Pythonのソケットに問題があります。
while 1
ループで相互にデータを送信するTCPサーバーとクライアントがあります。
structモジュール(struct.pack("hh", mousex, mousey)
)に2つのshortをパッケージ化します。ただしrecv
、他のコンピューターでデータを処理すると、2つのメッセージが結合されているように見える場合があります。これはnagleのアルゴリズムですか?
ここで何が起こっているのですか?前もって感謝します。
確かに実際のコードを確認する必要がありますが、受信機には常に正確なバイト数として1バイトが表示されることを期待しているsend
ようn
ですn
。
TCPストリームはそのようには機能しません。これは、UDP、 STCP、またはRDSのような「データグラム」(レコード指向)プロトコルとは対照的に、「ストリーミング」プロトコルです。
固定データサイズのプロトコル(または次のチャンクサイズが事前に予測可能なプロトコル)の場合、正確にバイトrecv()
を取得するまでループを実行するだけで、ストリームソケット上に独自の「データグラムのようなレシーバー」を構築できます。n
def recv_n_bytes(socket, n):
"attempt to receive exactly n bytes; return what we got"
data = []
while True:
have = sum(len(x) for x in data)
if have >= n:
break
want = n - have
got = socket.recv(want)
if got == '':
break
return ''.join(data)
(テストされていない; python 2.xコード;必ずしも効率的ではない;など)。
私は他のポスターに同意します、「TCPはそれをするだけです」。TCPは、バイトが正しい順序で到着することを保証しますが、到着するチャンクのサイズについては保証しません。TCPは、単一の送信を複数のrecvに分割したり、たとえばaabbを分割したりすることもできます。 ccddをaab、bcc、ddに変換します。
Pythonで関連する問題を処理するために、このモジュールをまとめました。http: //stromberg.dnsalias.org/~strombrg/bufsock.html これはオープンソースライセンスの下にあり、UCIが所有しています。CPython 2.x、CPython 3.x、Pypy、Jythonでテストされています。
HTH
他のソースエンドで送信するために提供されたのと同じサイズのデータがローカルソケットから読み取れるようになるとは思わないかもしれません。あなたが見てきたように、これは通常真実かもしれませんが、決して確実にそうではありません。むしろ、TCPが保証するのは、一方の端にあるものが最終的にもう一方の端に出てくるということです。何も欠けることなく、または再試行などのプロトコルに組み込まれた手段でそれを達成できない場合は、すべてがエラーで壊れます。
ネーグルが考えられる原因の1つですが、それだけではありません。