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?

[Valle]

Das ist so allgemein schwer zu sagen, da ich deinen genauen Anwendungszweck nicht kenne.

Ich kann dir mal ein Beispiel geben, wie MySQL das macht. MySQL unterstützt einen Master-Slave-Modus, bei denen die Slaves ihren Datenbestand synchron zum Master halten. MySQL führt dabei eine Nummer mit, die mit jeder Änderung am Datenbestand erhöht wird. Die Slaves sind mit dem Master verbunden und führen Änderungen sequentiell ein. Startest du einen Slave neu, so beginnt er, dieses s.g. "Backlog" von seinem letzten Datenstand aufzuholen.

Das klappt soweit meistens ganz gut. (Ich will nicht sagen dass das problemlos klappt, aber das Problem ist meist eher MySQL als dieses System)

Es gibt einige Situationen, in denen man daran per Hand rumwerkeln muss. Beispielsweise führt der Server sein Backlog (also die Liste der Änderungen am Datenbestand) nicht unendlich lang. Ist ein Slave langer offline als das Backlog alt ist, so kann er den Bestand nicht mehr automatisch abgleichen. In dem Fall muss man vorgehen, wie man es auch beim Hinzufügen eines neuen Slaves tut. Dazu stellt man sicher, dass der Master seine Daten nicht mehr ändert (er speichert Änderungen solange im RAM) und macht ein Backup. Das Backup wird auf neue Slaves eingespielt. Der Master darf dann weiterarbeiten. Wichtig ist, das man vor dem reaktivieren des Masters aufschreibt, welche Revisionsnummer (also die Position im Backlog bzw. die Nummer die zur Synchronisation dient) das Backup hat. Nach dem Einspielen des Backups auf den Clients gibt man ihnen diese Nummer mit und sie sind wieder automatisch in der Lage synchron zum Master zu bleiben.

Im Prinzip also eine Mischung aus beiden deiner Vorschläge. Das komplette Neuladen der Datenbestände muss man in MySQL leider manuell machen, das ließe sich aber bestimmt automatisieren in deinem Programm.

Hilft dir das eventuell weiter als Ansatz?

[mm1256]

Zitat von Harry Stahl:

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?

So macht es z.B. NexusDB, die ja bekanntlich komplett in Delphi programmiert ist: Der Client sendet permanent (in einem eigenen Thread) einen Heartbeat. Wenn der Server nach einer einstellbaren Zeit (üblich sind 10 Sekunden) keinen Heartbeat mehr erhält, trennt er die Verbindung. Somit bleiben keine Verbindungsleichen übrig. ReConnect nach "Tiefschlaf" kann/muss der Client durchführen.

Was mich an der Stelle auch mal interessieren würde: Bekommt man es eigentlich vorher mit (Message? Frage an die API-Spezies), dass Windows beabsichtigt den Rechner in den Ruhezustand zu versetzen? Dann könnte man clientseitig reagieren.

[Photoner]

Ja die Message gibt es.

Eine schnelle Suche ergab:

WM_ENDSESSION message

https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

In den Kommentare steht aber, dass man evtl. nur sehr wenig Zeit zur Verfügung hat bis der eigene Prozess abgewürgt wird.
Ich würde da eher einen Ticken früher sichern, egal ob sich der Benutzer des Rechners es anders überlegt und doch nicht herunterfährt.

WM_QUERYENDSESSION message

https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

Notfalls kann man den Shutdown verhindern indem der Rückgabewert auf False gesetzt wird.

Findet sich auch schon im Forum:
Anwendung beenden bei Windows Shutdown (WM_QueryEndSession)

[Harry Stahl]

Zitat von Valle:

Das ist so allgemein schwer zu sagen, da ich deinen genauen Anwendungszweck nicht kenne.

Es ist eine Client-Server Anwendung, wo für mehrere Anwender im Netz eine gemeinsame Termindatenbank verwaltet wird. Der Server verwaltet dabei die Datenbank (Clients fragen also an, ob sie einen Datensatz bearbeiten oder einfügen können, Server gibt OK, Client liefert dann die neuen oder geänderten Daten. Server verteilt neue oder geänderte Daten an andere Clients, die gerade im Netz mit dieser Datenbank verbunden sind).

Zitat von Valle:

Ich kann dir mal ein Beispiel geben, wie MySQL das macht. MySQL unterstützt einen Master-Slave-Modus, bei denen die Slaves ihren Datenbestand synchron zum Master halten.

Ja, so mache ich das im Prinzip auch.

Zitat von Valle:

MySQL führt dabei eine Nummer mit, die mit jeder Änderung am Datenbestand erhöht wird. Die Slaves sind mit dem Master verbunden und führen Änderungen sequentiell ein. Startest du einen Slave neu, so beginnt er, dieses s.g. "Backlog" von seinem letzten Datenstand aufzuholen.

Auch ein interessanter Ansatz. Das würde sogar "Offline"-Arbeiten mit dem Datenbestand ermöglichen.

Zitat von Valle:

Im Prinzip also eine Mischung aus beiden deiner Vorschläge. Das komplette Neuladen der Datenbestände muss man in MySQL leider manuell machen, das ließe sich aber bestimmt automatisieren in deinem Programm.

Hilft dir das eventuell weiter als Ansatz?

Ja danke, das sind gute Ideen, um hier noch Erweiterungen / Verbesserungen einführen zu können.

Da die Datenbank i.d.R. maximal nur einige MB einnimmt, wäre auch ein stiller Reload machbar, wenn der Client merkt, er hat das eine oder andere verpasst.