Kurze Win-Sock Frage
-
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.
