Indy TCP Server OnAccept?

[Tumm]

Hi,

ich habe ein Problem mit dem Indy TCP Server. Zu diesem soll sich ein Java-Client verbinden. Dieser hängt sich jedoch auf, erst beim brutalen Beenden des Clients scheinen die Pakete "durchzukommen", der Server stellt zumindest die Verbindung fest und nimmt die ersten Daten entgegen. Anschließend wird die Verbindung aber eben geschlossen.
Ich habe zuvor LNet unter Lazarus genutzt und wollte es jetzt mit Indy versuchen (ebenfalls unter Lazarus), um dem NetworkOrder Problem aus dem Weg zu gehen. Das OnConnect-Event des LNet-Clients wurde ebenfalls nicht ausgelöst, nur das OnAccept-Event.

Woran kann das denn bloß liegen :/?

[Astat]

Zitat:

Zitat von Tumm

Java-Client verbinden. Dieser hängt sich jedoch auf, erst beim brutalen Beenden des Clients scheinen die Pakete "durchzukommen",Woran kann das denn bloß liegen :/?

Hallo Tumm, ich kenne die Interne Arbeitsweise der Indy's nicht, da ich ausschließlich mit der Socket-API arbeite.
Aber das beschriebene Verhalten tritt dann auf, wenn folgende Bedingungen zutreffen.
Das Handshake des Servers ist unterschiedlich mit Handshake des Clients.
D.h. eine Seite Blockierend, die Andere NonBlocking.
In diesem Fall Sendet der Client (Blockierend eingestellt),
Daten an den Server, danach wartet der Client im recv (Blockierend) auf eine Rückantwort.
Kommt nun vom Server (Asynchron) kein Send, blockiert der Client im recv -> INFINITE.

Da sich ja der JAVA Client "aufhängt", vermute ich mal das oben beschriebene Szenario.
Folgende Lösungen sind möglich.
1. Server auf Blockierend umstellen.
2. Client auf Asynchron umstellen.

Bei den Indy's ist vermutlich alles was die Komponente in Threads anbietet, blockierend.


lg. Astat

[Tumm]

Danke für die Antwort :>

Delphi-Quellcode:

1. Server auf Blockierend umstellen.
2. Client auf Asynchron umstellen.

Dazu hab ich leider nicht die Möglichkeit. Indy bietet keine Möglichkeit da was zu drehen.

Wäre die Lnet-Reaktion dann damit zu erklären, dass Accept vor der erwarteten Handshakerückgabe ausgeführt wird?

[Astat]

Zitat:

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