Fehlermeldungen vom I-Telex

[BjoernS]

Hallo zusammen!

es geht nicht nur um das sorgfältige Schliessen der Sockets. Darüber haben wir ja schon mal an anderer Stelle diskutiert. Diese Meldung kam auf den I-Telex-Systemen auch nachdem ich mit meinem ersten Rundsendeprogramm getestet habe. Ich hatte lediglich die Versendung des Endepakets "03" auskommentiert. Nach Aktivierung war die Fehlermeldung dann weg. Das nur mal als Tipp.

Danke schonmal Willi, habe das geprüft. Die Netzwerkroutine ist eine große While-Schleife, und sobald die Ausführung da rausfällt, wird bei nicht-ASCII-Verbindungen ein END ausgesendet (seit 2020, davor wurde auch bei ASCII ein END verschickt). Das passiert zu folgenden Gelegenheiten:

1. Wenn wir trennen, z.B. wegen ST-Bedienung und
2. wenn wir von der Gegenstelle ein END-Telegramm empfangen.

Fall 1 ist recht klar (wenn auch nicht absolut vorgeschrieben). Die Spec fixiert Fall 2 nicht vollkommen. Denn sie sagt

The receiving station should switch off the printer and should close of the TCP connection [...] The station which receives this packet may immediately close the TCP connection.

... also SOLLTE und DARF. An der Stelle sind wir so vorgegangen, lieber ein END mehr als eins zu wenig. Vielleicht ist dieses END zu viel das Problem? (Fred, hast du ggf. einen diesbezüglichen Verdacht?)

Bei einem Socketfehler wird nichts mehr gesendet (wohin auch?). Im Kontext der o.g. Schleife werden alle Exceptions gefangen/protokolliert und danach der Socket ordentlich geschlossen.

Ansonsten, probiert gerne bei mir (844767 twtr d) aus. Wenn es jemand reproduzieren kann bitte Bescheid sagen, ich schreibe bei diesem Anschluss alles auf Netzwerkebene mit.

Franz, hattest du das bei mir schonmal? (Und, lese ich richtig, das Problem tritt bei i-Telex vs. i-Telex auf?)

Grüße


Björn

[Franz]

Hi Björn, ja eindeutig auch bei I-Telex vs. I-Telex, und soweit bekannt, immer bei Eingang von FS, würde Dich aber dann später mal mit kurzen Ausgangs-FS belästigen, um zu schauen, ob es auch beim Senden auftritt, gerne kannst Du mir auch kurze Teste zuschicken ;-) Danke ......VG Franz

[detlef]

Die Spec fixiert Fall 2 nicht vollkommen. Denn sie sagt

The receiving station should switch off the printer and should close of the TCP connection [...] The station which receives this packet may immediately close the TCP connection.

... also SOLLTE und DARF.

Das verstehe ich nicht. Im Wiki steht zum End Packet: "The station which receives this packet may immediately close the TCP connection". Das heisst für mich, Verbindung schließen und nichts mehr senden.

EDIT: Ich habe das gerade mal mit WinTlx simuliert. Wenn ich nach einem empfangenen End Packet selbst ein End Packet zurücksende, passiert nichts. Das scheint also kein Problem zu sein.

Trotzdem sehe ich keinen Sinn darin. Wenn mir die Gegenstation mitteilt, dass sie die Verbindung beenden möchte, dann muss ich das ja nicht der Gegenstation noch mal mitteilen. Ich fände es gut, wenn alle Implementationen etwas näher an der Spezifikationen bleiben würden. Wer weiss ob alle bestehenden oder zukünftigen i-Telex-Programme damit klar kommen. Wie WinTlx an der Stelle reagiert, weiß ich auch nicht. Das kann ich schlecht testen.

[BjoernS]

Moin Detlef!

Das verstehe ich nicht. Im Wiki steht zum End Packet: "The station which receives this packet may immediately close the TCP connection". Das heisst für mich, Verbindung schließen und nichts mehr senden.

Das ist auch eine richtige Vorgehensweise. "may" heißt "darf", nicht "muss". In der Tradition der Internetstandards interpretiert hieße das "tatsächlich optional" (truly optional). Dort ist sogar die zusätzliche Forderung, dass jeder Andere damit umgehen können muss, wenn diese Option nicht umgesetzt wird (Robustheitsgrundsatz). Mag zugegebenermaßen in diesem Fall recht weit gegriffen scheinen.

EDIT: Ich habe das gerade mal mit WinTlx simuliert. Wenn ich nach einem empfangenen End Packet selbst ein End Packet zurücksende, passiert nichts. Das scheint also kein Problem zu sein.

