Dauerhafte "Onlineüberprüfung" mit Serverseitigen Befehlen

[Delphi-Narr]

So ein NOOP-Befehl ist eine gute Idee. Das mit den Switches und Routern war mir so nicht bewusst.
Von Zeit zu Zeit einen "sinnlosen" Befehl zu senden ist auf jeden Fall kein Problem! Kann der Client mit einem Befehl vom Server nichts anfangen,
reagiert er jetzt schon einfach nicht. So ist das in dieser Richtung auf jeden Fall sehr einfach zu realisieren. Muss die Kommunikation denn
zwangsweise in beide Richtungen stattfinden, damit die Verbindung nicht gekappt wird oder würde das schon reichen?
Danke auf jeden Fall für die Antwort!

[sx2008]

Zitat von Delphi-Narr:

Muss die Kommunikation denn zwangsweise in beide Richtungen stattfinden, damit die Verbindung nicht gekappt wird oder würde das schon reichen?

Eine Richtung reicht.
Ich würde im Protokoll nur beide Richtungen vorsehen, damit man sich alle Möglichkeiten offen hält.
Ein NOOP-Befehl sollte von der anderen Seite nicht bestätigt sondern ignoriert werden.

[Furtbichler]

Ich würde ein Ping-Pong implementieren. Der Client sendet alle X Sekunden ein cund erwartet ein "Jupp" vom Server. Der Server erwartet ein "Bist Du noch da?" alle X+n Sekunden.

Kommt das "Jupp" nicht, beendet der Client die Verbindung, die ja offensichtlich ins Nirvana geführt hat.
Bekommt der Server die nächste Anfrage "Bist Du noch Da?" nach X+n Sekunden nicht, kappt er die Verbindung.

Der Client versucht bei verlorener Verbindung, diese wieder aufzubauen.

Eine ständig offene Verbindung ist nur bei ständigem Datenfluß zu erwarten, tut aber eigentlich auch nicht weh. Wenn man jedoch eh nur selten etwas zu verschicken hat, dann kann man die Verbindung jedes Mal neu aufbauen. Das dauert aber manchmal etwas, weil die Netzwerkkomponenten teilweise erst aufwachen müssen (jedenfalls war das mein Eindruck). Bei einem Kunden war das ein Problem, denn dann war der Server beim 1. Verbindungsversuch nicht erreichbar, also musste man mehrmals versuchen und dann noch den Timeout erhöhen. Also beim ersten Versuch mit kurzem Timeout und dann den Timeout erhöhen.

Wenn Du mit abgebrochenen Verbindungen leben musst (WLAN außer Reichweite z.B.) dann solltest Du das vielleicht einfach ins Kalkül nehmen.

Ich persönlich würde dann vermutlich Daten nur verschicken, wenn es etwas zu sagen gibt, oder benötigst Du auch die Information, das der Client auch 'da', also 'online' ist?

[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 von 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.

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

Zitat von Delphi-Narr:

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 von Delphi-Narr:

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 von Delphi-Narr:

Darum muss die Verbindung an sich immer offen gehalten werden.

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

Gruß
K-H

[Delphi-Narr]

Zitat von p80286:

Zitat von 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.

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 von p80286:

Zitat von Delphi-Narr:

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 von p80286:

Zitat von Delphi-Narr:

Darum muss die Verbindung an sich immer offen gehalten werden.

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

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 von Delphi-Narr:

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?