Viele Fragen zu WinSock...
-
Ok danke, bleiben noch 3 Fragen.
MfG,
Der Netzwerknoob
-
Öh sorry, eigentlich ... brauche ich nur ein ordentliches Tutorial...
MfG,
Der Netzwerknoob
-
Wie ist das mit AcceptEx(), muss ich das so machen:
Einmal beim Start des Programmes, und dann immer bei GetQueuedCompletionStatus() und OP_ACCEPT gleich ein neues AcceptEx() aufrufen?
Gibt es da dann keine Lücke, wo ein Client keine acception bekommt?MfG,
Der Netzwerknoob
-
Die Listen Queue ist doch auch noch da.
-
Ich weiß nicht, was du meinst.
MfG,
Der Netzwerknoob
-
Und für WSARecv() muss ich das dann doch auch so machen. Wie kann das performant sein? Wenn es fertig ist, ein neues WSARecv() aufrufen usw...
MfG,
Der Netzwerknoob
-
Netzwerknoob schrieb:
Einmal beim Start des Programmes, und dann immer bei GetQueuedCompletionStatus() und OP_ACCEPT gleich ein neues AcceptEx() aufrufen?
Gibt es da dann keine Lücke, wo ein Client keine acception bekommt?Windows puffert für die die eingehenden Verbindungen, auch wenn gerade kein accept ausständig ist.
-
[quote="Badestrand"]
Zu "send":
MSDN schrieb:
If no error occurs, send returns the total number of bytes sent, which can be less than the number indicated by len.
Das geht noch weiter. Ganz versteckt in einem kleinen Satz heißt es:
MSDN schrieb:
On nonblocking stream oriented sockets, the number of bytes written can be between 1 and the requested length ...
Wenn man mit einem blockierenden Socket send aufruft, wird immer alles gesendet. Im Gegensatz dazu kommt nicht zwangsläufig bei einem recv auch alles gesendete an.
-
ad send()...
Die Doku ist da leider sehr unklar.
Es macht aber jede Implementierung die ich kenne so, dass bei blocking Sockets immer alles gesendet wird (solange die Verbindung nicht abbricht). Und es gibt tonnenweise Programme die sich genau darauf verlassen, also kann es auch kaum eine Implementierung anders machen, weil dann viele Programme nichtmehr funktionieren würden.Man kann aber, wenn man "defensiv" programmieren will, auch davon ausgehen, dass send() evtl. nicht alles sendet, und send() dann einfach selbst nochmal aufrufen (mit verschobenem Zeiger und reduziertem "count"). So lange bis alles gesendet wurde.
Sollte aber wie gesagt nicht nötig sein.
p.S.: @Belli: ich will dir damit nicht widersprechen, ich teile deine Auslegung der Doku. Ich finde die Doku nur trotzdem reichlich unklar/unglücklich formuliert.
-
Mhm, mhm, schön wäre ne Aufstellung von Send/Receive bei UDP/TCP blocking/non-blocking, bitte von jemandem, der es weiß. Und gilt das dann auch für WSASend() usw.. und auch für completion ports?
Nochmal wegen completion ports. Soll ich jetzt immer soviele AcceptEx()'s, WSARecv()'s, .. im port haben, wie es Prozessorkerne gibt, +1?
Also bei zwei Kernen bei Programmstart jeweils drei der Funktionen aufrufen und dann drei Worker-Threads starten? So hab ich das jetzt verstanden...MfG,
Der Netzwerknoob
-
hier gibts nen ganz guten Einstieg in die Socket-programmierung... (hauptsächlich tcp) also wens interessiert:
http://www.c-worker.ch/tuts.php
-
Danke, kenn ich schon.
Jetzt interessieren mich die completion ports.MfG,
Der Netzwerknoob
-
Mhm, mhm, schön wäre ne Aufstellung von Send/Receive bei UDP/TCP blocking/non-blocking, bitte von jemandem, der es weiß.
Und vermutlich noch mit Sahne und Zucker oben drauf, ne?

- Lern Dokus Lesen
- Lern Englisch
- Lern englische Dokus Lesen
- Stell konkrete Fragen, und verkneif dir sowas wie "ey macht mir mal ne Aufstellung über blubb aber bitte nur von jmd. der wirklich Ahnung hat und ein bisschen plötzlich wenns Recht ist"
-
Fühl dich nicht angegriffen.

Ich hab halt nix von "afaik" und "glaube".
NO OFFENSE
-
Du hast mich etwas falsch verstanden. Ich wollte eigentlich sagen: RTFM!
-
Du sagst doch selbst, dass die Doku unklar ist.
-
Bezogen auf den einen Punkt, ja.
Und?
Deswegen liest man sie am besten gleich garnicht?
-
Nein. Habe sehr viel gelesen, aber beinahe nix kapiert. Deshalb frage ich hier.
-
Für TCP gilt:
blockierender Socket:
send sendet alles, recv muß solange aufgerufen werden, bis alles angekommen ist.
nicht blockierender Socket:
send muß aufgerufen werden, bis alles gesendet ist, recv siehe oben.Für UDP kann ich keine Aussage treffen.
-
Bei WSASend ist es aber sehr klar geschrieben:
... Given the same buffer situation and a blocking socket, WSASend will block until all of the application buffer contents have been consumed.