Dass TCP-Verbindungen übers Internet oft abreißen, habe ich bisher so nicht beobachten können. TCP ist sehr fehlertolerant, z.B. liegt der native TCP-Sitzungs-Timeout einer bestehenden Verbindung je nach Einstellung im Betriebssystem meist im Stundenbereich. Da viele Anwendungen (und ggf. Firewalls dazwischen) ungeduldiger sind, wird oft ein Timeout der Anwendung darübergelegt -- inkl. eines Mechanismus zum Offenhalten der Verbindung, siehe Heartbeat/Acknowledge. Wenn dieser Timeout zuschlägt, schließt die Anwendung aktiv die TCP-Verbindung. Oder das Betriebssystem hat aus irgend einem Grund die Anwendung selbst abgeschossen, oder eine Firewall hat die Geduld verloren, und weitere ankommende Pakete werden mit RST quittiert, was einer Trennung gleichkommt.Fernschreiber hat geschrieben: ↑Mi 25. Mai 2022, 12:02 das mit der Bemerkung das auch ohne "03" Paket die Welt nicht untergeht war darauf bezogen, das ein Abbruch einer TCP-Verbindung nicht immer steuerbar ist. [...] Bei "echter" Unterbrechung ( Fehler irgendwo in Übertragungsstrecke) ohne Reconnect kommt dann diese (ich nenne es statt Fehler- mal Hinweis-) Meldung. Das dieser Effekt auch zwischen i-telex-Hardware auftritt zeigt doch, das die End to End Verbindungen so stabil nicht sind.
Wenn bei einer bestehenden TCP-Verbindung mal Pakete verloren gehen, passiert mit der Verbindung erstmal nichts, die Anwendungen könnten problemlos weiterwarten und das Protokoll kümmert sich -- sobald es wieder eine funktionierende Route für die Pakete gibt -- um die Anforderung der verlorenen Pakete und bringt die "nachgelieferten" wieder in die richtige Reihenfolge.
Im Übrigen benutzt auch der Centralex zu jedem "Kunden" eine dauerhafte TCP-Verbindung, und das scheint doch recht stabil zu laufen. (Hat da jemand Erfahrungen dazu? )
Seit HTTP/1.1 nicht mehr (anno 1999, Keepalive-Option). Wegen der Leistungsprobleme, die das ständige Verbinden und Trennen für jede Einzelanfrage verursachen.Fernschreiber hat geschrieben: ↑Mi 25. Mai 2022, 12:02 Nicht umsonst nutzt HTTP das TCP in Basisversion u.a. nur als 1mal- (one shot) Verbindung.
Da komme ich jetzt nicht mehr mit ... Auf meinem Pi läuft piTelex wochenlang ohne Unterbrechung bzw. Fehler. Der gelegentliche geplante Neustart ist nur bei Kernelupdates nötig. Was für einen prinzipiellen Vorteil hat der ATmega denn hier?Fernschreiber hat geschrieben: ↑Mi 25. Mai 2022, 12:02 Es liegt auch in der Natur der Sache das ein pi leichter und öfter seinen Dienst versagen kann ( und damit kein "03" mehr schicken kann egal wie es programmiert ist) wie der AT-Mega im i-Telex.
Diese Betriebssystemfehler bekomme ich im Programm zumindest mit (Socket-Schreibfehler). Die sind aber wirklich extrem selten. Ich kann dir aus den Logs meines Pi vmtl. keine fünf davon zusammenklauben.Fernschreiber hat geschrieben: ↑Mi 25. Mai 2022, 12:02 Zu deinem Statement in #11:
1.Wenn wir trennen, z.B. wegen ST-Bedienung
Selbst wenn Du ausschliessen kannst das in deinem Code keine Lücke besteht das zu umgehen, ist da auch noch das OS. Das macht den Socket u.U.
zu (getrieben von internen oder externen Einflüssen) , das kriegtst du garnicht so schnell mit und schreibst noch in den Sendepuffer, welcher dann auch weg ist. Kommt natürlich nie an.
Um hier Erfahrungen zu sammeln, schreibe ich den gesamten Verkehr über den Telex-Port meiner Maschine auf der Transportebene mit. Gelegentlich sieht man mal eine TCP Retransmission. Größere Zuverlässigkeitsprobleme habe ich bisher keine finden können, mit Ausnahme des gelegentlich holprigen WLAN. Hier habe ich alle paar Tage bis Wochen ein Verbindungsausfall von wenigen Sekunden, i.d.R. fehlgeschlagenes Roaming. Dementsprechend versagt selten mal ein Verbindungsselbsttest, den piTelex alle 20 s ausführt. In der Regel überschneiden sich die beiden aber nicht.
Grüße
Björn