werden netzwerkdaten gepuffert bevor recv ?

Reply to werden netzwerkdaten gepuffert bevor recv ? on Thu, 09 Jul 2009 15:44:26 GMT

howsthat — Thu, 09 Jul 2009 15:44:26 GMT

Hi Zusammen,

ähm.. ja.. eine kleine Verständnisfrage von mir:

Nehmen wir mal an, ich hätte ein Programm, das die Windows Sockets verwendet... (also mit den altbekannten Funktionen wie recv, send, sendto, listen, etc.)

...dann muss mir doch "Windows" (oder der zugrunde liegende Winsock Service Provider )solange die ankommenden Daten von TCP in einem "internen" Puffer speichern, bis ich sie mir schließlich mit recv() in meinen eigenen Programmbuffer rüberkopiere, oder ?
Was würde angenommen passieren, wenn ich ein Server-Socket erstelle, danach mit einem anderen Programm zu diesem Server hin-connecte und eine Menge Bytes an diesen sende, aber (!) die empfangenen Daten serverseitig nie mit recv() auslese ?

Dann müsste doch logischerweise irgendwann der "interne" Windows-Puffer irgendwann vollgeschrieben sein und keinen Datenempfang mehr zulassen, oder ?
Mir geht's nur grad darum, ob ich Daten verlieren könnte, wenn ich lange Zeit recv() nicht aufrufe, aber dauernd Daten über die Netzwerkleitung reinkommen...
verwirrt mich grad ein bisschen. Hoffe mein Text ist nicht allzu schwer zu parsen im Moment Vielleicht weiß ja noch jemand, wie groß dieser Puffer ist.

Schöne Grüße,
howsthat

Reply to werden netzwerkdaten gepuffert bevor recv ? on Thu, 09 Jul 2009 15:55:43 GMT

profezeih0r — Thu, 09 Jul 2009 15:55:43 GMT

ich würde sagen, die daten kommen paketweise an. holste ein paket nicht ab, kommt auch nicht das nächste an, usw.

Reply to werden netzwerkdaten gepuffert bevor recv ? on Thu, 09 Jul 2009 21:06:12 GMT

howsthat — Thu, 09 Jul 2009 21:06:12 GMT

ähm...nö XD
habs gerade mit einer einfachen Anwendnung ausprobiert.
Die Daten werden irgendwo abgespeichert, auch wenn ich sie nicht per recv() sofort auslese.
soweit ich weiß is tcp ja stream-basiert, d.h. die einzelnen packets werden auf der anderen seite zu einem endlosen fluss (engl. stream) wieder zusammengesetzt.
da dürfte dann auch nix fehlen an packets.
aber die grenzen des puffers würden mich mal interessieren.
ich mein'... ich werd ja wohl nicht komplette 10GB übertragen können ohne die auf der anderen seite jemals mit recv() abgeholt zu haben.

Reply to werden netzwerkdaten gepuffert bevor recv ? on Thu, 09 Jul 2009 21:21:47 GMT

Nanyuki — Thu, 09 Jul 2009 21:21:47 GMT

howsthat schrieb:

ich mein'... ich werd ja wohl nicht komplette 10GB übertragen können ohne die auf der anderen seite jemals mit recv() abgeholt zu haben.

Stimmt. Google einfach mal nach TCP window size.

Reply to werden netzwerkdaten gepuffert bevor recv ? on Thu, 09 Jul 2009 21:37:44 GMT

howsthat — Thu, 09 Jul 2009 21:37:44 GMT

yup, hab's genau 2 minuten nach meinem post auch gefunden
nennt sich "RWin" unter Wikipedia, die sog. Receive Window Size.

Weiß zufällig einer was passiert, wenn diese Empfangsfenstergröße überschritten wird ? Ich denke, ich werd's mal ausprobieren und versuchen, mehr als die maximalen 16 Kilobyte (unter Windows 2000 und XP) an einen Clientrechner zu senden.
Ich nehme mal an, nach weiteren Versuchen, Daten an den Rechner zu schicken, wird mir send() mit einem Fehlercode abschmieren, aber mal sehen...

Danke jedenfalls, Nanyuki !

MFG,
howsthat

Reply to werden netzwerkdaten gepuffert bevor recv ? on Thu, 09 Jul 2009 21:45:59 GMT

Badestrand — Thu, 09 Jul 2009 21:45:59 GMT

Du kannst es dir auch einfach machen und mit asynchronen Sockets (=nicht blockierend) arbeiten, dann bekommst du einfach Bescheid wenn du (wieder) senden kannst

Reply to werden netzwerkdaten gepuffert bevor recv ? on Thu, 09 Jul 2009 22:59:57 GMT

hustbaer — Thu, 09 Jul 2009 22:59:57 GMT

Ich denke, ich werd's mal ausprobieren und versuchen, mehr als die maximalen 16 Kilobyte (unter Windows 2000 und XP) an einen Clientrechner zu senden.

Die maximale Grösse ist AFAIK nicht 16KB, sondern einiges grösser. Aber egal.
Was passiert ist einfach: der empfangende PC verwirft die Daten, und teilt dem Sender mit, dass er nixmehr puffern kann. Der Sender puffert dann auf seiner Seite eine Zeit lang weiter, und wenn auch der "Sende Puffer" voll ist, dann fängt beim Sender an send() zu blockieren. Bzw. im nonblocking Mode liefert send() dann einfach EWOULDBLOCK.