Dauerhafte "Onlineüberprüfung" mit Serverseitigen Befehlen

[Der schöne Günther]

Die Befürchtung betrifft doch eigentlich nur den Server, dass er nicht damit zurechtkommt, so viele Verbindungen gleichzeitig offen zu halten, oder? Mein Windows 7-Desktop lauscht im Moment gerade schon auf 70 Ports gleichzeitig, ein halbwegs ernstzunehmender Server wird auch mit zwei- dreihundert offenen Verbindungen wohl zurechtkommen.

Aber das ist nicht mein Fachgebiet, Menschenleben sollte man von meiner Aussage jetzt besser nicht abhängig machen.

Ab wann gilt der Client beim Server eigentlich wieder als abgemeldet? Wenn innerhalb von ... 45 Sekunden keine Meldung mehr von ihm kam?

Warum ein Client die Verbindung verlieren sollte wüsste ich spontan auch nicht.

[p80286]

Eigentlich sollte es so sein, daß zwei Rechner nur dann in Verbindung treten wenn sie sich etwas zu sagen haben. 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. Falls so etwas wirklich notwendig ist, sollte das dannaber auch über ein physisch eigenständiges Netz abgewickelt werden.

Gruß
K-H

[Sir Rufo]

Mal abgesehen davon, dass man dass auch mit Microsoft-Message-Queue (oder einem anderen MQ Dienst) abtüten könnte.

Ich würde die Clients alle x Sekunden mit dem Server verbinden und dort nach Aufgaben anfragen lassen.
Ist eine Aufgabe vorhanden, diese Aufgabe abholen, abarbeiten und die Aufgabe als erledigt melden.
Dann direkt wieder nach einer Aufgabe suchen.

Ist keine Aufgabe mehr vorhanden, dann wieder alle x Sekunden fragen.

Eine Verbindung zum Server besteht somit nur während der Abfrage, dem Abholen und der Rückmeldung.

[mjustin]

Zitat von p80286:

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

[hathor]

Hier gibt es Infos:

So ermitteln Sie den Verlust von Client/Server-Verbindung

http://support.microsoft.com/kb/140325

Tags:
halb-offene Verbindung
KeepAlive
KeepAliveInterval
KeepAliveTime

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

[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?