Socket-Verbindung absichern

[Jan]

Ich habe die hier ausführlich diskutierte Socketverbindung vergangene Woche scharf geschaltet. Und erwartungsgemäß lief auch alles sauber durch.

Aber heute früh habe ich das routinemäßig kontrolliert, und mußte leider feststellen, daß das Programm komplett abgestürzt war. Nun gibt es keine Arrays, die irgendwann mal überlaufen können, oder sonstige Fallstricke, die nicht sofort aufgefallen wären. Mehrere Tage lang lief das sauber, dann kurz nach Mitternacht Exitus.

Nun stellt sich mir die Frage, woran das gelegen haben könnte. Als Einziges kommt mir die Socket-Verbindung in den Sinn, die eventuell unterbrochen gewesen sein könnte. Unterstützt wird das durch die Aussage des Admins, das auch immer mal Pings in den Switches verloren gehen. Ich habe erstmal eine Routine eingebaut, die um Mitternacht die Verbindung löscht, und neu aufbaut. In der Hoffnung, daß das eine mögliche Überlastung durch Dauerbetrieb verhindert.

Ich kann aber nicht glauben, das ein Socket-Dauerbetrieb ein Problem darstellen könnte.

Wie also könnte ich eine Überprüfung einbauen, die im laufenden Betrieb klärt ob die Verbindung steht, eventuell kurz wartet, und wenn das immer noch nicht klappt, die alte sauber schließt und eine neue aufbaut? Ich hab mal die SocketSelect() versucht, aber die gibt mir immer nur zurück, das die Parameter falsch wären. Obwohl die alle optional sind, und ich nur das Array an Pos. 4 und die Fehlerauswertung an Pos. 5 gesetzt hatte. Oder wäre SocketSelect() garnicht der richtige Weg?

Jan

[andreas]

Hallo Jan,

wenn du ein Gartenschlauch durchschneidest, fließt leider kein Wasser mehr durch.
Genauso ist es auch bei einer Socket-Verbindung: du hast zwar noch den Pointer auf diese, kannst aber damit nicht mehr arbeiten, weil die Verbindung nicht mehr da ist und das ganze zu einem Runtime-Fehler führen kann.
Die Probleme mit unterbrochenen Netzwerkverbindungen bestehen immer. Du muss dein Programm so erweitern, dass es damit umgehen kann.

Ich habe jetzt die Befehle nicht vor mir, deswegen kann ich dir nur die Möglichkeiten anbieten:
1. Bevor du die Daten sendest oder empfängst, musst du den Status der Verbindung prüfen.
2. Sende-/Empfangsbefehl in Begin Sequence umschließen und den Fehler abfangen.
3. Bei Fehler kannst du den Fehlercode prüfen und dem entsprechend reagieren.
4. Wenn nichts mehr geht, dann die Verbindung zum Server neu aufbauen.

Ich würde an deiner Stelle das ganze in eine Klasse packen, um besser reagieren zu können. In den Sende-/Empfangs-Methoden die Prüfung einbauen.

[andreas]

Du kannst dein Problem am Samstag mitbringen, damit wir es zusammen ansehen können, falls es bis dahin noch nicht gelöst seien sollte!

[Martin Altmann]

Fragt sich natürlich, warum die Socketverbindung permanent offen sein muß! Warum nicht jedesmal vor dem Zugriff Verbindung aufbauen, Daten senden, Verbindung trennen?
Ist die Latenz so stark und das Intervall so kurz, dass diese Möglichkeit ausscheidet?

Viele Grüße,
Martin

[Jan]

Hallo Andreas und Martin,

das Datenholen läuft in einer Do While-Schleife. Ohne Ausstiegspunkt. In jedem Durchlauf holt der genau 1 Zeichen aus dem Socket-Datenstrom.

Ich kann den auch nicht ständig beenden und neu starten - bei jedem Neustart werden komplett alle Knoten des Gira-Servers übermittelt. Das würde mir das ganze System total ausbremsen.

Mir schwebt vor, in jedem Schleifendurchgang einfach kurz zu checken, ob die Socketverbindung noch steht. Und notfalls die dann doch neu aufzubauen. Aber eben nur dann, wenn die aus welchem Grund auch immer unterbrochen worden ist.

Jan

[andreas]

Hallo Jan,

hast du dir schon die Beispiele von Alaska angesehen?
Normalerweise erfragst du beim 1. Schritt, wieviele Daten dir gesendet werden und dann empfängst du alles.

Mir schwebt vor, in jedem Schleifendurchgang einfach kurz zu checken, ob die Socketverbindung noch steht. Und notfalls die dann doch neu aufzubauen. Aber eben nur dann, wenn die aus welchem Grund auch immer unterbrochen worden ist.

Das ist ja genau das, was ich sage. Bei Dauerverbindung ist es der Beste Weg.

[Jan]

Andreas,

ich kann nicht abfragen, wie viel da kommen wird. Weil das ein ständiger Datenstrom ist. Mal mehr oder weniger lange unterbrochen (der Datenstrom, nicht die Verbindung!), wenn gerade nix passiert, aber dennoch muß ich auch in der Zeit immer "ein Ohr auf der Leitung" haben.

Und zu der Art der Überprüfung hatte ich genau das auch in meinem Eingangsposting angefragt.

Jan

[Jan]

Da ja nun klar ist, das meine Eingangsfrage korrekt ist, fehlt mir noch eine Idee, wie ich vor jedem Auslesen eines Zeichens aus dem Datenstrom sicherstellen kann, das die Verbindung wirklich noch steht.

Jan

[Martin Altmann]

Gar nicht - denke ich mal.
Also wirst Du - statt mit defensiven programmieren - nur mit offensiven programmieren weiterkommen: Bau eine Errorhandlingroutine drum rum!

Viele Grüße,
Martin

[andreas]

Ich mache es so, dass der normale Empfang in BEGIN SEQUENCE eingeschlossen wird. Falls ein Fehler auftritt, dann noch ein Mal versuchen und bei 2. Fehler die Verbindung neu aufbauen.

[Werner_Bayern]

Bei Marshallsoft gibt es dazu die Funktion

cscIsConnected:: Returns the Current Connection Status

Gibts das in Xbase++ nicht?

[schmä]

Ich mache es so, dass der normale Empfang in BEGIN SEQUENCE eingeschlossen wird. Falls ein Fehler auftritt, dann noch ein Mal versuchen und bei 2. Fehler die Verbindung neu aufbauen.

Ja, so handhabe ich das auch!!