2016-04-27 18 views
0

私は社内のTCPサーバーとTCPクライアントで作業しています。パケット損失が0%になると、サーバーとクライアントは正常に動作します。しかし、私は20%以上のパケットロスがあると、重複したTCPメッセージが表示されています。私は Python TCP Duplicate Message

Client <-- MessageA -- Server 
Client -- MessageB --> Server 
Client <-- MessageCMessageA -- Server 

がMessageAが完全にクライアントにそれを作っていないこと、それは可能です....このような何かを受け付けており、その回アウト、そして、TCPは、それを再送信した後、元のメッセージが受信されることになりますクライアントによって後で?

私の質問は、TCPがそれに似ているかどうか、また20%のパケット損失以上のネットワークを持つシナリオが考えられる場合です。

クライアントとサーバがデータを受信/送信しているかのベアボーン...

socket.recv(1024) 
socket.send(1024) 
+1

組み込みのTCP/IPライブラリを使用しており、接続がタイムアウトする前にすべてのピースが到着したと仮定すると、TCPは重複や再送信を心配する必要がないという保証を提供します。これは、UDP over TCPを選択する主な理由の1つです。データが適切に注文されていることとそれが保証されています。 –

+0

よろしくお願いいたします。私はバグを探し始める前に確かめたいと思っていました。 – Taztingo

+0

おそらく、あなたの 'recv'呼び出しは常に正確に1,024バイトを返すと仮定しましたか?バッファサイズは、実際の数ではなく、受信される最大バイト数です。メッセージを受け取るための完全なコードを表示してください。 –

答えて

1

いいえ、それは不可能です。 TCPは、データを正確に1回、送信された順序で配信するか、エラーをアプリケーションに通知するかを保証します。したがって、おそらくあなたのコードにバグがあります。最も可能性が高いのは、コードがの部分読み取りを処理できないことです。

あなたはTCPソケットのwriteまたはsendを行い、TCPモジュールがしますセグメントあなたのデータに必要とされる限り多くのパケットに。パケットロスがある場合、一部のパケットは正常に到着した可能性がありますが、他のパケットは再送信する必要があります。その場合、対応するreadまたはrecvはデータの一部のみを受信し、残りのデータは次のreadまたはrecvに到着します。言い換えると、TCPはメッセージの境界を保持しません。

あなたのコードは、おそらくこのような分割メッセージを複数のメッセージとして解釈しています。解析する前に、完全なメッセージがバッファに蓄積されていることを確認してください。

+0

すばらしい説明。 – Taztingo