[VS60] GetQueuedCompletionStatus(): (falsche) Anzahl an übertragenen Bytes
-
Hallo Zusammen!
Hab da ein Problem, bzw. eher eine Frage zu o.g. Funktion.
Per Definition
BOOL GetQueuedCompletionStatus( HANDLE CompletionPort, // the I/O completion port of interest LPDWORD lpNumberOfBytesTransferred, // to receive number of bytes // transferred during I/O LPDWORD lpCompletionKey, // to receive file's completion key LPOVERLAPPED *lpOverlapped, // to receive pointer to OVERLAPPED // structure DWORD dwMilliseconds // optional timeout value );gibt der Parameter lpNumberOfBytesTransferred die Anzahl der übertragenen Bytes zurück wenn die Funktion zurückkehrt oder das timeout zuschlägt. (Auf die genaue Implementierung der I/O-CompletionPorts einzugehen würd sich glaub ich a bissal ziehen...Nur so viel: klappt wunderbar und das schon einige Zeit.)
Das klappt auch alles wunderbar so lange ich mich im LAN bewege (Server/Client klappt auch einwandfrei). Sobald ich Daten über's Internet verschicke, kommt es ab und an (ja, ich hab noch nicht rausbekommen an was es genau liegt) vor, das die Methode mit nur einem Teil der Bytes (ca. 60%) zurückkehrt. Mit dem nächsten Completion der Rest der Daten.
Auf der Gegenseite (Sender) hab ich bereits sichergestellt, dass auch immer die komplette Datenmenge auf die Reise geschickt wird. Anhand eines Parameter im Paket kann ich feststellen, ob noch was fehlt oder ob schon alles angekommen ist und reagiere dementsprechend. (Sollte aber eigentlich nicht passieren, da TCP[/IP] das eigentlich regelt.)
Die Frage ist daher nicht, wie ich es erreiche, dass nur die komplette Anzahl der Daten bearbeitet wird, sondern warum das Ding völlig irrational in ca. 90% der Fälle mit den kompletten Daten aufwacht und manchmal nur mit einem Teil.
Hat wer eine Ahnung/Tip?
Grüße,
m.PS: Datengröße ist 4k, TCP[/IP] macht das aber wie es soll. Zerfetzen und wieder zusammenbauen.
PPS: Ein Code-BSP muss glaub ich ned sein, is fast identisch mit einschlägigen Win-BSPs.
PPPS: Hätte das eher in WinAPI rein sollen? Dann entschuldige ich mich jetzt schon.
-
Dieser Thread wurde von Moderator/in CStoll aus dem Forum MFC (Visual C++) in das Forum WinAPI verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Was für einen Wert hast du denn als Timeout angegeben? Vielleicht hat die Übertragung der Daten einfach zu lange gedauert und irgendwo in der Mitte hat die Funktion wegen TimeOut abgebrochen.
m.trix schrieb:
PPPS: Hätte das eher in WinAPI rein sollen? Dann entschuldige ich mich jetzt schon.
Kein Problem - das lässt sich mit ein paar Mausklicks beheben
-
Dann hat mich meine Vermutung mit WinAPI also doch nicht getäuscht. Sollte öfter mal auf mich hören.
Timeout is auf INFINITE gesetzt. Aber ich denkmal das man das ausschließen kann. Hab zwar kein fibre backbone, aber schnell genug isses allemal. Zum mal der Rest der Daten unmittelbar mit dem nächsten Completion kommt.
Hab auch schon sämtliche Daten-Puffer überprüft ob da irgendwo der Hund drin ist. Aber die Größen passen alle. Die Methode kommt aus irgendeinem Grund nur mit einem Teil der Daten aus dem 'Winterschlaf'.
Wie schon gesagt, der gesamte Kommunikations-Apparat ist schon länger in Betrieb und klappt auch ohne Aussetzer. Dieses 'Phänomen' ist im LAN nicht präsent, über Internet mal so, mal so, mal bei dem Paket, mal bei dem. Wenn ich da wenigstens ein Muster erkennen könnte...
Danke schonmal für
a) die freundliche Zurechtweisung.
b) deinen Tip.Grüße,
m.
-
Das ist bei TCP völlig normal und lässt sich auch nicht ändern.
-
Hab auch in keinster Weise daran gezweifelt.
Datengröße ist 4k, TCP[/IP] macht das aber wie es soll. Zerfetzen und wieder zusammenbauen.
Dafür gibt's ja verbindungsorientierte Protokolle.
-
Verbindungsorientieter Protokolle sichern die *Verbindung*.
Die Daten kommen damit *zuverlässig* an.ABER: Wenn Du z.B: 1000 Bytes wegschickst, dann kann auf der Empfängerseite folgendes ankommen, 1 Byte, 9 Byte, 90 Byte, 500 Byte, 400 Byte
Es kommen also auch 1000 Bytes an, aber eben in Häppchen!
-
m.trix schrieb:
Hab auch in keinster Weise daran gezweifelt.
Hä? Warum hast du dann diesen Thread erstellt?
-
Weil ich die irrsinnige Vermutung habe/hatte, dass die o.g. Funktion erst zurückkehrt, wenn alle Bytes komplett übertragen sind.
Scheint aber nicht der Fall zu sein.
Grüße,
m.
-
is auch schlecht dokumentiert
-
Nö.
recv:
For connection-oriented sockets (type SOCK_STREAM for example), calling recv will return as much data as is currently available—up to the size of the buffer specified.
WSARecv:
For byte stream-style sockets (for example, type SOCK_STREAM), incoming data is placed into the buffers until the buffers are filled, the connection is closed, or the internally buffered data is exhausted. Regardless of whether or not the incoming data fills all the buffers, the completion indication occurs for overlapped sockets.
-
Ok, ok. Dann hat sich das jetzt von selbst erklärt. Mal wieder einfach drübergelesen. Danke für die Hilfe!
Aber nochwas, da ich da vllt. auch im Dunkeln tappe oder im Studium mal wieder geschlafen hab:
Wenn TCP mein 1000 Byte auseinanderreisst, dann kann ich schon davon augehen, dass ich mich nicht noch um die Reihenfolge kümmern muss? Die Bytes sind dann schon in der ursprünglichen Reihenfolge?Grüße,
m.
-