Conversation between python tpp server and c ++ client

Question

I had a problem trying to communicate between a python TCP server and a C ++ TCP client. After the first call, which works fine, subsequent calls cause problems.

As for WinSock, the send () function works correctly, it returns the correct length, and WSAGetLastError () does not return anything meaningful.

However, observing packets using wirehark, I notice that the first call sends two packets, PSH, ACK with all the data in it and ACK immediately after, but subsequent calls that do not work send only the PSH, ACK packet, not the next ACK package

wireshark host computers confirm this, and the python server does nothing, it has no data coming out of the socket, and I cannot debug it deeper, since socket is a native class

when I start the C ++ client and C ++ server (a hacked replica of what python will do), the client correctly sends both PSH, ACk, and ACK packets all the time even after the first call.

Is the winsock send function supposed to always send PSH, ACK, and ACK? If yes, then why do this when connecting to my C ++ server and not to the python server? Has anyone had problems like this?

Answer 1

Client

sends PSH, ACK, and then the server sends PSH, ACK and FIN, PSH, ACK

There is FIN, so could it be that the version of your Python server closes the connection right after the initial read?

If you do not explicitly close the server socket, is it possible that the remote server socket server goes out of scope, thereby closing it (and this error is absent in your C ++ version)?

Assuming this is so, I can call a very similar TCP sequence with this code for the server:

# 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 second packet sleep(10) 

and this is for the client:

 # 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') 

Run the batch sniffer, then run server.py and then client.py. Here is an excerpt from tcpdump -A -i lo that matches your observations:

 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

What packet size do you send?

If they are small - maybe the Nagle algorithm and the Delayed ACK algorithm - is this your headache? From what you described, the Delayed ACK is involved ...