Das ist schonmal gut zu wissen. Die Suche geht weiter ... Bin auf Franz' Rückmeldung gespannt.

Trotzdem sehe ich keinen Sinn darin. Wenn mir die Gegenstation mitteilt, dass sie die Verbindung beenden möchte, dann muss ich das ja nicht der Gegenstation noch mal mitteilen.

Einfache Implementierungen könnten darauf angewiesen sein. Ich hab da mal vor einer Apotheke ... Nicht dass das die primäre Überlegung beim derzeitigen piTelex-Code war, zumindest soweit ich weiß.

Ich fände es gut, wenn alle Implementationen etwas näher an der Spezifikationen bleiben würden. Wer weiss ob alle bestehenden oder zukünftigen i-Telex-Programme damit klar kommen.

Sehe ich auch so. Wenn in der Spec aber "may" steht, heißt das auch ohne RFC 2119 auf Deutsch erstmal "darf", nicht "muss". Vielleicht kann Fred da etwas Licht ins Dunkel bringen, wie er es gemeint hat.

And now for something completely different: "The sending station shall wait for the opposite station to close the TCP connection." "shall" bedeutet soviel wie "must", aber das tut piTelex z.B. nicht. Wenn ich den Code richtig lese, aber auch i-Telex und WinTlx nicht. Da wird direkt die eigene Seite der Verbindung geschlossen.

Grüße


Björn

[detlef]

And now for something completely different: "The sending station shall wait for the opposite station to close the TCP connection." "shall" bedeutet soviel wie "must", aber das tut piTelex z.B. nicht. Wenn ich den Code richtig lese, aber auch i-Telex und WinTlx nicht. Da wird direkt die eigene Seite der Verbindung geschlossen.

Ist das nicht ein Widerspruch zu "The station which receives this packet may immediately close the TCP connection."

Das mit dem "shall", "may" und "should" würde ich nicht auf die Goldwaage legen. Ich weiß nicht, ob Fred diese Worte wirklich so bewusst gewählt hat. Aber er kann ja selber mal erklären, wie er das gemeint hat.

[Fernschreiber]

Hallo zusammen,
Jetzt muss ich auch noch etwas beitragen. Am letzten Punkt von Björn bin ich auch etwas ins grübeln gekommen. Wie soll ein Vorgang auf etwas warten müssen, was er nicht mal anstossen muß? An einigen Punkten (siehe unsere Diskussionen in den letzten Jahren ) ist die Spec mehr oder weniger zum
einfachen Leitfaden geworden. Da ist es wirklich schwierig "nah an der Spec" zu bleiben. Ich bin ja nun einer der Verfechter dieser Spezifikation, aber das simple "03"Paket zeigt mal wieder wo es hakelt. Die Begriffe "shall, should, will, must und may" haben ihre feste Begrifflichkeit und ich hoffe sehr das Fred die kennt. Ansonsten sollten wir eine verbindliche Version in unserer Muttersprache erstellen. Beim "03er" ist eine Diskussion umso sinnloser, da es auch ohne das Paket gehen muß und geht. Lediglich die ein/abschaltbaren Fehlermeldungen bringen das immer wieder hoch.
Nebenbei: auch meine SW schickt aus Höflichkeit ein "03" zurück, war noch nie ein Thema. Die Bescheibung " möge sofort die TCP-Verbindung schliessen" erlaubt durchaus noch eine Rückmeldung. Wie Fred mal schrieb, der Empfänger muß mit den Paketen umgehen können, komme was wolle. Ich habe letztens bei den Tests mit Dieters Problem mal die Durchwahl vor der Versionsaushandlung geschickt, ging auch. Würde bei mir nicht funktionieren, gehört logisch dahinter.
Interessanter ist für mich, warum solche Fehlermeldungen immer mal wieder in den Fokus geraten und dann in der Versenkung verschwinden bis wieder
jemandem was auffällt. Liegt das an den neuen Mitstreitern die evt. aus Unwissenheit und Vorsicht etwas genauer hinschauen oder an Nutzern die täglich an den Ebenen der Fehlermeldungen rumschrauben oder an tatsächlich aufkommenden Inkompatibilitäten der Endstellen?
Bisher haben wir (als Entwickler) einiges an Energie da reingesteckt um gemeinsam den Tücken auf die Spur zu kommen, möge es so bleiben.
Gruß
Willi

[detlef]

Interessanter ist für mich, warum solche Fehlermeldungen immer mal wieder in den Fokus geraten und dann in der Versenkung verschwinden bis wieder jemandem was auffällt.

