reconnect bei IPCONTROL

[uweissbach]

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

[peewit]

hallo

eine einzelne instanz deines programmes mit ip_control ermöglicht nur eine einzige verbindung zu einen client.

ich würde mal behaupten das dein client die verbindung nicht beendet !

wenn du nun deinen client einfach schliesst gibt es keine offizielle beendigung der verbindung
der port bleibt somit für deine ip_control instanz belegt.


ganz sicher könnten wir mit einen wireshark mitschnitt sehen was wirklich passiert.

welche sps und firmware hast du drauf

[uweissbach]

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

[peewit]

das problem ist das es bei einer telnet verbindung keine art lebenszeichen gibt
auche 5 minuten ohne irgendwas zu versenden kann so gewollt sein !

du kannst eine überwachung einbauen, wenn innerhalb einer zeit kein zeichen empfangen wird dann stoppst du die verbindung

z.b. die timeout zeit etwas höher setzen und  IP_C.R_OBSERVE = TRUE machen
dann sollte bei inaktivität ein receive timout fehler kommen und darauf kannst du IP_C.C_ENABLE kurz auf false und true setzen

ein notnagel ist wenn du mehr als eine telnet server instanzen betreibst
dann erhält wenn der eine belegt ist er andere die client anfrage....

und du merkst dann das problem nicht sofort

tcp verbindungen die über längere zeit ohne aktivität sind werden meines wissens irgendwann von der sps eliminiert.

[uweissbach]

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

[uweissbach]

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

[peewit]

um hier eine kommentar abzugeben brauche ich einen wireshark mitschnitt
erst dann sieht man was wer macht...

[uweissbach]

Wireshark anbei...

[gelöscht durch Administrator]

[uweissbach]

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

[peewit]

hi

damit ich dir helfen kann musst du mir das alles etwas besser vorkauen

wireshark mitschnitt schön und gut aber ohne kommentar

ich sehe nur das nach verbindungsaufbau gleich wieder vom server abgebaut wird.

was war vorher
was dann
was war danach

und dann solltest du den ganzen verlauf aufzeichnen

nach der unsauberen client beendigung solltest du mal alle ip_control daten grafisch festhalten
ipc datenstruktur und die lokalen variablen vom ip_control

wenn der client sich sauber abmeldet sollte es auch immer wieder funktionieren !
ich kenne das nicht anders....

ich habe in meiner network lib im demo ordner auch ein telnet demo drinnen
da kannst du dich mit win-telnet oder putty-telnet immer wieder verbinden

[uweissbach]

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]

[uweissbach]

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

[uweissbach]

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

[peewit]

also so simpel im grafischen modus den ip_control zu programmieren ist eher problematisch

hast du denn in der network bibliothek im ordner "demo" die demos schon angesehen ?

und das telnet_Send beispiel ausprobiert das hier im forum herum geistert

http://www.oscat.de/community/index.php/topic,1071.msg6404.html#msg6404