Aus der Steckdose lesen: Ist garantiert, dass mindestens x Bytes gelesen werden?

Question

Ich habe einen seltenen Fehler, der beim Lesen einer Steckdose aufzutreten scheint.

Es scheint, dass ich beim Lesen von Daten manchmal nur 1-3 Bytes eines Datenpakets erhalte, das größer als dieses ist.

Wie ich aus der Pipe-Programmierung gelernt habe, erhalte ich dort immer mindestens 512 Bytes, solange der Absender genügend Daten bereitstellt.

Außerdem überträgt mein Sender jedes Mal, wenn er etwas sendet, mindestens >= 4 Bytes - ich dachte also, dass am Anfang (!!) der Übertragung mindestens 4 Bytes auf einmal empfangen werden.

In 99,9% aller Fälle scheint meine Annahme zuzutreffen ... aber es gibt wirklich seltene Fälle, in denen weniger als 4 Bytes empfangen werden. Es erscheint mir lächerlich, warum das Netzwerksystem dies tun sollte?

Weiß jemand mehr?

Hier ist der von mir verwendete Lesecode:

mySock, addr = masterSock.accept()
mySock.settimeout(10.0)
result = mySock.recv(BUFSIZE)
# 4 bytes are needed here ...
...
# read remainder of datagram
...

Der Absender sendet das komplette Datagramm mit einem Aufruf von send.

Edit: das Ganze funktioniert auf localhost - es sind also keine komplizierten Netzwerkanwendungen (Router etc.) beteiligt. BUFSIZE ist mindestens 512 und der Absender sendet mindestens 4 Bytes.

Answer 1

Ich nehme an, Sie verwenden TCP. TCP ist ein auf Datenströmen basierendes Protokoll, das keine Vorstellung von Paketen oder Nachrichtengrenzen hat.

Das bedeutet, dass Sie beim Lesen möglicherweise weniger Bytes erhalten, als Sie angefordert haben. Wenn Ihre Daten zum Beispiel 128k groß sind, erhalten Sie beim ersten Lesen nur 24k und müssen erneut lesen, um den Rest der Daten zu erhalten.

Für ein Beispiel in C:

int read_data(int sock, int size, unsigned char *buf) {
   int bytes_read = 0, len = 0;
   while (bytes_read < size && 
         ((len = recv(sock, buf + bytes_read,size-bytes_read, 0)) > 0)) {
       bytes_read += len;
   }
   if (len == 0 || len < 0) doerror();
   return bytes_read;
}

Answer 2

Soweit ich weiß, ist dieses Verhalten durchaus vernünftig. Steckdosen können, und wahrscheinlich wird Ihre Daten bei der Übertragung fragmentieren. Sie sollten auf solche Fälle vorbereitet sein, indem Sie geeignete Pufferungstechniken anwenden.

Andererseits, wenn Sie die Daten auf dem localhost übertragen und Sie tatsächlich nur 4 Bytes erhalten, bedeutet dies wahrscheinlich, dass Sie irgendwo anders in Ihrem Code einen Fehler haben.

EDIT: Eine Idee - versuchen Sie, einen Packet Sniffer zu starten und zu sehen, wann das übertragene Paket voll ist oder nicht; dies könnte Ihnen einen Einblick geben, wann der Fehler in Ihrem Client oder in Ihrem Server liegt.

Answer 3

Die einfache Antwort auf Ihre Frage "Von Socket lesen: Ist garantiert, dass mindestens x Bytes gelesen werden?", lautet keine . Schauen Sie sich die Doku-Strings für diese Socket-Methoden an:

>>> import socket
>>> s = socket.socket()
>>> print s.recv.__doc__
recv(buffersize[, flags]) -> data

Receive up to buffersize bytes from the socket.  For the optional flags
argument, see the Unix manual.  When no data is available, block until
at least one byte is available or until the remote end is closed.  When
the remote end is closed and all data is read, return the empty string.
>>> 
>>> print s.settimeout.__doc__
settimeout(timeout)

Set a timeout on socket operations.  'timeout' can be a float,
giving in seconds, or None.  Setting a timeout of None disables
the timeout feature and is equivalent to setblocking(1).
Setting a timeout of zero is the same as setblocking(0).
>>> 
>>> print s.setblocking.__doc__
setblocking(flag)

