python-docs-ja/howto/sockets.po at 3.14 · python/python-docs-ja

768 lines (707 loc) · 42.8 KB
# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001 Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
# Translators:
# python-doc bot, 2025
"Project-Id-Version: Python 3.15\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2026-09-01 17:31+0000\n"
"PO-Revision-Date: 2025-09-16 00:00+0000\n"
"Last-Translator: python-doc bot, 2025\n"
"Language-Team: Japanese (https://app.transifex.com/python-doc/teams/5390/"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: ja\n"
"Plural-Forms: nplurals=1; plural=0;\n"
#: ../../howto/sockets.rst:5
msgid "Socket Programming HOWTO"
msgstr "ソケットプログラミング HOWTO"
#: ../../howto/sockets.rst-1
msgid "Abstract"
msgstr "概要"
#: ../../howto/sockets.rst:9
"Sockets are used nearly everywhere, but are one of the most severely "
"misunderstood technologies around. This is a 10,000 foot overview of "
"sockets. It's not really a tutorial - you'll still have work to do in "
"getting things operational. It doesn't cover the fine points (and there are "
"a lot of them), but I hope it will give you enough background to begin using "
"them decently."
"ソケットはそこかしこで使われているが、最大級に誤解されている技術でもある。こ"
"の文書はソケットの全体像を俯瞰しており、チュートリアルとしてはあまり役に立た"
"ない。実際に動くモノを完成させるには、他にもやらなければいけないことがあるか"
"らだ。この文書はソケットの微妙なところ (たくさんある) まではカバーしていない"
"が、恥ずかしくない使い方ができるようになる程度の情報は得られるはずだ。"
#: ../../howto/sockets.rst:17
msgid "Sockets"
msgstr "ソケット"
#: ../../howto/sockets.rst:19
"I'm only going to talk about INET (i.e. IPv4) sockets, but they account for "
"at least 99% of the sockets in use. And I'll only talk about STREAM (i.e. "
"TCP) sockets - unless you really know what you're doing (in which case this "
"HOWTO isn't for you!), you'll get better behavior and performance from a "
"STREAM socket than anything else. I will try to clear up the mystery of what "
"a socket is, as well as some hints on how to work with blocking and non-"
"blocking sockets. But I'll start by talking about blocking sockets. You'll "
"need to know how they work before dealing with non-blocking sockets."
"INET (すなわち IPv4) ソケットのことしか語らないつもりだが、利用率でいうとソ"
"ケットの 99% 以上はこれだ。さらに中でも STREAM (すなわち TCP) ソケットに話題"
"を絞ろうと思う - 自分が何をしているのか分かっているのでない限り (分かってるな"
"らこの HOWTO なんて要らないだろ!)、STREAM ソケットが一番分かりやすく、一番性"
"能が出るのだ。そうやって謎に包まれたソケットの正体を明らかにしてゆくと共に、"
"ブロッキングおよびノンブロッキングなソケットの扱いに関するいくつかのヒントを"
"提示しよう。だが、まずはブロッキングソケットから始めることにする。ノンブロッ"
"キングを扱うより先に、ブロッキングの仕組みを知っておかなくてはならないのだ。"
#: ../../howto/sockets.rst:28
"Part of the trouble with understanding these things is that \"socket\" can "
"mean a number of subtly different things, depending on context. So first, "
"let's make a distinction between a \"client\" socket - an endpoint of a "
"conversation, and a \"server\" socket, which is more like a switchboard "
"operator. The client application (your browser, for example) uses \"client\" "
"sockets exclusively; the web server it's talking to uses both \"server\" "
"sockets and \"client\" sockets."
"話を理解しにくくしている要因として、「ソケット」という言葉が文脈によって微妙"
"に違うものを指すことが挙げられる。そこでまず、「クライアント」ソケット - 対話"
"の両端 - と「サーバ」ソケット - 電話交換手みたいなもの - の区別を付けておこ"
"う。クライアントアプリケーション (たとえばブラウザ) は「クライアント」ソケッ"
"トだけを使うが、話し相手のウェブサーバは「サーバ」ソケットと「クライアント」"
"ソケットの両方を使う。"
#: ../../howto/sockets.rst:37
msgid "History"
msgstr "歴史"
#: ../../howto/sockets.rst:39
"Of the various forms of :abbr:`IPC (Inter Process Communication)`, sockets "
"are by far the most popular.  On any given platform, there are likely to be "
"other forms of IPC that are faster, but for cross-platform communication, "
"sockets are about the only game in town."
"各種 :abbr:`IPC (Inter Process Communication` (プロセス間通信) の中でも、ソ"
"ケットは群を抜いて人気がある。どのプラットフォームにも、ソケットより速い IPC "
"はあるだろう。だが、プラットフォームをまたぐ通信はソケットの独擅場だ。"
#: ../../howto/sockets.rst:44
"They were invented in Berkeley as part of the BSD flavor of Unix. They "
"spread like wildfire with the internet. With good reason --- the combination "
"of sockets with INET makes talking to arbitrary machines around the world "
"unbelievably easy (at least compared to other schemes)."
"ソケットは BSD Unix の一部としてバークレイで発明され、インターネットの普及と"
"共に野火のごとく広まった。それももっともなことで、ソケットと INET のコンビに"
"よって世界中どんなマシンとも、信じられないほど簡単 (少なくとも他のスキームと"
"比べて) に通信できるようになったのだ。"
#: ../../howto/sockets.rst:51
msgid "Creating a Socket"
msgstr "ソケットの作成"
#: ../../howto/sockets.rst:53
"Roughly speaking, when you clicked on the link that brought you to this "
"page, your browser did something like the following::"
"あなたがリンクをクリックしてこのページに来たとき、ブラウザは大雑把に言って次"
"のようなことをしたのである::"
#: ../../howto/sockets.rst:56
"# create an INET, STREAMing socket\n"
"s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n"
"# now connect to the web server on port 80 - the normal http port\n"
"s.connect((\"www.python.org\", 80))"
#: ../../howto/sockets.rst:61
"When the ``connect`` completes, the socket ``s`` can be used to send in a "
"request for the text of the page. The same socket will read the reply, and "
"then be destroyed. That's right, destroyed. Client sockets are normally only "
"used for one exchange (or a small set of sequential exchanges)."
"この ``connect`` が完了すると、ソケット ``s`` を使ってこのページ文章への要求"
"を送ることができるようになる。その同じソケットが返答を読み、そして破壊され"
"る。そう、破壊される。クライアントソケットは通常、一回 (か少数の) やり取りで"
"使い捨てになるのだ。"
#: ../../howto/sockets.rst:67
"What happens in the web server is a bit more complex. First, the web server "
"creates a \"server socket\"::"
"ウェブサーバで起こる事柄はもう少し複雑だ。まず「サーバソケット」を作る::"
#: ../../howto/sockets.rst:70
"# create an INET, STREAMing socket\n"
"serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n"
"# bind the socket to a public host, and a well-known port\n"
"serversocket.bind((socket.gethostname(), 80))\n"
"# become a server socket\n"
"serversocket.listen(5)"
#: ../../howto/sockets.rst:77
"A couple things to notice: we used ``socket.gethostname()`` so that the "
"socket would be visible to the outside world.  If we had used ``s."
"bind(('localhost', 80))`` or ``s.bind(('127.0.0.1', 80))`` we would still "
"have a \"server\" socket, but one that was only visible within the same "
"machine.  ``s.bind(('', 80))`` specifies that the socket is reachable by any "
"address the machine happens to have."
"ここで注意すべき点がいくつかある: 今回はソケットが外界に見えるよう、 "
"``socket.gethostname()`` を使った。 ``s.bind(('localhost', 80))`` や  ``s."
"bind(('127.0.0.1', 80))`` でも「サーバ」ソケットにはなるが、それだと同じマシ"
"ン内にしか見えないものになってしまう。 ``s.bind(('', 80))`` はこのマシンが"
"持っている全てのアドレスで接続可能になるようにという指定になる。"
#: ../../howto/sockets.rst:84
"A second thing to note: low number ports are usually reserved for \"well "
"known\" services (HTTP, SNMP etc). If you're playing around, use a nice high "
"number (4 digits)."
"ふたつめ: 小さな番号のポートは大抵、「ウェルノウン (有名)」なサービス (HTTP, "
"SNMP 等々) のために取ってある。お遊びで使うのなら適当に大きな数 (4桁) を使お"
#: ../../howto/sockets.rst:88
"Finally, the argument to ``listen`` tells the socket library that we want it "
"to queue up as many as 5 connect requests (the normal max) before refusing "
"outside connections. If the rest of the code is written properly, that "
"should be plenty."
"最後に: ``listen`` の引数はソケットライブラリに、接続要求を 5 個 (通常の最大"
"値) まで順番待ちさせるように命じている。これ以降の外部接続は拒否するのだが、"
"コードが適切に書かれていれば、それで十分すぎるほどだ。"
#: ../../howto/sockets.rst:92
"Now that we have a \"server\" socket, listening on port 80, we can enter the "
"mainloop of the web server::"
"よし、「サーバーソケット」ができて、80 番ポートで耳を澄ましているところまで来"
"た。では、ウェブサーバのメインループに入ろう::"
#: ../../howto/sockets.rst:95
"while True:\n"
"    # accept connections from outside\n"
"    (clientsocket, address) = serversocket.accept()\n"
"    # now do something with the clientsocket\n"
"    # in this case, we'll pretend this is a threaded server\n"
"    ct = make_client_thread(clientsocket)\n"
"    ct.start()"
#: ../../howto/sockets.rst:103
"There's actually 3 general ways in which this loop could work - dispatching "
"a thread to handle ``clientsocket``, create a new process to handle "
"``clientsocket``, or restructure this app to use non-blocking sockets, and "
"multiplex between our \"server\" socket and any active ``clientsocket``\\ s "
"using ``select``. More about that later. The important thing to understand "
"now is this: this is *all* a \"server\" socket does. It doesn't send any "
"data. It doesn't receive any data. It just produces \"client\" sockets. Each "
"``clientsocket`` is created in response to some *other* \"client\" socket "
"doing a ``connect()`` to the host and port we're bound to. As soon as we've "
"created that ``clientsocket``, we go back to listening for more connections. "
"The two \"clients\" are free to chat it up - they are using some dynamically "
"allocated port which will be recycled when the conversation ends."
"このループには実際のところ、3 通りの一般的な動作方法がある - "
"``clientsocket`` を扱うようにスレッドを割り当てたり、``clientsocket`` を扱う"
"新しいプロセスを作ったり、あるいはノンブロッキングソケットを使うようにアプリ"
"を作り直して ``select`` で「サーバ」ソケットとアクティブな ``clientsocket`` "
"の間を多重化したりするのだ。最後のについてはまた後にしよう。ここで理解してお"
"くべき要点はこれだ: 以上が「サーバ」ソケットの仕事の *すべて* である。データ"
"は一切送信しないし、受信しない。「クライアント」ソケットを生み出すだけ。我々"
"のバインドされているホストとポートに ``connect()`` してくる *他の* 「クライア"
"ント」ソケットに応える形で ``clientsocket`` を作り、作るや否や、さらなる接続"
"を聞きに戻っていくのだ。このふたつの「クライアント」は、あとは勝手に喋ってい"
"ればいい - 使うポートは動的に割り当てられ、会話が終わればリサイクルに廻され"
#: ../../howto/sockets.rst:118
msgid "IPC"
msgstr "IPC"
#: ../../howto/sockets.rst:120
"If you need fast IPC between two processes on one machine, you should look "
"into pipes or shared memory.  If you do decide to use AF_INET sockets, bind "
"the \"server\" socket to ``'localhost'``. On most platforms, this will take "
"a shortcut around a couple of layers of network code and be quite a bit "
"1つのマシン上の2プロセス間で高速なIPCを行いたい場合は、pipe か共有メモリを検"
"討するべきです。AF_INET ソケットを使用すると決めた場合、「サーバー」ソケット"
"は ``'localhost'`` にバインドしましょう。ほとんどのプラットフォームで、いくつ"
"かのネットワークレイヤーをショートカットすることでかなり高速になります。"
#: ../../howto/sockets.rst:126
"The :mod:`multiprocessing` integrates cross-platform IPC into a higher-level "
":mod:`multiprocessing` はクロスプラットフォームなIPCの高級なAPIを提供していま"
#: ../../howto/sockets.rst:131
msgid "Using a Socket"
msgstr "ソケットの利用"
#: ../../howto/sockets.rst:133
"The first thing to note, is that the web browser's \"client\" socket and the "
"web server's \"client\" socket are identical beasts. That is, this is a "
"\"peer to peer\" conversation. Or to put it another way, *as the designer, "
"you will have to decide what the rules of etiquette are for a conversation*. "
"Normally, the ``connect``\\ ing socket starts the conversation, by sending "
"in a request, or perhaps a signon. But that's a design decision - it's not a "
"rule of sockets."
"はじめに憶えておくべきなのは、ウェブブラウザの「クライアント」ソケットとウェ"
"ブサーバの「クライアント」ソケットがまったく同じ種族だということだ。つまり、"
"これは「ピア・トゥ・ピア」(1 対 1) の会話である。別の言い方をすると、 *設計者"
"として自分で会話のエチケット規則を決めなくてはいけない* ということでもある。"
"通常は、 ``connect`` してくるソケットが要求あるいは宣言をして会話を始める。だ"
"が、それはそう設計しただけのことだ - ソケットの規則ではない。"
#: ../../howto/sockets.rst:140
"Now there are two sets of verbs to use for communication. You can use "
"``send`` and ``recv``, or you can transform your client socket into a file-"
"like beast and use ``read`` and ``write``. The latter is the way Java "
"presents its sockets. I'm not going to talk about it here, except to warn "
"you that you need to use ``flush`` on sockets. These are buffered \"files\", "
"and a common mistake is to ``write`` something, and then ``read`` for a "
"reply. Without a ``flush`` in there, you may wait forever for the reply, "
"because the request may still be in your output buffer."
"さて、コミュニケーションに使う動詞は二組ある。 ``send`` と ``recv`` を使うこ"
"ともできるし、クライアントソケットをファイルっぽい種族に変形して ``read`` と "
"``write`` を使っても良い。後者は Java のソケットの表現方法だ。ここで詳しく語"
"るつもりはないが、その場合はソケットも ``flush`` しなければいけない、とだけ"
"言っておく。これはバッファリングした「ファイル」なので、何かを ``write`` して"
"すぐに返答を ``read`` するというのはよくある間違いだ。間に ``flush`` を入れな"
"いと、要求がまだ出力バッファにあって永遠に返事が来ない、という可能性がある。"
#: ../../howto/sockets.rst:149
"Now we come to the major stumbling block of sockets - ``send`` and ``recv`` "
"operate on the network buffers. They do not necessarily handle all the bytes "
"you hand them (or expect from them), because their major focus is handling "
"the network buffers. In general, they return when the associated network "
"buffers have been filled (``send``) or emptied (``recv``). They then tell "
"you how many bytes they handled. It is *your* responsibility to call them "
"again until your message has been completely dealt with."
"さあ、ソケットの主要な難関に進もう -  ``send`` と ``recv`` はネットワークバッ"
"ファに働きかけるものだ。だから、手渡したもの (や返してもらいたいもの) を 1 バ"
"イトも残さず実際に処理してくれているとは限らない。一般的に言って、 ``send`` "
"はバッファが埋まるまで、``recv`` はバッファが空になるまで処理をして、そのバイ"
"ト数を返す。メッセージが完全に処理されるまで繰り返し呼び出すのは *自分の* 責"
#: ../../howto/sockets.rst:157
"When a ``recv`` returns 0 bytes, it means the other side has closed (or is "
"in the process of closing) the connection.  You will not receive any more "
"data on this connection. Ever.  You may be able to send data successfully; "
"I'll talk more about this later."
"``recv`` が 0 バイトを返したときは、向こう側が接続を閉じてしまった (または閉"
"じようとしている途中) という意味だ。もうこの接続でデータを受け取ることはな"
"い。永遠にだ。ただ、データ送信は成功するかもしれない; これについてはあとで語"
#: ../../howto/sockets.rst:162
"A protocol like HTTP uses a socket for only one transfer. The client sends a "
"request, then reads a reply.  That's it. The socket is discarded. This means "
"that a client can detect the end of the reply by receiving 0 bytes."
"HTTP のようなプロトコルでは、ひとつのソケットを1回の転送にしか使わない。クラ"
"イアントは要求を送り、返答を受ける。以上だ。これでソケットは破棄される。だか"
"らこの場合、クライアントは受信 0 バイトの時点で返答の末尾を検出することができ"
#: ../../howto/sockets.rst:166
"But if you plan to reuse your socket for further transfers, you need to "
"realize that *there is no* :abbr:`EOT (End of Transfer)` *on a socket.* I "
"repeat: if a socket ``send`` or ``recv`` returns after handling 0 bytes, the "
"connection has been broken.  If the connection has *not* been broken, you "
"may wait on a ``recv`` forever, because the socket will *not* tell you that "
"there's nothing more to read (for now).  Now if you think about that a bit, "
"you'll come to realize a fundamental truth of sockets: *messages must either "
"be fixed length* (yuck), *or be delimited* (shrug), *or indicate how long "
"they are* (much better), *or end by shutting down the connection*. The "
"choice is entirely yours, (but some ways are righter than others)."
"だが、以降の転送にもそのソケットを使い回すつもりなら、ソケットに :abbr:`EOT "
"(End of Transfer)` など *存在しない* ことを認識する必要がある。もう一度言お"
"う: ソケットの ``send`` や ``recv`` が 0 バイト処理で返ってきたなら、その接続"
"は終わっている。終わって *いない* なら、いつまで ``recv`` を待てばいいかは分"
"からない。ソケットは「もう読むものが (今のところ) ないぜ」などと *言わない* "
"のだから。このことを少し考えれば、ソケットの真実を悟ることになるだろう: *メッ"
"セージは必ず固定長か* (うげぇ) *区切り文字を使うか* (やれやれ) *長さ標識を付"
"けておくか* (かなりマシ) *接続を閉じて終わらせるかのいずれかでなければいけな"
"い* のだ。選ぶ権利と責任はまったくもって自分にある (が、正しさの程度に違いは"
#: ../../howto/sockets.rst:177
"Assuming you don't want to end the connection, the simplest solution is a "
"fixed length message::"
"毎回接続を終わらせるのはイヤだとして、最も単純な解決策は固定長メッセージだろ"
#: ../../howto/sockets.rst:180
"class MySocket:\n"
"    \"\"\"demonstration class only\n"
"      - coded for clarity, not efficiency\n"
"    \"\"\"\n"
"    def __init__(self, sock=None):\n"
"        if sock is None:\n"
"            self.sock = socket.socket(\n"
"                            socket.AF_INET, socket.SOCK_STREAM)\n"
"        else:\n"
"            self.sock = sock\n"
"    def connect(self, host, port):\n"
"        self.sock.connect((host, port))\n"
"    def mysend(self, msg):\n"
"        totalsent = 0\n"
"        while totalsent < MSGLEN:\n"
"            sent = self.sock.send(msg[totalsent:])\n"
"            if sent == 0:\n"
"                raise RuntimeError(\"socket connection broken\")\n"
"            totalsent = totalsent + sent\n"
"    def myreceive(self):\n"
"        chunks = []\n"
"        bytes_recd = 0\n"
"        while bytes_recd < MSGLEN:\n"
"            chunk = self.sock.recv(min(MSGLEN - bytes_recd, 2048))\n"
"            if chunk == b'':\n"
"                raise RuntimeError(\"socket connection broken\")\n"
"            chunks.append(chunk)\n"
"            bytes_recd = bytes_recd + len(chunk)\n"
"        return b''.join(chunks)"
#: ../../howto/sockets.rst:214
"The sending code here is usable for almost any messaging scheme - in Python "
"you send strings, and you can use ``len()`` to determine its length (even if "
"it has embedded ``\\0`` characters). It's mostly the receiving code that "
"gets more complex. (And in C, it's not much worse, except you can't use "
"``strlen`` if the message has embedded ``\\0``\\ s.)"
"この送信コードは、ほぼあらゆるメッセージ通信スキームで使える - 文字列を送ると"
"き、Python なら長さを ``len()`` で見極めることができる (中に ``\\0`` が埋め込"
"まれていても大丈夫)。難しくしているのは、おもに受信コードである。 (なお、C で"
"も事態はあまり悪くならないが、メッセージに ``\\0`` が埋め込まれていると "
"``strlen`` が使えないのは面倒だ。)"
#: ../../howto/sockets.rst:220
"The easiest enhancement is to make the first character of the message an "
"indicator of message type, and have the type determine the length. Now you "
"have two ``recv``\\ s - the first to get (at least) that first character so "
"you can look up the length, and the second in a loop to get the rest. If you "
"decide to go the delimited route, you'll be receiving in some arbitrary "
"chunk size, (4096 or 8192 is frequently a good match for network buffer "
"sizes), and scanning what you've received for a delimiter."
"最も簡単な改良法は、メッセージの最初の一文字をタイプ標識にして、そのタイプで"
"長さを決定するというものだ。この場合ふたつの ``recv`` があることになる - 一番"
"目でその一文字 (だけじゃなくても可) を取って長さを調べ、二番目でループして残"
"りを取るのだ。あるいはもし区切り方式の道を行くのであれば、任意のサイズ (4096 "
"か 8192 がネットワークバッファには最適なことが多い) で受信して区切り文字を走"
"査していくことになる。"
#: ../../howto/sockets.rst:228
"One complication to be aware of: if your conversational protocol allows "
"multiple messages to be sent back to back (without some kind of reply), and "
"you pass ``recv`` an arbitrary chunk size, you may end up reading the start "
"of a following message. You'll need to put that aside and hold onto it, "
"until it's needed."
"心に留めておくべき面倒な点がひとつ: 複数メッセージが次々に (何らかの返事を待"
"たずに) 返ってくることのある会話プロトコルなら、そして任意のサイズを "
"``recv`` に渡しているなら、次のメッセージの冒頭部分まで読んでしまうことがある"
"かもしれない。そのときは、必要になるまで脇によけて、大切に保管しておく必要が"
#: ../../howto/sockets.rst:234
"Prefixing the message with its length (say, as 5 numeric characters) gets "
"more complex, because (believe it or not), you may not get all 5 characters "
"in one ``recv``. In playing around, you'll get away with it; but in high "
"network loads, your code will very quickly break unless you use two ``recv`` "
"loops - the first to determine the length, the second to get the data part "
"of the message. Nasty. This is also when you'll discover that ``send`` does "
"not always manage to get rid of everything in one pass. And despite having "
"read this, you will eventually get bit by it!"
"メッセージ冒頭に長さを (たとえば 5 桁の数字で) 付けるのは、それよりもさらに複"
"雑になる。というのも、(信じられないかもしれないが) 一回の ``recv`` で 5 文字"
"を全部受け取ることができるとは限らないからだ。お遊びでやっている間はごまかせ"
"ても、高負荷ネットワークのもとでは、``recv`` ループをふたつ使わないコードは、"
"あっと言う間にダメになってしまう - 一番目は長さを見定める用で、二番目はデータ"
"部分を受け取る用だ。うーむ、いやらしい。さらにこのとき、``send`` も一発で全部"
"を出し切れるとは限らないことに気付くだろう。なお、今こうやって読んでいても、"
"いつか誰もが痛い目を見るのである!"
#: ../../howto/sockets.rst:243
"In the interests of space, building your character, (and preserving my "
"competitive position), these enhancements are left as an exercise for the "
"reader. Lets move on to cleaning up."
"紙面の都合および教育的配慮 (と著者の地位確保) のため、こうした改良は練習問題"
"として残しておく。さあ片付けてしまおう。"
#: ../../howto/sockets.rst:249
msgid "Binary Data"
msgstr "バイナリデータ"
#: ../../howto/sockets.rst:251
"It is perfectly possible to send binary data over a socket. The major "
"problem is that not all machines use the same formats for binary data. For "
"example, `network byte order <https://en.wikipedia.org/wiki/"
"Endianness#Networking>`_ is big-endian, with the most significant byte "
"first, so a 16 bit integer with the value ``1`` would be the two hex bytes "
"``00 01``. However, most common processors (x86/AMD64, ARM, RISC-V), are "
"little-endian, with the least significant byte first - that same ``1`` would "
"be ``01 00``."
#: ../../howto/sockets.rst:259
"Socket libraries have calls for converting 16 and 32 bit integers - ``ntohl, "
"htonl, ntohs, htons`` where \"n\" means *network* and \"h\" means *host*, "
"\"s\" means *short* and \"l\" means *long*. Where network order is host "
"order, these do nothing, but where the machine is byte-reversed, these swap "
"the bytes around appropriately."
#: ../../howto/sockets.rst:265
"In these days of 64-bit machines, the ASCII representation of binary data is "
"frequently smaller than the binary representation. That's because a "
"surprising amount of the time, most integers have the value 0, or maybe 1. "
"The string ``\"0\"`` would be two bytes, while a full 64-bit integer would "
"be 8. Of course, this doesn't fit well with fixed-length messages. "
"Decisions, decisions."
#: ../../howto/sockets.rst:274
msgid "Disconnecting"
msgstr "切断"
#: ../../howto/sockets.rst:276
"Strictly speaking, you're supposed to use ``shutdown`` on a socket before "
"you ``close`` it.  The ``shutdown`` is an advisory to the socket at the "
"other end. Depending on the argument you pass it, it can mean \"I'm not "
"going to send anymore, but I'll still listen\", or \"I'm not listening, good "
"riddance!\".  Most socket libraries, however, are so used to programmers "
"neglecting to use this piece of etiquette that normally a ``close`` is the "
"same as ``shutdown(); close()``.  So in most situations, an explicit "
"``shutdown`` is not needed."
"厳密には、ソケットを ``close`` する前には ``shutdown`` することになってい"
"る。 ``shutdown`` は相手ソケットに対する報告であり、渡す引数によって「これ以"
"上こっちからは送らないけど、まだ聞いてるぜ」という意味になったり、「もう聞か"
"ない。せいせいした!」だったりする。しかしほとんどのソケットライブラリは、この"
"エチケットを怠るプログラマに慣れてしまって、通常 ``close`` だけで "
"``shutdown(); close()`` と同じことになる。だから大抵はわざわざ ``shutdown`` "
#: ../../howto/sockets.rst:284
"One way to use ``shutdown`` effectively is in an HTTP-like exchange. The "
"client sends a request and then does a ``shutdown(1)``. This tells the "
"server \"This client is done sending, but can still receive.\"  The server "
"can detect \"EOF\" by a receive of 0 bytes. It can assume it has the "
"complete request.  The server sends a reply. If the ``send`` completes "
"successfully then, indeed, the client was still receiving."
"``shutdown`` の効果的な使い方のひとつは、HTTP 風のやりとりだ。クライアントは"
"要求を出してすぐに ``shutdown(1)`` する。これでサーバに、「クライアントは送信"
"完了ですが、まだ受信可能です」と伝わる。サーバは 0 バイト受信で \"EOF\" を検"
"出することができる。要求を残さず受け取ったことにして良いのだ。対してサーバは"
"返答を送る。その ``send`` が成功したなら、クライアントは実際にまだ受信してい"
#: ../../howto/sockets.rst:291
"Python takes the automatic shutdown a step further, and says that when a "
"socket is garbage collected, it will automatically do a ``close`` if it's "
"needed. But relying on this is a very bad habit. If your socket just "
"disappears without doing a ``close``, the socket at the other end may hang "
"indefinitely, thinking you're just being slow. *Please* ``close`` your "
"sockets when you're done."
"Python はこの自動 shutdown をもう一歩進めて、ソケットが GC されるときに必要な"
"ら自動で ``close`` してくれると言っている。しかしこれに頼るクセをつけてはいけ"
"ない。もしソケットが ``close`` せずに姿を消せば、相手ソケットはこちらが遅いだ"
"けだと思ってハングしてしまうかもしれない。 *お願いだから* 終わったらちゃんと "
"``close`` してくれ。"
#: ../../howto/sockets.rst:299
msgid "When Sockets Die"
msgstr "ソケットが死ぬと"
#: ../../howto/sockets.rst:301
"Probably the worst thing about using blocking sockets is what happens when "
"the other side comes down hard (without doing a ``close``). Your socket is "
"likely to hang. TCP is a reliable protocol, and it will wait a long, long "
"time before giving up on a connection. If you're using threads, the entire "
"thread is essentially dead. There's not much you can do about it. As long as "
"you aren't doing something dumb, like holding a lock while doing a blocking "
"read, the thread isn't really consuming much in the way of resources. Do "
"*not* try to kill the thread - part of the reason that threads are more "
"efficient than processes is that they avoid the overhead associated with the "
"automatic recycling of resources. In other words, if you do manage to kill "
"the thread, your whole process is likely to be screwed up."
"ブロッキングソケットを使っていて一番いやなのは多分、相手側が意地悪く "
"(``close`` せずに) ダウンするときに起こる事柄だ。自分側のソケットは高確率でハ"
"ングするだろう。TCP は信頼性の高いプロトコルなので、ずっとずっと待ち続けて、"
"なかなか見捨てないのだ。スレッドを使っているのであれば、そのスレッド全体が根"
"本から死んだ状態になる。こうなると、もう手の施しようがない。まあ、ブロッキン"
"グ読み出しの間ロックし続けるといった馬鹿げたことをしていない限り、リソースの"
"点ではたいして消費にならない。だから *ぜったいに* そのスレッドを殺そうとして"
"はいけない - プロセスよりスレッドが効率的である理由のひとつは、自動リソース回"
"収にまつわるオーバヘッドを避けられるという点にあるのだ。つまり別の言い方をす"
"ると、どうにかしてそのスレッドを殺したなら、プロセス全体がぐちゃぐちゃになっ"
"てしまうだろうということだ。"
#: ../../howto/sockets.rst:315
msgid "Non-blocking Sockets"
msgstr "ノンブロッキングソケット"
#: ../../howto/sockets.rst:317
"If you've understood the preceding, you already know most of what you need "
"to know about the mechanics of using sockets. You'll still use the same "
"calls, in much the same ways. It's just that, if you do it right, your app "
"will be almost inside-out."
"ここまで理解してきたなら、もうソケットの仕組みについて必要なことはほとんど"
"知っていることになる。これからも同じコールを、ほぼ同じように使っていくだけ、"
"それだけだ。これをちゃんとやっていれば、そのアプリはだいたい完璧であろう。"
#: ../../howto/sockets.rst:322
"In Python, you use ``socket.setblocking(False)`` to make it non-blocking. In "
"C, it's more complex, (for one thing, you'll need to choose between the BSD "
"flavor ``O_NONBLOCK`` and the almost indistinguishable POSIX flavor "
"``O_NDELAY``, which is completely different from ``TCP_NODELAY``), but it's "
"the exact same idea. You do this after creating the socket, but before using "
"it. (Actually, if you're nuts, you can switch back and forth.)"
"Python の場合、ノンブロッキングにするには ``socket.setblocking(False)`` を使"
"う。 C ならもっと複雑だ (一例を挙げると、BSD 方式の ``O_NONBLOCK`` およびほぼ"
"違いのない POSIX 方式 ``O_NDELAY`` のどちらを選ぶか決めなくてはならなくて、後"
"者は ``TCP_NODELAY`` とは全然別物だったりする) が、考え方はまったく一緒だ。こ"
"れは、ソケットを作成した後、使用する前に行う。(実際、常識破りなら、切り替える"
"ことができます。)"
#: ../../howto/sockets.rst:329
"The major mechanical difference is that ``send``, ``recv``, ``connect`` and "
"``accept`` can return without having done anything. You have (of course) a "
"number of choices. You can check return code and error codes and generally "
"drive yourself crazy. If you don't believe me, try it sometime. Your app "
"will grow large, buggy and suck CPU. So let's skip the brain-dead solutions "
"and do it right."
"構造上の大きな違いは、 ``send``, ``recv``, ``connect``, ``accept`` が何もしな"
"いで戻ってくるかもしれないという点である。選択肢は (当然ながら) いくつかあ"
"る。返り値とエラーコードをチェックするという方法もある。が、発狂すること請け"
"合いだ。信じないなら、いつかやってみるといい。アプリは肥大化し、バグが増え、"
"CPU を喰い尽くすだろう。だからそんな愚かな解法は飛ばして、正解に進もう。"
#: ../../howto/sockets.rst:336
msgid "Use ``select``."
msgstr "``select`` を使え。"
#: ../../howto/sockets.rst:338
"In C, coding ``select`` is fairly complex. In Python, it's a piece of cake, "
"but it's close enough to the C version that if you understand ``select`` in "
"Python, you'll have little trouble with it in C::"
"C において ``select`` でコードを書くのはかなり面倒だが、Python なら造作もな"
"い。しかし Python で ``select`` を理解しておけば C でもほとんど問題なく書け"
"る、という程度には似ている::"
#: ../../howto/sockets.rst:342
"ready_to_read, ready_to_write, in_error = \\\n"
"               select.select(\n"
"                  potential_readers,\n"
"                  potential_writers,\n"
"                  potential_errs,\n"
"                  timeout)"
#: ../../howto/sockets.rst:349
"You pass ``select`` three lists: the first contains all sockets that you "
"might want to try reading; the second all the sockets you might want to try "
"writing to, and the last (normally left empty) those that you want to check "
"for errors. You should note that a socket can go into more than one list. "
"The ``select`` call is blocking, but you can give it a timeout. This is "
"generally a sensible thing to do - give it a nice long timeout (say a "
"minute) unless you have good reason to do otherwise."
"``select`` に三つのリストを渡しているが、一番目にはあとで読みたくなるかもしれ"
"ないソケットすべて、二番目には書き込みたくなるかもしれないソケットすべて、最"
"後に (通常は空のままだが) エラーをチェックしたいソケットが入っている。ひとつ"
"のソケットが複数にまたがってリストされても構わないことを憶えておくと良い。な"
"お、 ``select`` コールはブロックするが、時間制限を与えることができる。これ"
"は、やっておいて損はない - 特に理由がなければ、かなり長い (たとえば 1 分とか"
"の) 時間制限を付けておくことだ。"
#: ../../howto/sockets.rst:357
"In return, you will get three lists. They contain the sockets that are "
"actually readable, writable and in error. Each of these lists is a subset "
"(possibly empty) of the corresponding list you passed in."
"戻り値として、三つのリストが手に入る。それぞれには、実際に読めるソケット、書"
"けるソケット、エラー中のソケットが入っていて、渡したリストの部分集合 (空集合"
"かもしれない) になっている。"
#: ../../howto/sockets.rst:361
"If a socket is in the output readable list, you can be as-close-to-certain-"
"as-we-ever-get-in-this-business that a ``recv`` on that socket will return "
"*something*. Same idea for the writable list. You'll be able to send "
"*something*. Maybe not all you want to, but *something* is better than "
"nothing.  (Actually, any reasonably healthy socket will return as writable - "
"it just means outbound network buffer space is available.)"
"出力のうち、readable リストにあるソケットについては、 ``recv`` がとりあえず *"
"何か* を返すであろう、ということは史上最高度に確信できる。 writable リストも"
"考え方は同じで、 *何か* は送れる。送りたいもの全体は無理かもしれないが、 *何"
"も* ないよりはマシだろう。 (実のところ、ふつうに健康なソケットなら writable "
"で返ってくることができる - それは外向きネットワークバッファに空きがあるという"
"だけの意味しかないのだから)"
#: ../../howto/sockets.rst:368
"If you have a \"server\" socket, put it in the potential_readers list. If it "
"comes out in the readable list, your ``accept`` will (almost certainly) "
"work. If you have created a new socket to ``connect`` to someone else, put "
"it in the potential_writers list. If it shows up in the writable list, you "
"have a decent chance that it has connected."
"「サーバ」ソケットは potential_readers リストに入れておこう。それが readable "
"リストに入って出てきたら、 ``accept`` は (ほぼ) 確実に成功するはずだ。どこか"
"へ ``connect`` するために作った新しいソケットは potential_writers リストに入"
"れる。それが writable リストに現れたら、接続が成功している可能性は高いと言え"
#: ../../howto/sockets.rst:374
"Actually, ``select`` can be handy even with blocking sockets. It's one way "
"of determining whether you will block - the socket returns as readable when "
"there's something in the buffers.  However, this still doesn't help with the "
"problem of determining whether the other end is done, or just busy with "
"something else."
"じつは ``select`` はブロッキングソケットにも便利に使える。それはブロックする"
"かどうかを見極める方法のひとつである - バッファに何かがあれば readable として"
"返ってくるのだ。しかしこれも、相手の用事がもう済んでいるのか、それとも単に他"
"のことで忙しいだけなのかを見極める役には立たない。"
#: ../../howto/sockets.rst:379
"**Portability alert**: On Unix, ``select`` works both with the sockets and "
"files. Don't try this on Windows. On Windows, ``select`` works with sockets "
"only. Also note that in C, many of the more advanced socket options are done "
"differently on Windows. In fact, on Windows I usually use threads (which "
"work very, very well) with my sockets."
"**非互換警報**: Unix ではソケットにもファイルにも ``select`` が使える。これ"
"を Windows でやろうとしてはいけない。Windows で ``select`` はソケットにしか使"
"えない。また C の場合、高度なソケットオプションの多くは、やり方が Windows で"
"は違っている。実際、Windows なら著者は通常、ソケットにスレッドを使っている "
"(これは実に、実にうまくいく)。"
Navigation Menu

Uh oh!

Uh oh!

Uh oh!

Uh oh!

FilesExpand file tree

sockets.po

Latest commit

History

sockets.po

File metadata and controls
