Dauerhafte "Onlineüberprüfung" mit Serverseitigen Befehlen

[Delphi-Narr]

Da die Serveranwendung den Onlinestatus in eine Datenbank einträgt, die dann hinterher von anderen Programmen ausgelesen werden kann,
muss der Server auch immer wissen, ob der Client noch da ist.
Und der Server muss auch jederzeit die Möglichkeit haben, dem Client etwas zu "sagen" - wenn der Client dann grade offline ist, ist das nicht so optimal.
Entweder verschwindet der Befehl im Nirvana, weil der Server den Client für dauerhaft offline hält, oder der Befehl wird gecacht und dann viel zu spät ausgeführt,
wenn er schon gar nicht mehr benötigt wird. Darum muss die Verbindung an sich immer offen gehalten werden.

Ich werde dann mal eine "Sinnlos-Kommunikation" einbauen.

[p80286]

Zitat:

Zitat von Delphi-Narr (Beitrag 1215619)

Da die Serveranwendung den Onlinestatus in eine Datenbank einträgt, die dann hinterher von anderen Programmen ausgelesen werden kann,
muss der Server auch immer wissen, ob der Client noch da ist.

alles was der Server weiß, ist daß zu einem bestimmten Zeitpunkt X der Client geantwortet hat.
Nicht mehr nicht weniger.

Zitat:

Zitat von Delphi-Narr (Beitrag 1215619)

Und der Server muss auch jederzeit die Möglichkeit haben, dem Client etwas zu "sagen" - wenn der Client dann grade offline ist, ist das nicht so optimal.

Darum lassen sich viele Protokolle ja den Empfang auch quittieren.

Zitat:

Zitat von Delphi-Narr (Beitrag 1215619)

Entweder verschwindet der Befehl im Nirvana, weil der Server den Client für dauerhaft offline hält, oder der Befehl wird gecacht und dann viel zu spät ausgeführt,wenn er schon gar nicht mehr benötigt wird.

Es soll auch für Daten/Befehle so etwas wie ein Verfallsdatum geben (TimeToLive)

Zitat:

Zitat von Delphi-Narr (Beitrag 1215619)

Darum muss die Verbindung an sich immer offen gehalten werden.

Ich werde dann mal eine "Sinnlos-Kommunikation" einbauen.

:gruebel:

Gruß
K-H

[mjustin]

Zitat:

Zitat von p80286 (Beitrag 1215525)

Die permanent offene Verbindung,mit permanentem Versand von Prüfnachrichten ist einfach nur Verschwendung und bringt überhaupt nichts, wenn im Moment der Übertragung der wichtigen Daten die Verbindung zusammenbricht.

Bei TCP ist das Problem leider, dass der Socket - ohne aktiv zu werden - eine zusammengebrochene Verbindung nicht von einer noch bestehenden Verbindung unterscheiden kann.

Das regelmäßige Senden von heart-beat Signalen (auf der Protokollebene) ist ein in der Praxis üblicher Weg, einen Verbindungszusammenbruch auch dann festzustellen, wenn gerade keine Nutzdaten übertragen werden. Es verursacht weniger Netzwerktraffic als ein ständiges Auf- und Abbauen der Verbindung.

p.s. In Netzwerken mit Network Address Translation NAT sind heart-beats auch eine Möglichkeit, das Trennen der Verbindung durch das NAT Gerät zu vermeiden (NAT arbeitet mit einer Tabelle der Verbindungen, und Tabelleneinträge werden nach einer bestimmten Zeit der Inaktivität entfernt).

[Delphi-Narr]

Zitat:

Zitat von p80286 (Beitrag 1215633)

Zitat:

Zitat von Delphi-Narr (Beitrag 1215619)

Da die Serveranwendung den Onlinestatus in eine Datenbank einträgt, die dann hinterher von anderen Programmen ausgelesen werden kann,
muss der Server auch immer wissen, ob der Client noch da ist.

alles was der Server weiß, ist daß zu einem bestimmten Zeitpunkt X der Client geantwortet hat.
Nicht mehr nicht weniger.

Das stimmt, aber wenn der Client ab und an mal etwas schickt, hält ein Switch dann die Verbindung offen (wenn ich das hier alles richtig verstanden habe)
und es könnte einzig das Problem auftreten, dass Server oder Client abschmieren. Wenn das der Fall ist, wird die Gegenseite das mit der Zeit aber auch herausfinden.

Zitat:

Zitat von p80286 (Beitrag 1215633)

Zitat:

Zitat von Delphi-Narr (Beitrag 1215619)

Entweder verschwindet der Befehl im Nirvana, weil der Server den Client für dauerhaft offline hält, oder der Befehl wird gecacht und dann viel zu spät ausgeführt,wenn er schon gar nicht mehr benötigt wird.

Es soll auch für Daten/Befehle so etwas wie ein Verfallsdatum geben (TimeToLive)

An sich eine gute Idee, aber weder Server noch Client wissen, wie der Nutzer reagiert, wenn sein Befehl nicht sofort ausgeführt wird.
Darum kann ich eigentlich nicht global so eine Zeit festlegen.

Zitat:

Zitat von p80286 (Beitrag 1215633)

