Zitat von
Tumm:
Wäre die Lnet-Reaktion dann damit zu erklären, dass Accept vor der erwarteten Handshakerückgabe ausgeführt wird?
Hallo Tumm, auf Socketebene läuft dies wie folgt ab.
1. Zugehörige Laufzeit (WSockxxx.Dll) mit WSAStartup initialisieren
2. je nach Art des gewünschten Sockets, diesen mit z.B. Socket(AF_INET, SOCK_STREAM, IPPROTO_TCP), erstellen.
3. Binding für Adapter mit Bind(Socket,..) durchführen.
4. Den Erzeugten und an einen oder an alle Adaptoren gebundenen Socket mit Listen(Socket) in den "listening Mode" setzen.
Hier Blockiert nun der Betreffende Thread oder Applikation, bis sich ein Client verbindet.
Wird nun eine Verbindung durch einen Client aufgebaut, wird die Blokade aufgehoben, und der Thread oder die Applikation
kann mit Accept die Anfrage weiterbehandeln.
5. Wird die neue Clientverbindung durch den Aufruf von Accept, Akzeptiert, erfolgt die Datenaufbereitung mit Select, Recv und Send.
6. Normalerweise wird dem Client mit Select(..Timeout) eine gewisse Zeit eingeräumt um mit dem Senden zu beginnen.
Select blockiert auch hier, bis der Client Sendet, bzw. das eingestellte Timeout auftritt.
Hier beginnt nun das von mir angesprochene Handshake
7. Daten werden mittels Recv empfangen, und aufbereitet bzw. weiterverarbeitet.
8. Wurden die Daten empfangen, wird im Send(socket) eine Rückantwort zum Client übermittelt.
9. Entweder Verbindung beibehalten, oder mit Shutdown und Close Verbindung beenden.
Fertig
7. 8. Ist das Klassische Clien-Server Handshake.
Ein Handshake kann auch folgendermaßen aussehen.
7a. Recv (z.B. HTTP Post)
8a. Send (OK)
9a. Recv (Daten) wenn hier ein Client kein Send mehr aus OK ausführt, blokiert Recv hier.
10a. Send (OK)
11a. Entweder Verbindung beibehalten, oder mit Shutdown und Close Verbindung beenden.
Fertig.
Um nun herauszufinden wo das Problem ist, musst Du den Datenverkehr aufzeichnen (Packetyzer, Wireshake etc.) um zu sehen
wie der Handshake benötigt wird.
Als Alternative kannst Du beigelegten Server Code Debugen, um festzustellen wo's hakt.
lg. Astat