Was kann ich tun, um TCP Zero Window/TCP Window Full auf der Empfängerseite zu vermeiden?

Question

Ich habe eine kleine Anwendung, die Dateien über das Netzwerk an einen Agenten auf einem Windows-Betriebssystem sendet.

Wenn diese Anwendung unter Windows ausgeführt wird, funktioniert alles einwandfrei, die Kommunikation ist OK und die Dateien werden alle erfolgreich kopiert.

Aber wenn diese Anwendung unter Linux läuft (RedHat 5.3, der Empfänger ist immer noch Windows) - Ich sehe in Wireshark Netzwerk-Trace-Nachrichten von TCP Zero Window und TCP Window Full, um alle 1-2 Sekunden erscheinen. Der Agent schließt die Verbindung nach einigen Minuten.

Der Windows-Linux-Code ist fast der gleiche und ziemlich einfach. Die einzige nicht-triviale Operation ist setsockopt mit SO_SNDBUF und dem Wert von 0xFFFF. Das Entfernen dieses Codes hat nicht geholfen.

Kann mir bitte jemand mit diesem Problem helfen?

EDIT: Hinzufügen des Senden Code - es sieht aus, dass es richtig Teil schreibt Griffe:

int totalSent=0; 
while(totalSent != dataLen) 
{ 
    int bytesSent 
     = ::send(_socket,(char *)(data+totalSent), dataLen-totalSent, 0); 

    if (bytesSent ==0) { 
     return totalSent; 
    } 
    else if(bytesSent == SOCKET_ERROR){ 
#ifdef __WIN32 
     int errcode = WSAGetLastError(); 
     if(errcode==WSAEWOULDBLOCK){ 
#else 
      if ((errno == EWOULDBLOCK) || (errno == EAGAIN)) { 
#endif 
      } 
      else{ 
       if(!totalSent) { 
        totalSent = SOCKET_ERROR; 
       } 
       break; 
      } 
     } 
     else{ 
      totalSent+=bytesSent; 
     } 
    } 
} 

Vielen Dank im Voraus.

Answer 1

Ich habe versucht Nagles Algorithmus (mit TCP_NODELAY) zu deaktivieren, und irgendwie hat es geholfen. Die Übertragungsrate ist viel höher, die TCP-Fenstergröße ist nicht voll oder zurückgesetzt. Die seltsame Sache ist, dass, wenn ich die Fenstergröße gecheckt hatte, hatte es keinen Einfluss.

Vielen Dank.

Answer 2

Das wahrscheinlichste Problem ist, dass Sie einen Fehler in Ihrem Code haben, wo Sie nicht teilweise Lesevorgänge oder partielle Schreibvorgänge korrekt behandeln. Es ist bekannt, dass TCP zwischen Linux und Windows funktioniert.

Answer 3

Ein häufiger Fehler beim Entwickeln mit TCP Sockets ist eine falsche Annahme über das read()/write() Verhalten.

Wenn Sie eine Lese-/Schreiboperation ausführen, müssen Sie den Rückgabewert überprüfen, sie müssen die angeforderten Bytes möglicherweise nicht lesen/schreiben, Sie benötigen normalerweise eine Schleife, um den Überblick zu behalten und sicherzustellen, dass die gesamten Daten übertragen wurden.

Answer 4

Wenn Sie Ihren Code nicht sehen, muss ich raten.

Der Grund, warum Sie ein Zero-Fenster in TCP erhalten, liegt darin, dass im Recv-Puffer des Empfängers kein Platz ist.

Es gibt eine Reihe von Möglichkeiten, wie dies auftreten kann. Eine häufige Ursache für dieses Problem ist, wenn Sie über ein LAN oder eine andere relativ schnelle Netzwerkverbindung senden und ein Computer wesentlich schneller ist als der andere Computer. Als ein extremes Beispiel, sagen Sie, dass Sie einen 3Ghz-Computer haben, der so schnell wie möglich über ein Gigabit-Ethernet zu einem anderen Computer sendet, der eine 1-GHz-CPU betreibt. Da der Sender viel schneller senden kann, als der Empfänger lesen kann, füllt sich der recv-Puffer des Empfängers, was bewirkt, dass der TCP-Stapel dem Absender ein Zero-Fenster ankündigt.

