Kurze Win-Sock Frage
-
plotzen schrieb:
Das hat nichts mit non-blocking I/O zu tun. Das ist immer bei TCP so. Man muss so programmieren das es auch funktioniert wenn recv nur 1 Byte holt.
Ok, genau da war ich mir unsicher. Durch Testen kam ich zu der Annahme, dass recv exakt die Nachricht empfaengt die mit send gesendet wurde, aber das scheint wohl nicht so zu sein.
Noch was: Wenn mein Puffer zu klein fuer die Nachricht ist, was passiert mit den restlichen Daten? Gehen die verloren, oder kommen die beim naechsten recv Aufruf in den naechsten Puffer ?
-
Chase schrieb:
Ok, genau da war ich mir unsicher. Durch Testen kam ich zu der Annahme, dass recv exakt die Nachricht empfaengt die mit send gesendet wurde, aber das scheint wohl nicht so zu sein.
das ist z.b. bei udp so (paketorientiert). tcp ist eine art 'streaming protocol'. aus sichtweise der anwendung sind es byte-ströme, keine pakete. das kannste dir ungefähr so vorstellen als würdest du dateien auf der festplatte lesen oder schreiben. das programm, das eine datei öffnet und was rausliest, weiss nicht, wieviele bytes ein anderes programm da reingeschrieben hat. datenträger sind auch 'paketorientiert' (sektoren etc.) aber das filesystem nacht daraus datenströme...
Chase schrieb:
Noch was: Wenn mein Puffer zu klein fuer die Nachricht ist, was passiert mit den restlichen Daten? Gehen die verloren, oder kommen die beim naechsten recv Aufruf in den naechsten Puffer ?
der tcp-stack hat intern einen eigenen buffer. wenn der volläuft, sagt dein tcp der gegenstelle, dass sie langsamer/weniger senden soll bis hin zum stillstand. wenn dein programm aus diesem puffer was ausliest, wird der platz wieder frei und es können ein paar neue bytes empfangen werden.
-
Ist es "legitim" staendig zwischen blocking und nonblocking zu wechseln ? Also wenn ich sende moechte ich das meine Anwendung blockt (daher wartet bis auch wirklich alles raus ist) und sich dann erst darum kuemmert ob es was zu empfangen gibt.
Dummerweise hab ich noch ein kleines Problem mit einem nicht blockierenden receive: Irgendwie wird immer die gleiche Nachricht aus dem Puffer geholt, dieser wird aber nicht geleert. Kann mir das jemand erklaeren ?
-
Dummerweise hab ich noch ein kleines Problem mit einem nicht blockierenden receive: Irgendwie wird immer die gleiche Nachricht aus dem Puffer geholt, dieser wird aber nicht geleert. Kann mir das jemand erklaeren ?
das kann nur passieren wenn du bei recv MSG_PEEK angibst
-
Bei Flags hab ich bisher einfach NULL angegeben und hat auch so geklappt.
-
wenn im buffer immer das gleiche steht hat wohl recv nichts gelesen. hast du den rückgabewert überprüft? vielleicht ist er SOCKET_ERROR.
-
Nein, der Rueckgabewert ist != SOCKET_ERROR. Der Buffer wird auch jedesmal genullt, es wird tatsaechlich immer wieder das Gleiche gelesen, der Server sendet auch sicher nur einmal.
Edit:
Dummer Fehler: Es hat sich eine unsigned Variable zum Speichern des Rueckgabewertes von recv eingeschlichen
-
Was spricht denn gegen 2 Threads. Einen zum Senden und einen zum Empfangen.
Dann kann man sich diese ganze Frickelei mit nicht blockierenden Aufrufen sparen.
(Das Blockieren ist ja grade das Gute, das dann keine cpu power sinnlos verbraten wird)
-
plotzen schrieb:
Du kannst dich aber bei nonblocking IO nicht darauf verlassen dass eine ganze Nachricht auf einmal eintrifft, ggf. musst du diese selbst Stückweise zusammenbasteln bis sie fertig ist, es kann sein dass du 10kB auf einmal wegschickst, die Gegenseite aber erstmal 1k empfängt, dann nochmal 5, dann mal wieder eines, und dann die restlichen 3.
Das hat nichts mit non-blocking I/O zu tun. Das ist immer bei TCP so. Man muss so programmieren das es auch funktioniert wenn recv nur 1 Byte holt.
Ok, sorry, mein Fehler. Ja, kann bei sockets auch bei blocking io passieren.
EDIT: @MisterX: gegen 2 threads spricht das was immer gegen threads spricht, nämlich dass threads kompliziert sind und man schnell fehler machen kann ohne es gleich zu bemerken.
-
hustbaer schrieb:
EDIT: @MisterX: gegen 2 threads spricht das was immer gegen threads spricht, nämlich dass threads kompliziert sind und man schnell fehler machen kann ohne es gleich zu bemerken.
Naja, einen seperaten Thread braucht man meistens ja sowieso. Nicht jede Anwendung beruht vollkommen auf Events, die Hauptanwendung muss laufen koennen ohne von der Netzkommunikation abhaengig zu sein. Ich wollte nur irgendwie vermeiden zwei Threads (also 3 mit main) benutzen zu muessen. Meine Methode (send blockiert, recv blockiert nicht) klappt auf den ersten Blick ganz gut..
-
Chase schrieb:
Meine Methode (send blockiert, recv blockiert nicht) klappt auf den ersten Blick ganz gut..
naja, hoffentlich hast du keine gui-anwendung. wenn 'send' erstmal blockiert, sind deine fensterchen eingefroren...
-
net schrieb:
Chase schrieb:
Meine Methode (send blockiert, recv blockiert nicht) klappt auf den ersten Blick ganz gut..
naja, hoffentlich hast du keine gui-anwendung. wenn 'send' erstmal blockiert, sind deine fensterchen eingefroren...
Seperater Thread :p
-
Hm. Wenn man mit non-blocking io, completion ports etc. arbeitet kommt man eigentlich oft mit einem thread aus.
