Frage zum Disconnect mit Indy und einer TCP/IP Verbindung

[Harry Stahl]

Vorweg, ich habe im Forum gesucht, aber nicht die passenden Antworten gefunden.

Es geht hier um eine Verbindung, die ein TidTCPClient mit einer TidTCPServer-Komponente auf einem anderen PC im Netzwerk herstellt.

Mir ist immer noch nicht ganz klar, ob es besser ist,

1. dass der Client eine mit dem Server hergestellte Verbindung wieder trennt, wenn der seine Informationen erhalten hat

oder

2. dass der Server im OnExecute-Event auf jeden Fall die Verbindung trennt, wenn er die erwünschten Daten übermittelt hat?

Oder sollten sogar beide (Client und Server) ein Disconnect ausführen? Oder wäre das problematisch?

Kann es ein Nachteil sein, wenn die Verbindung "offen gehalten wird"? Bislang habe ich es immer so gemacht, dass die Verbindung immer wieder getrennt wird, wenn eine Abfrage beim Server stattgefunden hat und eben wieder neu aufgebaut wird, wenn das Clientprogramm weitere Abfragen starten muss.

Im Prinzip funktioniert hier zwar alles mit meinen Verbindungen, ich bin mir aber nicht sicher, ob bei hoher Auslastung (halt einige Dutzend Clients, die Verbindung mit dem Server herstellen), die eine oder andere Vorgehensweise zu Problemen führen könnte.

Falls neben einer Antwort gar ein Verweis auf guter Literatur zur Indy Client-Server-Programmierung möglich wäre, wäre ich dankbar.

[BUG]

Wenn man jetzt von klassischen Sockets ausgeht, dann sollten beide Seiten ihre Verbindung sauber schließen. Die Best-Praktice für Indy bzw. WinSock kenne ich nicht, die WinSocks sind ein bisschen merkwürdig.

Eine gehaltene Verbindung hat den Vorteil, das bei einer neuen Anfrage keine neue Verbindung aufgebaut werden muss. Durch den Handshake dauert das mindestens die doppelte Netzwerklatenz.
Andererseits kosten offene Verbindungen eben auch (Verwaltung im Betriebssystem und der Anwendung) und es ergeben sich andere Probleme (Heartbeat zum offen halten? Wie lange offen halten?).

[Valle]

Du solltest die Verbindung offen halten. Der Overhead für das Betriebssystem ist nicht nennbar. Vermutlich sogar größer wenn du immer wieder eine neue öffnest. Es ist auch nicht zwingend notwendig einen Heartbeat mitzuschicken. Im Zweifel kann es passieren, dass du erst bei der Verwendung der Verbindung mitbekommst, dass die Verbindung nicht mehr steht. Hier musst du wissen, ob das ein Problem für dich ist.

Es ist auch kein Problem eine Verbindung länger offen zu halten. Einige interne Serversysteme halten monatelange Verbindungen (z.B. zwei MySQL Server). Na und? Dafür gewinnst du beim Schicken von Anfragen deutlich an Zeit.

Ich weiß nicht, ob es überhaupt funktioniert wenn beide Clients die Verbindung schließen. Einer wird vermutlich schneller sein und der andere kann eine geschlossene Verbindung nicht erneut schließen. Leg es protokollbedingt fest, wer die Verbindung zu schließen hat. Wenn dein Server offene Verbindungen unterstützt, dann lass den Client entscheiden, wann er disconnected. Wenn dein Protokoll vorsieht, dass nach einer Anfrage die Verbindung geschlossen wird, dann entscheide dich von wem, dokumentiere es und setze es so um.

Wichtig ist aber, dass entsprechend darauf eingegangen wird, was beispielsweise passiert wenn das Protokoll festlegt, dass die Verbindung geschlossen werden soll, dies jedoch nicht passiert. Eine weitere Anfrage über TCP zu senden wäre dann nicht gemäß der Spezifikation.

[Harry Stahl]

OK, erst mal Danke Euch beiden für die Antworten.

Offen halten klingt einerseits sympathisch, wegen der Beschleunigung.

Wie ist es aber, wenn ein Client abstürzt und die Verbindung nicht mehr schließen kann und beim erneuten Programmstart dann wieder versucht eine Verbindung herzustellen?

Kann die zuvor noch offen gebliebene Verbindung ein Hindernis darstellen? Wenn ja, wäre es eigentlich ein Argument, die Verbindung immer wieder zu schließen.

Bisher habe ich immer beide Seiten disconnecten lassen. Im Programmablauf war das bislang kein sichtbares Problem. Aber ich bin mir eben unsicher.

[Valle]

Sofern dein Server es nicht explizit verbietet, dass die gleiche IP zwei mal verbunden ist, ist das kein Problem mit dem abgestürzten Client.

Was das Schließen angeht: ich denke das hängt auch von der Implementierung der Sockets ab. Insofern will ich mich diesbezüglich nicht zu weit aus dem Fenster lehnen, wie es bei dir ist. Ich würde nur den Client schließen lassen und die Verbindung serverseitig beliebig lang offenhalten. Der Client bestimmt, wann er fertig ist. Wie bei HTTP.

[Harry Stahl]

Ich nutze hier nur die INDY-Komponenten, spezielle Implementierungen in Bezug auf Sockets habe ich nicht vorgenommen.

Ich bin gerade dabei eine Server/Client Anwendung auf reines TCP/IP umzustellen. Zuvor hatte ich da noch eine wilde Mischung aus Mailslot-Technik (gruselig) und TCP-IP gehabt.

Nur TCP/IP zu verwenden ist da deutlich einfacher.

In einem Test gerade hier im Netz mit ca. 10 Rechnern (Verbindung teils über festes Netzwerk, teils WLan), teils Desktop, teils Notebook stellten sich folgende Probleme dar:

Die Notebooks gingen relativ schnell "schlafen" und bekamen daher einige Meldungen vom Server nicht mehr mit. Hier stellt sich die Frage, wie mit dieser Situation umgehen:

Die Notebooks, wenn man feststellt, dass die in den Tiefschlaf gehen, automatisch vom Server trennen? Oder, wenn wieder wach, die Datendatei aktualisieren / automatisch neu laden?

Wie geht Ihr mit solchen Situationen um, damit die Konsistenz des Datenbestandes auf allen Rechner erhalten bleibt?