[VS60] GetQueuedCompletionStatus(): (falsche) Anzahl an übertragenen Bytes
Hallo Zusammen!
Hab da ein Problem, bzw. eher eine Frage zu o.g. Funktion.
Per Definition
Code:
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.
