parlando tra python tcp server e un client c ++

Question

Sto riscontrando un problema nel tentativo di comunicare tra un server TCP python e un client TCP c ++. Dopo la prima chiamata, che funziona correttamente, le chiamate successive causano problemi.

Per quanto riguarda WinSock, la funzione send () ha funzionato correttamente, restituisce la lunghezza corretta e WSAGetLastError () non restituisce nulla di significativo.

Tuttavia, quando guardo i pacchetti usando WireShark, noto che la prima chiamata invia due pacchetti, un PSH, ACK con tutti i dati al suo interno e un ACK subito dopo, ma le chiamate successive, che non funzionano , invia solo il pacchetto PSH, ACK e non un pacchetto ACK successivo

il wirehark dei computer riceventi lo conferma, e il server Python non fa nulla, non ha alcun dato che esce dal socket e non posso eseguire il debug più in profondità, poiché socket è una classe nativa

quando eseguo un client c ++ e un server c ++ (una replica compromessa di ciò che farebbe un python), il client invia fedelmente sia i pacchetti PSH, ACk e ACK per tutto il tempo, anche dopo la prima chiamata.

Si suppone che la funzione di invio di winsock invii sempre un PSH, un ACK e un ACK? In tal caso, perché dovrebbe farlo quando è collegato al mio server C ++ e non al server Python? Qualcuno ha avuto problemi simili a questo?

Answer 1

  

il client invia un PSH, ACK e quindi il   il server invia un PSH, ACK e un   FIN, PSH, ACK

Esiste un FIN, quindi potrebbe essere che la versione Python del tuo server stia chiudendo la connessione immediatamente dopo la lettura iniziale?

Se non si sta chiudendo esplicitamente il socket del server, è probabile che la variabile del socket remoto del server esca dall'ambito, quindi chiudendolo (e che questo errore non è presente nella versione C ++)?

Supponendo che sia così, posso causare una sequenza TCP molto simile con questo codice per il 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's second packet
sleep(10)

e questo per il 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')

Avvia lo sniffer di pacchetti, quindi esegui server.py e quindi client.py. Ecco il ritaglio di tcpdump -A -i lo , che corrisponde alle tue osservazioni:

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

Che dimensione dei pacchetti invii?

Se sono piccoli - possono essere Algorith di Nagle & amp; Algoritmo ACK ritardato è il tuo mal di testa? Da quello che hai descritto pensa che sia coinvolto l'ACK ritardato ...