Ich müsste also irgendwie überprüfen können, ob noch FD_READ_Events in der Schleife sind, bevor ich die Verbindung schließe, aber ich hab keine Ahnung wie das gehen kann.

Bitte um Hilfe und Anregungen.

mfg
Ingenuus

switch (msg) 
      { 
      case WM_SUSCIP:
            switch(WSAGETSELECTEVENT(l))
            {
              case FD_READ:
                   numread = recv(sock,buffer[0],1024,0);
                    fwrite(temp,1,numread,file);

                   break;

              case FD_WRITE:
                   break;

              case FD_CLOSE:
                   fclose(file);
                   WSACleanup();  
              default:
                   break;  
            }
            break;
}

Da weiß ich nicht wie ich WSAEventSelect, WSAWaitForMultipleEvents, WSAEnumNetworkEvents einbauen soll.

The WS2_32.DLL will not continually flood an application with messages for a particular network event. Having successfully posted notification of a particular event to an application window, no further message(s) for that network event will be posted to the application window until the application makes the function call that implicitly reenables notification of that network event.

D.h. Du musst alles mit recv zuerst auslesen, bevor Du wieder neue Nachrichten annehmen darfst, da sonst vielleicht ein FD_CLOSE kommt und Du noch nicht alle Daten gelesen hast.
Das wird vermutlich schon Dein Problem lösen...

With these semantics, an application need not read all available data in response to an FD_READ message — a single recv in response to each FD_READ message is appropriate.

Ich benutzte bereite WSAAsyncSelect, aber das verursacht ja anscheinend das ganze Dilemma.

war das nur ein Tippfehler, oder woher bekomme ich die WSASyncSelect?

Ich quote auch mal:

msdn schrieb:

FD_CLOSE should only be posted after all data is read from a socket, but an application should check for remaining data upon receipt of FD_CLOSE to avoid any possibility of losing data.

Be aware that the application will only receive an FD_CLOSE message to indicate closure of a virtual circuit, and only when all the received data has been read if this is a graceful close. It will not receive an FD_READ message to indicate this condition.

Hmm, einfach noch nen recv() vors WSACleanup()? - (Hmm, für gewöhnlich ruft man WSACleanup() erst am Programmende auf und WSAStartup() beim Programmstart? - Hast du nur eine Verbindung?)

ich rufe WSAStartup() und WSACleanup() jedes mal auf, wenn ich ne neue Verbindung zum Server aufmache und das tu ich für jede seite einzeln.

wenn ich jetzt noch ein recv vor das WSACleanup() hänge bringt das nix, da er damit auch nur einen weiteren Teil der Daten bekommt, aber nicht alles, außerdem schmiert er ab, wenn keine Daten mehr da sein sollten.

ne was ich bräuchte wäre ne möglichkeit, die FD_CLOSE solange auszubremsen, bis wirklich alle FD_READ weg sind.

Ich wollte eigendlich schon mein WSAAsyncSelect() bebehalten, weil ich das ganz elegant find, aber wenn alles nix Hilft muss ich halt nochmal den ganzen Code umstellen.

Nein, auf ein FD_READ Nachricht sollte man nur einmal recv aufrufen.

With these semantics, an application need not read all available data in response to an FD_READ message — a single recv in response to each FD_READ message is appropriate.

Wenn aber anschliessend ein FD_CLOSE kommt, dann hast Du ein Problem...
Das Hauptproblem ist aber: Wenn Du ein recv mit Buffergröse von 1024 aufrufst und 2000 Bytes angekommen sind, so bleibt ein Teil übrig... dieser Teil kann schlimmstenfalls immer größer werden u´nd wird von Dir dann nich abgeholt.

Ich kann nur dazu raten das recv so oft aufzurufen, bis weniger zurückkommt als der Buffer gross ist.

Es steht ja auch nicht da, dass es nicht erlaubt ist... ich mache es bei mir immer und es funktioniert tadelos...

WSAAsyncSelect rausgenommen und ne einfache Schleife um recv gelegt.

Is zwar nicht elegant, funktioniert aber und scheint für meinen Zweck vollkommen ausreichend zu sein.

Danke nochmal für die Anregungen.

Wenn ich den Code posten soll sagt bescheid.

mfg
Ingenuus

Wie gesagt: Du musst auf FD_READ, das recv so oft in einer Schleife aufrufen, bis weniger zurückkommt, als der Bufer gross ist! Dann geht alles!

Laut msdn ist FD_READ da eine Ausnahme: Sobald recv() einmal aufgerufen wurde wird sofort im Anschluss geprüft ob immer noch was im Buffer ist und FD_READ erneut gesendet.

msdn schrieb:

Any call to the reenabling routine, even one that fails, results in reenabling of message posting for the relevant event.

For FD_READ, FD_OOB, and FD_ACCEPT events, message posting is level-triggered. This means that if the reenabling routine is called and the relevant condition is still met after the call, a WSAAsyncSelect message is posted to the application. This allows an application to be event-driven and not be concerned with the amount of data that arrives at any one time. Consider the following sequence:
- Network transport stack receives 100 bytes of data on socket s and causes Windows Sockets 2 to post an FD_READ message.
- The application issues recv( s, buffptr, 50, 0) to read 50 bytes.
- Another FD_READ message is posted because there is still data to be read.

With these semantics, an application need not read all available data in response to an FD_READ message — a single recv in response to each FD_READ message is appropriate.