Nun kann dies Probleme sowohl auf der Sende- als auch auf der Empfangsseite verursachen, wenn sie nicht beide bereit sind, damit umzugehen. Auf der sendenden Seite kann dies dazu führen, dass der Sendepuffer voll wird, und Aufrufe, um entweder zu blockieren oder fehlzuschlagen, wenn Sie nicht blockierende E/A verwenden. Auf der Empfängerseite könnten Sie so viel Zeit mit I/O verbringen, dass die Anwendung keine Möglichkeit hat, irgendwelche ihrer Daten zu verarbeiten und den Anschein zu erwecken, eingesperrt zu sein.

bearbeiten

Von einigen Ihrer Antworten und Code klingt es wie Ihre Anwendung Gewinde Single ist und Sie versuchen, nicht-Blocking aus irgendeinem Grund sendet zu tun. Ich nehme an, dass Sie den Socket in einem anderen Teil des Codes auf Nicht-Blockieren setzen.

Generell würde ich sagen, dass dies keine gute Idee ist. Wenn Sie befürchten, dass Ihre App auf send(2) hängt, sollten Sie idealerweise eine lange Zeitüberschreitung für den Socket unter Verwendung von setsockopt festlegen und einen separaten Thread für das eigentliche Senden verwenden.

Siehe socket(7):

SO_RCVTIMEO und SO_SNDTIMEO die Empfangs Geben oder das Versenden von Timeouts, bis ein Fehler meldet. Der Parameter ist ein Strukturzeitval. Wenn eine Eingangs- oder Ausgangsfunktion für diese Zeitspanne sperrt und Daten gesendet oder empfangen wurden, wird der Rückgabewert diese Funktion die Menge der übertragenen Daten sein; Wenn keine Daten übertragen wurden und das Zeitlimit erreicht wurde, wird -1 zurückgegeben, wobei errno auf EAGAIN oder EWOULDBLOCK gesetzt ist, genauso wie , wenn der Socket als nicht blockierend festgelegt wurde. Wenn das Zeitlimit auf Null (Standardeinstellung) gesetzt ist, wird die Operation niemals ablaufen.

Ihr Hauptthread kann jede Dateideskriptor in ein queue drücken, um einen Schub für Mutex Warteschlange Zugriff mit sagen, beginnt dann 1 - N Threads die tatsächlichen zu tun Senden I unter Verwendung von blockierenden/O mit Timeouts senden.

Ihre Sendefunktion sollte wie folgt aussehen (vorausgesetzt, Sie ein Timeout sind Einstellung):

// blocking send, timeout is handled by caller reading errno on short send 
int doSend(int s, const void *buf, size_t dataLen) {  
    int totalSent=0; 

    while(totalSent != dataLen) 
    { 
     int bytesSent 
      = send(s,((char *)data)+totalSent, dataLen-totalSent, MSG_NOSIGNAL); 

     if(bytesSent < 0 && errno != EINTR) 
      break; 

     totalSent += bytesSent; 
    } 
    return totalSent; 
} 

Die MSG_NOSIGNAL Flagge stellt sicher, dass Ihre Anwendung nicht durch das Schreiben an eine Steckdose getötet wird, der geschlossen worden ist oder zurückgesetzt durch den Peer. Manchmal werden E/A-Vorgänge durch Signale unterbrochen, und die Überprüfung auf EINTR ermöglicht es Ihnen, die send neu zu starten.

Im Allgemeinen sollten Sie doSend in einer Schleife mit Datenbrocken der TCP_MAXSEG Größe aufrufen.

Auf der Empfangsseite können Sie eine ähnliche blockierende recv-Funktion schreiben, die ein Timeout in einem separaten Thread verwendet.