Winsock: Was passiert, wenn man zu viel sendet?

[Belli]

Oh wow ... das ändert natürlich alles ...

[hustbaer]

Mit "completion packet" meinst du eine Benachrichtigung über einen IO Completion Port, oder? Falls nicht, vergiss den Rest der jetzt folgt.

Hi schrieb:

Ähh, also hat das completion packet nun doch nix mit dem ACK vom Empfänger zu tun?

Richtig, hat es nicht. Macht auch Sinn. Sonst müsste man u.U. recht lange darauf warten.
Du bekommst die Completion-Notification (über welchen Mechanismus auch immer) genau zu dem Zeitpunkt zu dem ein synchrones, blockierendes send() zurückkommen würde.
Im Prinzip bedeutet dass nur, dass du deinen Sende-Puffer jetzt wieder freigeben/überschreiben darfst.

Die Completion-Notification bedeutet nichtmal, dass die Daten schon versendet wurden. Die können zu dem Zeitpunkt noch in Puffern der Netzwerkkarte stehen. Bzw. sogar in Puffern des Betriebssystems, so dass noch nichtmal die Netzwerkkarte was davon mitbekommen hat.

Anders wäre z.B. Send-Coalescing nicht möglich (siehe z.B. Nagle's Algorithm).

Bekommt man es also, sobald die Daten transportiert wurden, und nicht erst, wenn der Empfänger empfangen hat?

Nö, normalerweise sogar noch früher, siehe oben.

Dann würden die Pakete also auch verworfen (Irgendwo bei den Providern wohl) werden, könnte der Empfänger nicht schnell genug empfangen?!

Jain.

Zu dem Zeitpunkt wo die Completion-Notification bekommst, ist nicht garantiert, dass der Empfänger die Daten bereits empfangen hat, oder jemals empfangen wird.
Es ist allerdings garantiert, dass, WENN die Verbindung nicht abbricht, er die Daten irgendwann bekommen wird. Und zwar alle Daten, und auch genau in der Reihenfolge in der sie gesendet wurden.

Dazu puffert der TCP/IP Stack vom Sender die Daten im RAM. Wenn die zu sendenden Daten auf dem Weg zum Epfänger ganz oder teilweise verloren gehen, dann sendet der TCP/IP Stack sie einfach nochmal. Und nochmal und nochmal, so lange bis alles angekommen ist. Das ganze passiert völlig transparent, d.h. du brauchst dich darum nicht zu kümmern. z.B. werden die Daten aus dem Puffer des Programms in einen Puffer des TCP/IP Stacks kopiert, bevor die Completion-Notification geschickt wird. Dadurch darfst das Programm "seinen" Puffer sofort nach der Completion-Notification überschreiben, ohne dass das "Neu-Versenden" von Daten dadurch beeinträchtigt wird.

Und nochmal zu "könnte der Empfänger nicht schnell genug empfangen": der TCP/IP Stack des Senders puffert nur eine begrenzte Menge an Daten. Die Daten werden aus den internen Puffern des TCP/IP Stacks erst dann entfernt, wenn der Empfänger sie bestätigt hat (ACK). Daraus folgt, dass wenn der Sender schneller senden will als der Empfänger empfangen kann, send() irgendwann anfängt zu blockieren (bzw. die Completion-Notification erst später zu schicken). Anders gesagt: das System stellt sicher, dass du einfach nicht schneller senden kannst, als der Empfänger empfangen kann. Wenn du es versuchst, bremst es dich entsprechend aus.

[Hi]

Danke SEHR!