Die "Zeitüberschreitung bei Wiederaufnahme der Verbindung" habe ich regelmäßig immer mal wieder. Das interpretiere ich nicht als Fehlermeldung sondern einfach als ein Problem beim Auf- oder Abbau der Verbindung. Man weiß ja auch nie, was zu dem Zeitpunkt an der Gegenstelle gerade passiert ist.

[BjoernS]

Moin zusammen!

"The sending station shall wait for the opposite station to close the TCP connection."

Ist das nicht ein Widerspruch zu "The station which receives this packet may immediately close the TCP connection."

Eigentlich nicht ... Der Sender des "END" soll warten, der Empfänger darf sofort schließen.

Beim "03er" ist eine Diskussion umso sinnloser, da es auch ohne das Paket gehen muß und geht. Lediglich die ein/abschaltbaren Fehlermeldungen bringen das immer wieder hoch.

Das wiederum steht so nicht in der Spezifikation Denn die sagt:

When in a Texting Baudot state, the reception of a “reject” or “end” end package returns the i-Telex service to the Disconnected state and terminates the TCP session.

[...]

In Texting Baudot mode, any station may close the existing TCP connection, then the calling station should try to reconnect within 30 seconds without any influence to the communication handshake. This feature allows seamless reconnection in case of an unintended cut-off.

Das END ist ja genau dafür gedacht, diese 30-s-Wiederaufnahme abzumoderieren. Ich glaube die wenigsten Implementierungen außer dem originalen i-Telex haben diese 30-s-Sache drin. Wenn man END weglässt, löst man bei der Gegenseite die 30-s-Pause aus, während der sie für eingehende FS geperrt ist, weil eine Wiederaufnahme der Verbindung versucht wird.

Die "Zeitüberschreitung bei Wiederaufnahme der Verbindung" habe ich regelmäßig immer mal wieder. Das interpretiere ich nicht als Fehlermeldung sondern einfach als ein Problem beim Auf- oder Abbau der Verbindung. Man weiß ja auch nie, was zu dem Zeitpunkt an der Gegenstelle gerade passiert ist.

Aber wo ich das jetzt gerade lese, vielleicht hat es wirklich damit zu tun ... Hypothese: Das anrufende i-Telex hat von seiner Gegenstelle die Verbindung ohne END-Telegramm getrennt bekommen, versucht wiederzuverbinden und scheitert nach 30 s.

Grüße


Björn

[detlef]

Moin zusammen!

"The sending station shall wait for the opposite station to close the TCP connection."

Ist das nicht ein Widerspruch zu "The station which receives this packet may immediately close the TCP connection."

Eigentlich nicht ... Der Sender des "END" soll warten, der Empfänger darf sofort schließen.

Ja, stimmt.

[Fernschreiber]

Hallo Zusammen, hallo Björn,

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. Es ist natürlich besser protokolltechnisch sauber im Applikationslayer darauf hinzuweisen das ein Ende bevorsteht, aber Zufälle wie
Stromausfall, Netzkomponenten (Switche,Router),WLAN bzw. Routingprobleme im Netz können das verhindern. Dann ist die Wartezeit von 30s auf ein neuen Anrruf mit der gleichen IP als Reconnect nur sinnvoll, wenn Dieser auch geschieht. Fred's Überlegung in dieser Sache ist da ja ganz praktisch und lässt einen ungewollten Ausfall relativ unsichtbar bleiben. 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. Nicht umsonst nutzt HTTP das TCP in Basisversion u.a. nur als 1mal- (one shot) Verbindung. Es muß aber im Regelfall das Protokoll eingehalten werden. 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. Vielleicht sollten die Meldungen auch dahingehend priorisiert (gedruckt) werden, ob es echte Beeinträchtigungen oder Luxusprobleme sind.
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.
Auch wenn ich die Reconnectmöglichkeit (wie schon mal beschrieben) nicht eingebaut habe, ist es ungewollt ein "Feature" der alten analogen Übertragungstechnik (hier WT). Diese Verbindungen (wie auch SWFD) wurden mit Impulskennzeichen gesteuert und wenn eine Verbindung aufgebaut war, gab es praktisch auf Kanalebene keine aktive Überwachung mehr. Wir konnten damals durchaus im Betrieb Ersatzschaltungen machen (Unterbrechung mehrere Sekunden) ohne das bestehende Leitungen ausgelöst hätten. Es war eher ein technischer Aufwand diese Leitungen bei Kabelfehlern (12 bis 10800 Kanäle / Doppelader oder Koax) automatisch zu sperren und damit die Wähler und Übertragungen wieder freizugeben bzw. den Umwertern mitzuteilen, das Bündel ist nicht nutzbar.

Gruß
Willi