Verbindung AllFMS bricht ab

[Shinzon]

Mir ist immer noch nicht der genaue Aufbau deines Versuchs
klar.

Klingt nach einen TCP_KEEPALIVE-Problem, aber ohne genauere Infos
ist das nur Spekulation..

Gruss,
Tim

[Paramedic]

Also:

Server:
-POC32 wertet aus
-AllFMS holt sich die Telegramme über den Port 8000 (ohne gesetztes Passwort) und gibt sie über den Port 7778 (ohne gesetztes Passwort) aus.

Client:
FMSCrusader Client holt sich die Telegramme über das Internet (DynDNS Adresse) und Port 7778. DynDNS und Port Forwarding ist richtig konfiguriert, sonst würde es ja gar nicht funktionieren. Die Initialtelegramme werden geladen. Kommt eine neue Alarmierung wird sie angezeigt. Nach einer Weile werden aber aktuelle neue Alarmierungen nicht mehr angezeigt. Es kommt mir vor, als wenn die Verbindung unterbrochen ist. Im Crusader Client steht aber nach wie vor "mit 1 Server verbunden".

Beende ich den Crusader Client und starte ihn neu, holt er sich wieder die Initialtelegramme, wertet einige neue Alarmierungen aus und bleibt dann wieder "hängen".

Lasse ich nun auf dem Server PC den Crusader Server laufen und greife auf Ihn über das Internet mit dem Crusader Client zu, läuft es wunderbar.

Ich hoffe, ich konnte Licht ins Dunkel bringen ;)

Der gleiche Versuchsaufbau im lokalen Netzwerk scheint jetzt zu funktionieren, habe die Lease Zeit vom DHCP mal von 1 Stunde hochgesetzt.


Gruß
Michael

[Shinzon]

Gut, also scheint es tatsächlich TCP_KEEPALIVE zu sein..

[Andi-Hamburg]

Hast Du bei allfms als input die daten bei server eins oder zwei eingetragen? Wenn nicht,dann mache das noch einmal!
Gruß Andi

[Paramedic]

TCP_KEEPALIVE -->
Magst Du ne kurze Erklärung dazu abgeben, was ich ändern soll?

Gruß
Michael

[chortyenz]

Hab ich grad mal im Netz gefunden:

TCP "Keep Alive"

Ist ein TCP-Teilnehmer unsicher, ob der Dialog-Partner noch da ist
und die Sitzung aufrecht erhält, so kann er ein TCP-Paket versenden,
dessen Inhalt im Grunde aus einem Dummy-Byte besteht:
Das letzte Byte des zuletzt gesendeten Pakets wird erneut gesendet.
Das ist unschädlich, da der Empfänger mittels der TCP Acknowledge Number
erkennt, dass dies "alte Kamellen" sind.

Aber: Der Empfänger quittiert den Empfang mit TCP ACK,
und diese Quittung stellt für den Initiator klar, dass der TCP-Dialog-Partner
noch da ist und die Sitzung aufrecht erhält.

[Paramedic]

Danke chortyenz für die Erklärung. Was keepalive bedeutet weiß ich, nur was kann man wo verändern, damit es klappt?

Gruß
Michael