Set the socket to blocking (flag is true) or non-blocking (false).
setblocking(True) is equivalent to settimeout(None);
setblocking(False) is equivalent to settimeout(0.0).

Daraus wird deutlich, dass recv() ist nicht verpflichtet, so viele Bytes zurückzugeben, wie Sie angefordert haben. Da Sie außerdem die Funktion settimeout(10.0) ist es möglich, dass einige, aber nicht alle Daten kurz vor Ablauf der Gültigkeitsdauer der Datenbank empfangen werden. recv() . In diesem Fall recv() gibt zurück, was es gelesen hat - und das wird weniger sein, als Sie verlangt haben (aber eine Konsistenz < 4 Bytes scheint unwahrscheinlich).

Sie erwähnen datagram in Ihrer Frage, was bedeutet, dass Sie (verbindungslose) UDP-Sockets (und nicht TCP) verwenden. Die Unterscheidung ist hier beschrieben . Der gepostete Code zeigt die Socket-Erstellung nicht, so dass wir hier nur raten können, aber dieses Detail kann wichtig sein. Es könnte helfen, wenn Sie ein vollständigeres Beispiel Ihres Codes posten könnten.

Wenn das Problem reproduzierbar ist, könnten Sie die Zeitüberschreitung deaktivieren (was Sie übrigens nicht zu tun scheinen) und sehen, ob das Problem dadurch behoben wird.

Answer 4

So funktioniert TCP nun einmal. Sie werden nicht alle Daten auf einmal erhalten. Es gibt einfach zu viele Zeitprobleme zwischen Sender und Empfänger, einschließlich des Betriebssystems des Senders, der Netzwerkkarte, der Router, der Switches, der Leitungen selbst, der Netzwerkkarte des Empfängers, des Betriebssystems usw. Es gibt Puffer in der Hardware und im Betriebssystem.

Sie können nicht davon ausgehen, dass das TCP-Netzwerk dasselbe ist wie eine OS-Pipe. Bei der Pipe handelt es sich um Software, so dass bei den meisten Nachrichten keine Kosten für die Übermittlung der gesamten Nachricht auf einmal anfallen. Bei einem Netzwerk müssen Sie davon ausgehen, dass es Zeitprobleme gibt, selbst in einem einfachen Netzwerk.

Aus diesem Grund kann recv() nicht alle Daten auf einmal liefern, da sie möglicherweise nicht verfügbar sind, selbst wenn alles richtig funktioniert. Normalerweise werden Sie recv() aufrufen und die Ausgabe abfangen. Das sollte Ihnen sagen, wie viele Bytes Sie erhalten haben. Wenn es weniger sind, als Sie erwarten, müssen Sie recv() so lange aufrufen (wie vorgeschlagen), bis Sie die richtige Anzahl von Bytes erhalten. Beachten Sie, dass recv() in den meisten Fällen bei einem Fehler -1 zurückgibt, überprüfen Sie dies und schauen Sie in Ihrer Dokumentation nach ERRNO-Werten. Vor allem EAGAIN scheint den Leuten Probleme zu bereiten. Wenn ich mich recht entsinne, bedeutet dies, dass im Moment keine Daten verfügbar sind und Sie es noch einmal versuchen sollten.

Außerdem klingt Ihr Beitrag so, als ob Sie sicher sind, dass der Absender die gewünschten Daten sendet, aber überprüfen Sie der Vollständigkeit halber Folgendes: http://beej.us/guide/bgnet/output/html/multipage/advanced.html#sendall

Sie sollten am Ende von recv() etwas Ähnliches tun, um partielle Empfänge zu behandeln. Wenn Sie eine feste Paketgröße haben, sollten Sie lesen, bis Sie die erwartete Datenmenge erhalten. Wenn Sie eine variable Paketgröße haben, sollten Sie lesen, bis Sie den Header haben, der Ihnen sagt, wie viele Daten Sie senden(), und dann so viel mehr Daten lesen.

Answer 5

Aus der Linux-Manpage von recv http://linux.about.com/library/cmd/blcmdl2_recv.htm :

Die Empfangsaufrufe geben normalerweise alle Daten zurück, und zwar bis zur angeforderten Menge, anstatt auf den den Empfang der gesamten angeforderten Menge zu warten.

Wenn Ihr Absender also noch Bytes sendet, gibt der Anruf nur das an, was bisher gesendet wurde.