Dauerhafte "Onlineüberprüfung" mit Serverseitigen Befehlen

**Delphi-Narr**

@Der schöne Günther:
Bisher gilt der Client als abgemeldet, wenn er die Verbindung verliert, die (bisher) dauerhaft offenhalten wird.

An sich stimme ich zu, dass die Verbindung nicht dauerhaft aufgehalten werden sollte, doch um den Client als effektives Tool zu nutzen, müssen
die Aufgaben recht schnell abgearbeitet werden. Darunter fallen zum Beispiel auch Screenshots und die sollen auf jeden Fall aktuell sein, wenn der Server anfragt.
Während der eigentlichen Datenübertragung bricht die Verbindung nicht ab! Der Record kommt immer komplett an und verursacht keine Fehler. Nur während der "Wartephase"
verabschiedet sich der Client dann mal, um teilweise nach 2 Sekunden wieder zu verbinden.
Es handelt sich um einen Windows Server 2008, der mit den Verbindungen an sich durchaus klarkommen sollte.
Einzige Möglichkeit wäre vielleicht noch, dass das Serverprogramm überlastet, wenn es bei vielen verbundenen Clients auch noch viele "Kommandoverbindungen" gibt, welche dem Serverprogramm sagen,
welcher Client welchen Befehl ausführen soll.
Wenn alle 10 Sekunden 60 Anfragen auf einmal kommen, sollte das den Server aber eigentlich nicht aus der Bahn werfen.
Ich gucke mir mal die Links an, danke!

**sx2008**

Switches und Router müssen ihre internen ARP Caches (Zuordnung MAC <-> IP) klein halten und löschen die Einträge nach einer bestimmten Zeit.
Wenn die Endteilnehmer einer TCP-Verbindung eine bestimmte Zeit nicht miteinander reden, dann kann die Verbindung getrennt werden ohne dass es die Endpunkte gleich mitbekommen.
Möchte man das vermeiden, kann man in periodischen Abständen einen

NOOP-Befehl verschicken.

Natürlich muss der NOOP-Befehl im Protokoll vorgesehen werden.
Meine Empfehlung: im Protokoll sollte sowohl für den Client als auch für Server ein NOOP-Befehl/Message vorgesehen werden.

WinSock bietet auch die Möglichkeit Keep-Alive Pakete zu verschicken. (siehe Info von hathor)
Client und Server bekommen davon nichts mit.
Allerdings hängt es vor der Windows Version ab wie gut das funktioniert und man muss in die Tiefen von WinSock eintauchen.
Bei älteren Windows-Versionen muss man an der Registry herumschrauben und ändert das Verhalten aller TCP/IP-Verbindungen.
Falls möglich würde ich den NOOP-Befehl vorziehen.

**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.

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