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.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

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

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.

Datengröße ist 4k, TCP[/IP] macht das aber wie es soll. Zerfetzen und wieder zusammenbauen.

Dafür gibt's ja verbindungsorientierte Protokolle.

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!

Hab auch in keinster Weise daran gezweifelt.

Hä? Warum hast du dann diesen Thread erstellt?

Scheint aber nicht der Fall zu sein.

Grüße,
m.

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.

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.