4

Python TCP サーバーと c++ TCP クライアントの間で通信しようとすると問題が発生します。正常に動作する最初の呼び出しの後、後続の呼び出しで問題が発生します。

WinSock に関する限り、send() 関数は適切に機能し、適切な長さを返し、WSAGetLastError() は意味のあるものを何も返しません。

ただし、wireshark を使用してパケットを監視していると、最初の呼び出しで 2 つのパケット (すべてのデータを含む PSH、ACK、およびその直後の ACK) が送信されることに気付きましたが、その後の呼び出しは機能せず、送信のみを行います。後続の ACK パケットではなく、PSH、ACK パケット

受信コンピューターのwiresharkはこれを裏付けており、pythonサーバーは何もせず、ソケットからデータが出ていません。ソケットはネイティブクラスであるため、より深くデバッグすることはできません

C ++クライアントとC ++サーバー（Pythonのハッキングされたレプリカ）を実行すると、クライアントは最初の呼び出しの後でも、PSH、ACk、およびACKパケットの両方を常に忠実に送信します。

winsock send 関数は、常に PSH、ACK、および ACK を送信することになっていますか? もしそうなら、Python サーバーではなく C++ サーバーに接続しているときに、なぜそうなるのでしょうか? 誰かがこれに似た問題を抱えていますか?

4

2 に答える 2

2

クライアントはPSH、ACKを送信し、次にサーバーはPSH、ACKとFIN、PSH、ACKを送信します

FINがあるので、サーバーのPythonバージョンが最初の読み取りの直後に接続を閉じている可能性がありますか？

サーバーのソケットを明示的に閉じていない場合は、サーバーのリモートソケット変数がスコープ外になり、閉じている可能性があります（このバグはC ++バージョンには存在しません）。

これが事実であると仮定すると、サーバーに対してこのコードを使用して非常に類似したTCPシーケンスを発生させることができます。

# server.py
import socket
from time import sleep

def f(s):
        r,a = s.accept()
        print r.recv(100)

s = socket.socket()
s.bind(('localhost',1234))
s.listen(1)

f(s)
# wait around a bit for the client to send it's second packet
sleep(10)

そしてこれはクライアントのために：

# client.py
import socket
from time import sleep

s = socket.socket()
s.connect(('localhost',1234))

s.send('hello 1')
# wait around for a while so that the socket in server.py goes out of scope
sleep(5)
s.send('hello 2')

パケットスニファを起動し、server.pyを実行してからclient.pyを実行します。tcpdump -A -i loこれがあなたの観察と一致するのアウトアウトです：

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
12:42:37.683710 IP localhost:33491 > localhost.1234: S 1129726741:1129726741(0) win 32792 <mss 16396,sackOK,timestamp 640881101 0,nop,wscale 7>
E..<R.@.@...............CVC.........I|....@....
&3..........
12:42:37.684049 IP localhost.1234 > localhost:33491: S 1128039653:1128039653(0) ack 1129726742 win 32768 <mss 16396,sackOK,timestamp 640881101 640881101,nop,wscale 7>
E..<..@.@.<.............C<..CVC.....Ia....@....
&3..&3......
12:42:37.684087 IP localhost:33491 > localhost.1234: . ack 1 win 257 <nop,nop,timestamp 640881102 640881101>
E..4R.@.@...............CVC.C<......1......
&3..&3..
12:42:37.684220 IP localhost:33491 > localhost.1234: P 1:8(7) ack 1 win 257 <nop,nop,timestamp 640881102 640881101>
E..;R.@.@...............CVC.C<......./.....
&3..&3..hello 1
12:42:37.684271 IP localhost.1234 > localhost:33491: . ack 8 win 256 <nop,nop,timestamp 640881102 640881102>
E..4.(@.@...............C<..CVC.....1}.....
&3..&3..
12:42:37.684755 IP localhost.1234 > localhost:33491: F 1:1(0) ack 8 win 256 <nop,nop,timestamp 640881103 640881102>
E..4.)@.@...............C<..CVC.....1{.....
&3..&3..
12:42:37.685639 IP localhost:33491 > localhost.1234: . ack 2 win 257 <nop,nop,timestamp 640881104 640881103>
E..4R.@.@...............CVC.C<......1x.....
&3..&3..
12:42:42.683367 IP localhost:33491 > localhost.1234: P 8:15(7) ack 2 win 257 <nop,nop,timestamp 640886103 640881103>
E..;R.@.@...............CVC.C<......./.....
&3%W&3..hello 2
12:42:42.683401 IP localhost.1234 > localhost:33491: R 1128039655:1128039655(0) win 0
E..(..@.@.<.............C<......P...b...

9 packets captured
27 packets received by filter
0 packets dropped by kernel
于 2009-09-15T02:52:48.473 に答える
1

どのサイズのパケットを送信しますか？

それらが小さい場合-NagleのAlgorith＆Delayed ACK Algorithmが頭痛の種である可能性がありますか？あなたが説明したことから、DelayedACKが関係していると思います...

于 2009-09-14T19:05:44.343 に答える