Viele Fragen zu WinSock...

Aha ok super, danke!

Was ich nun bei Completion Ports nicht verstehe, ist, dass man anscheinend auf I/O, also beides, warten soll/kann?
Wie soll man auf einen Output warten? Ich dachte, damit wartet man, bis ein Client etwas schickt, also man wartet immer nur auf Input... Senden kann man doch, wann man will (Sobald die Verbindung steht)?

MfG,
Der Netzwerknoob

Netzwerknoob schrieb:

Wie soll man auf einen Output warten? Ich dachte, damit wartet man, bis ein Client etwas schickt, also man wartet immer nur auf Input... Senden kann man doch, wann man will (Sobald die Verbindung steht)?

wenn die gegenstation die daten zu langsam abholt und dein sendebuffer voll ist, dann musste warten, bis es weitergeht.

Aha, aber GetQueuedCompletionStatus() ist doch ein blocking call. Wie soll ich da vernünftig senden können (Wenn ich zB. per Button-Klick etwas senden möchte)?

MfG,
Der Netzwerknoob

Achso, ich denke, ich kapiere es jetzt. Man sendet und sollte dann erst auf eine Output-Completion warten. Wenn dort dann was schief läuft, könnte der Sendepuffer voll sein oder sonst was fehlschlagen...

MfG,
Der Netzwerknoob

Netzwerknoob schrieb:

Aha, aber GetQueuedCompletionStatus() ist doch ein blocking call. Wie soll ich da vernünftig senden können (Wenn ich zB. per Button-Klick etwas senden möchte)?

die funktion ist doch für 'nen extra thread gedacht. der kann ruhig warten, bis das ereignis eintritt. kannst auch 'nen timeout angeben: http://msdn.microsoft.com/en-us/library/aa364986.aspx

Jo danke, aber das weiß ich schon.

Habe nun paar Tutorials gelesen, kapiere es aber nicht. Warum ist AcceptEx() so doof designed, dass gleich ein receive mit eingebaut ist? Verstehe ich das richtig, dass ich noch einen extra Thread brauche, welcher nach "stale clients" prüft, also clients, die sich verbunden, aber noch nix gesendet haben (DoS Attack)?

Und soll man nun einen oder mehrere Threads mit AcceptEx() verwenden? Wenn nämlich gerade ein client verbindet, aber noch nix sendet, können doch keine anderen clients verbinden...

(Vielleicht ein Tutorial, wo nicht so kryptische Kacke (oder MFC) wie hier http://msdn.microsoft.com/en-us/magazine/bb985148.aspx verwendet wird? (OverlapPlus, Overlap, OVERLAPPEDPLUS, ol, in einer Zeile, toll...))

MfG,
Der Netzwerknoob

Warum ist AcceptEx() so doof designed, dass gleich ein receive mit eingebaut ist?

das receive ist doch optional

Oh, das ging mir aus dem Tutorial irgendwie nicht hervor. Auch verwirrt mich dort, warum "socket(AF_INET, SOCK_STREAM, 0);" geschrieben wird und nicht "WSASocket(AF_INET, SOCK_STREAM, 0, 0, 0, WSA_FLAG_OVERLAPPED);".

MfG,
Der Netzwerknoob

Und warum muss anscheinend irgend ein Funktionszeiger von AcceptEx() geholt werden? Reicht es nicht, einfach die Funktion aufzurufen?

MfG,
Der Netzwerknoob

Reicht, ist aber langsamer.

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

hustbaer

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.

hustbaer

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