Beiträge

Habs jetzt mal mit dem Standard Phoenix Baustein versucht (IP_CONNECT).
Dort kann ich nach dem Abbruch (wenn meine KeepALive Pakete ausbleiben)
nach "EN_C -> false -> true" problemlos wieder reconnecten.
Warscheinlich habe ich IP_CONTROL_2 irgendwie falsch eingebunden...

Also irgendwie sieht es für mich so aus,
als ob das Problem beim IP_C.ERROR liegt.
Im Gegensatz zu dem was ich am Anfang schrieb, ist nach dem "unsauberen " Disconnect
nämlich der Error auf 16#FD000000, und irgendwie geht der nicht wieder weg (Ausser bei Neustart)
Wenn ich das richtig sehe ist ja dann auch C_ENABLE false und dadurch kann es ja nicht gehen.
Oder habe ich hier einen Denkfehler??

Hallo peewit,

danke, dass du so spät noch Zeit dafür hast.
Ich hänge mal ein Bild von meiner Testschaltung dran,
damit du weiss, wovon ich rede...
(vieleicht habe ich ja auch einfach noch einen blöden Fehler drin..)

Folgende Vorgehensweise:
1. Ich setze ServerActive. Jezt kann ich mich vom Client verbinden.
(Wenn verbunden schickt mein Client  aller 5s ein "Keepalive Paket"

2. Wenn ich ServeActive auf false setze, wird die Verbindung abgebaut (logisch)
Wenn ich wieder auf true setzte, gibt es wieder eine Verbindung
(mein Client versucht aller 30s einen Reconnect)

3. Wenn ich vom CLient aus die Verbindung sauber(!) beende, kann ich mich jederzeit
wieder verbinden.

4. Wenn ich aber die Verbindung unsauber trenne (ich simuliere das, indem ich den Client per Task-Manager abschiesse,
sodass er nicht dazu kommt sich sauber abzumelden, starte den Client neu und versuche mich zu verbinden,
kommt oben geschilderter Fehler.
Genau diesen (fehlgeschlagenen) Verbindungsversuch zeigt der Wireshark Mitschnitt.

Das Blöde ist, dass dein Vorschlag, den C_Enable kurz auf false und wieder auf true zu setzen, leider nix bringt.
Erst nach einem Warmstart oder Kaltstart kommt ein neuer Verbindungsversuch zu stande...





[gelöscht durch Administrator]

weiter geforscht:

1. Das Problem wird tatsächlich durch einen "unsauberen" Verbindungsabbruch provoziert.
2. Dieses "connected" mit sofortigem "Socket closed by remote" bekomme ich auch wenn C_ENABLE false ist
3. (und das ist wirklich blöd) kurzes false auf C_ENABLE fürht leider nicht dazu, dass es anschliessend wieder funktioniert..

Wireshark anbei...

[gelöscht durch Administrator]

Muss mich nochmal melden.
Ich hab den Zustand jetzt nochmal überprüft.
Das tritt relativ selten auf, aber wenn,
lehnt der Server (IP_CONTROL) die Verbingung nicht etwa ab,
sondern sie kommt kurz Zustande und wird dann wieder abgebaut.
Am Client bekomme ich "Socket closed by remote)
Zustände IM IP_CONTROL sind nach wie vor
IP_C.C_STATE = 0
IP_C.ERROR = 0

ok, das hilft mitr erst mal weiter,
vielen Dank...

Hallo Peewit,

Erst mal danke für die schnelle Antwort.

Es geht um Worx Epress 6.30.1202
ne Phoenix ILC131 mit FW 4.30

und du hast Recht, ich habe das gerade nochmal überprüft,
wenn der Client den Connect korrekt beendet, klappt der reconnect.
Aber es kann ja mal eine "unexpected" Trennung geben
(Client reboot oder Ethernet unterbrochen)
Was kann man dann tun?
Wäre ein Watchdog mit einer Art Heartbeat eine Lösung,
der dann einen Timeout erzeugt? und wenn ja, wie kille ich dann dann
die tote Verbindung im IP_CONTROL?

Gruß,

Uwe

Hallo,

ich benutze IP_CONTROL2 für einen TelnetServer.
Es soll sich jederzeit ein Client mit dem Server verbinden können,
ohne dass irgendwelche Timeouts auftreten.

Ich habe IP_C.C_MODE auf 4
IP_C.R_OBSERVE aud false und
IP_C.C_ENABLE auf true

Ich kann mich mit dem Client genau einmal verbinden.
Nach dem Trennen geht kein neuer Connect.
Muss da noch was re-initialisiert werden ??