Zitat:

Zitat von Delphi-Narr (Beitrag 1215619)

Darum muss die Verbindung an sich immer offen gehalten werden.

Ich werde dann mal eine "Sinnlos-Kommunikation" einbauen.

:gruebel:

Ich meine damit, dass Server und Client zwischendurch einfach mal ein "Hallo, wie geht's?" schicken
und wenn es keine Antwort gibt, trennen sie die Verbindung und versuchen es erneut. Die übertragenen Daten werden
aber vom Server bzw. Client nicht weiter verarbeitet und in "komplexere" und rechenaufwendige Prozeduren geleitet.
Ein bisschen Smalltalk quasi ;)

[Furtbichler]

Zitat:

Zitat von Delphi-Narr (Beitrag 1215711)

und es könnte einzig das Problem auftreten, dass Server oder Client abschmieren.

Oder ein Wackelkontakt, oder Kabel wird rausgezogen, oder ein falsch konfigurierter Switch, oder überlastete Switches, oder WLAN, oder Internet, oder die Putzfrau, oder, oder, oder.

Bei TCP ist es nicht so, das Du Pech hast, wenn etwas nicht läuft, sondern Glück hast, das etwas läuft. Du musst hier wirklich Hosenträger, Gürtel und Antackern-An-Den-Bierbauch implementieren. Und zwar im Protokoll.

Also:
1. Heartbeats wie beschrieben.
2. Pack dein Telegramm in einen Frame mit Längenangabe: <STX><Len><Data><ETX> (vielleicht sogar eine Prüfsumme). Begrenze 'Len', denn auch hier kann Müll stehen, und Du willst ja nicht 300Gig an Daten lesen...
3. Jedes Telegramm wird per ACK/NAK beantwortet. Ich hatte hier mal ein Protokoll mit Checksum, was bei TCP eigentlich überflüssig ist, aber trotzdem bei einem Kunden in Indien diverse NAKs Aufgrund fehlerhafter Prüfsummen.
4. Jedes Telegramm erhält zudem eine eindeutige ID (fortlaufende Nummer reicht)

Wenn hier irgendetwas schief läuft (Heartbeat bleibt aus, Antwort kommt nicht, Länge zu groß) wird die Verbindung gnadenlos gekappt.

Mach Dir lieber mehr Gedanken über ein robustes und idiotensicheres Protokoll. Wenn Du dich darauf verlassen kannst, dann macht TCP sogar richtig Spaß.

Gibts da eigentlich nix Fertiges?

[Delphi-Narr]

Zitat:

Zitat von Furtbichler (Beitrag 1215714)

Zitat:

Zitat von Delphi-Narr (Beitrag 1215711)

und es könnte einzig das Problem auftreten, dass Server oder Client abschmieren.

Oder ein Wackelkontakt, oder Kabel wird rausgezogen, oder ein falsch konfigurierter Switch, oder überlastete Switches, oder WLAN, oder Internet, oder die Putzfrau, oder, oder, oder.

Aber auch wenn die Putzfrau sich austobt, wird der Smalltalk abgewürgt.
Die übertragenen Daten sind generell nicht gigantisch. Der Empfang von Kommandos wird bereits dadurch bestätigt, dass der Client das Empfangene einfach nochmal zurückschickt.

Ich werde mich aber jetzt mal an eine geschlossenes Protokoll setzen, wo das alles eingebaut ist und nicht viele einzelne Bruchstücke.

[tgvoelker]

TCP implementiert immer Verbindungen mit Status. "Keepalive" benötigst für TCP-Verbindungen nuraus einem Grund: um zwischen Server und Client vorhandenen Firewalls davon abzuhalten, die Verbindung nach Inaktivität zu löschen, während Server und/oder Client diese noch als "bestehend" ansehen.

Du erkennst einen Verbindungsverlust/abbau von Seiten des Clients auf Serverseite in zwei Fällen: erstens wenn der Client die Verbindung beendet und zweitens, wenn der Server was an den Client schickt und darauf kein ACK bekommt, bis der Retransmission Timer abgelaufen ist. Die Verbindungskontrolle erfolgt dabei auf Protokollebene.

Das Problem dabei ist, daß die Anti-DoS-Mechanismen von Firewalls restriktive Schranken für die Anzahl und Zeitdauer inaktiver Verbindungen haben (Hintergrund dafür ist, daß DDoS-Angriffe mit halboffenen Verbindungen geführt wurden) - was dazu führt, daß die Firewalls TCP-Verbindungen ohne periodische Aktivität schon nach kurzer Zeit aus der Verbindungsliste schmeißen. Beispiel: Ich hatte mal einen Levelone Router, der aktive FTP-Sitzung abgebrichen hat, wenn die Übertragung einer einzelnen Datei länger als 10 Minuten gedauert hat - das Ding hat FTP-DATA offengelassen und FTP-CONTROL geschlossen. Aufgefallen ist das erst am Ende der Übertragung, bei kleinen dateien ging alles.

Sauberer kannst Du das mit UDP oder auch mit ICMP implementieren, aber das erfordert, daß die Clients nicht hinter einer NAT-Firewall stecken.