разговор между tcp сервером python и клиентом c ++

Question

У меня возникла проблема при попытке установить связь между TCP-сервером Python и TCP-клиентом C ++. После первого вызова, который работает нормально, последующие вызовы вызывают проблемы.

Что касается WinSock, функция send () работала правильно, она возвращает правильную длину, а WSAGetLastError () не возвращает ничего значимого.

Однако, при просмотре пакетов с использованием wireshark, я замечаю, что первый вызов отправляет два пакета, PSH, ACK со всеми данными в нем и ACK сразу после, но последующие вызовы, которые не работают , только отправлять PSH, ACK-пакет, а не последующий ACK-пакет

Wireshark принимающих компьютеров подтверждает это, и сервер python ничего не делает, у него нет данных, поступающих из сокета, и я не могу отладить глубже, так как сокет является собственным классом

когда я запускаю клиент c ++ и сервер c ++ (взломанную копию того, что будет делать python), клиент точно отправляет пакеты PSH, ACk и ACK все время, даже после первого вызова.

Должна ли функция отправки winsock всегда отправлять PSH, ACK и ACK? Если да, то почему это происходит при подключении к моему серверу C ++, а не к серверу python? У кого-нибудь были подобные проблемы?

Answer 1

клиент отправляет 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

Answer 2

Какой размер пакетов вы отправляете?

Если они маленькие - может быть Алгоритм Нейгла и задержанный алгоритм ACK Ваша головная боль? Из того, что вы описали, думаете, что Задержка ACK ...