Telexforum.de

Ich hatte mich damals bewusst für ein (mehr oder weniger) zustandsloses Protokoll entschieden, d.h. jederzeit darf alles gesendet werden, solange es format-technisch die Anforderung erfüllt.
Wenn ein Empfänger mit einem konkreten Telegramminhalt nichts anfangen kann ist es dem Empfänger überlassen die Verbindung zu trennen oder das Telegramm zu ignorieren.
Letzteres ist m.E. einfacher zu realisieren und so habe ich es dann auch gemacht.
Dass es dann bei Abweichungen von der Spezifikation zu Funktionslücken oder Komfortbeschränkungen führt, ist die logische Folge.
Zum i-Telex selbst: Ja, im Verbindungszustand ersetzt das Ack-Telegramm das Lebenszeichen. Ggf wird das Ack-Telegramm mehrfach mit identischem Inhalt versandt.
Das Lebenszeichen wird also nur verwendet, wenn noch keine 5-Bit-Daten übermittelt worden sind.
Jedoch sollten neue Implementierungen diese Regel nicht voraussetzen, i-Telex tut es auch nicht.
EIne klare Lücke ist in der Spezifikation vorhanden: Es gibt leider kein klares Zeichen, dass bei der angewählten Station der Fernschreiber angelaufen ist.
Bei 95% der Anwender indirekt doch, da dort das Datum gedruckt und an den Absender gesendet wird.
Bei 5% ist aber erstmal "Stille", da passiert es ggf dass einer auf den anderen wartet.

Hallo Fred,
so, wieder was dazugelernt. Aber es wirft bei mir die Frage auf, welcher Zustand das ist, wenn noch keine 5-Bit Daten übermittelt sind. Nach meinen Traces sendet eine Station nach dem Durchwahlpaket ein einsames Baudotzeichen 31(BU). Zumindest bei Thomas (Blf) ist das so. Dann sende ich als angerufener mein Datum/ Uhrzeit. Wir haben mal darüber diskutiert , wann wodurch ein Fernschreiber am angerufenen Ende eingeschaltet wird. Da hast Du geschrieben, das geschieht mit dem ersten Baudotzeichen. Das muss natürlich vor dem Text kommen, damit die mechanische Maschine anlaufen kann. Ist das das Zeichen was in Traces immer wieder erscheint und wird es ganz normal zur Maschine durchgeroutet oder abgefangen? Ich verwerfe den Inhalt der ersten 2 Zeichen direkt nach dem DW-Paket.
Gibt es ältere Software die nur auf Heartbeats und nicht auf Ersatz Ack's reagiert?
Gruß
Willi

Ich lerne auch gerade einiges dazu.

Fernschreiber hat geschrieben: ↑Mi 15. Jan 2020, 14:49 Hallo Fred,
so, wieder was dazugelernt. Aber es wirft bei mir die Frage auf, welcher Zustand das ist, wenn noch keine 5-Bit Daten übermittelt sind.

Genau da ist die Lücke...
Das Binärprotokoll soll auch konzeptuell "Dienst-Kanäle" erlauben, also Verbindungen, wo gar nicht Baudot geschrieben wird.
Das hat die Folge, dass es ein klares Beginn-Zeichen geben müsste, was es aber momentan noch nicht gibt.

Fernschreiber hat geschrieben: ↑Mi 15. Jan 2020, 14:49 Nach meinen Traces sendet eine Station nach dem Durchwahlpaket ein einsames Baudotzeichen 31(BU). Zumindest bei Thomas (Blf) ist das so.

Das halte ich eher für einen Fehler oder eine Unzulänglichkeit beim Anlauf des anrufenden Fs. Gewollt ist dies sicher nicht.
Ich schlage folgende Spezifikation vor: Die angerufene Station muss nach einem Empfang des Durchwahl-Pakets oder eines Baudot-Daten-Pakets oder eines Ack-Pakets den Empfangsfernschreiber einschalten oder im Fehlerfall das "Reject-Paket" senden.
Das Ack-Paket ermöglicht dann auch die Aktivierung ohne Sendung einer Durchwahl.
Echte i-Telex-Stationen senden aber immer ein Durchwahl-Paket, auch bei Durchwahl "keine" (=Wert 0).

Fernschreiber hat geschrieben: ↑Mi 15. Jan 2020, 14:49 Dann sende ich als angerufener mein Datum/ Uhrzeit. Wir haben mal darüber diskutiert , wann wodurch ein Fernschreiber am angerufenen Ende eingeschaltet wird. Da hast Du geschrieben, das geschieht mit dem ersten Baudotzeichen.

Schade, da haben wir uns leider missverstanden.
Spätestens mit dem ersten Baudot-Zeichen. Das Durchwahlpaket macht doch eigentlich klar, dass jetzt "getextet" werden soll.

Fernschreiber hat geschrieben: ↑Mi 15. Jan 2020, 14:49 Das muss natürlich vor dem Text kommen, damit die mechanische Maschine anlaufen kann. Ist das das Zeichen was in Traces immer wieder erscheint und wird es ganz normal zur Maschine durchgeroutet oder abgefangen? Ich verwerfe den Inhalt der ersten 2 Zeichen direkt nach dem DW-Paket.

Wenn ein i-Telex ein Baudot-Paket empfängt und die Maschine noch nicht läuft, dann wird die angeschmissen und zwei Sekunden gewartet. Verworfen werden keine Zeichen!

Fernschreiber hat geschrieben: ↑Mi 15. Jan 2020, 14:49 Gibt es ältere Software die nur auf Heartbeats und nicht auf Ersatz Ack's reagiert?

Nein.
Sogar im Quelltext steht schon seit Urzeiten:
ITELEXC_QUITT = 0x06, //!< Meldet Empfangsbereitschaft und Anzahl bereits verarbeiteter Zeichen.

Die rufende Station wertet nur den Empfang von Baudot-Paketen oder Ack-Paketen als Bestätigung, dass die gerufene Seite empfangsbereit ist. Vorher werden auch keine eigenen Datenpakete gesendet!
Insofern wundere ich mich fast, dass du (Willi) erreichbar bist, da eigentlich ein Deadlock bestehen müsste: Deine Anlage wartet auf das erste Zeichen vom Anrufer, bevor du das Datum sendest. Der Anrufer wartet aber auch... Oder?

Das eben beschriebene Verhalten führt auch dazu, dass ein Gerät dass als angerufene Station kein erstes Zeichen senden möchte und auch kein Ack verwenden möchte, scheinbar dem Anrufer die Empfangsbereitschaft nicht signalisieren kann. Aber das geht doch: Mit einem Leeren Baudot-Data-Paket, also 0x02 0x00.

...hier nochmal ein Beispiel für den Verbindungsaufbau zu Willis Anlage:

18:14:02,83: iTelex(61211): Verbindungsaufbau zu Hostname telex.telephontechnik.de = 93.215.68.116 Port 134
18:14:02,90: iTelex(61211): Diagnoseausgabe Level 2: (NULL) ...gespeichert
18:14:02,90: iTelex(61211): Client-Socket #1 iTelex erfolgreich geoeffnet -> sende Durchwahl 0 und Version 1
18:14:02,91: iTelex(61211): Diagnoseausgabe Level 3: (NULL) ...gespeichert
18:14:03,57: iTelex(61212): Socket Sendung: (10) 07 05 01 38 34 35 00 01 01 00 --> Res 10 SumAnz 0/00
18:14:03,59: iTelex(61213): Socket Empfang: (3/3) 07 01 01 --> BufUsed 3
18:14:03,59: iTelex(61213): Protokollversion-Vorschlag 1 empfangen
18:14:07,02: iTelex( 5974): Socket Sendung: (2) 00 00 --> Res 2 SumAnz 0/00
18:14:07,97: iTelex( 8958): Socket Empfang: (2/2) 00 00 --> BufUsed 2
18:14:11,02: iTelex(18499): Socket Sendung: (2) 00 00 --> Res 2 SumAnz 0/00
18:14:11,75: iTelex(20797): Socket Empfang: (2/2) 00 00 --> BufUsed 2
18:14:12,89: iTelex(24437): Socket Empfang: (3/3) 02 01 1F --> BufUsed 3
18:14:12,90: iTelex(24437): Angerufener hat geantwortet -> Einschaltung intern
18:14:12,90: iTelex(24437): ModusWechsel von 2 nach 4.
18:14:13,00: iTelex(24439): Socket Sendung: (3) 06 01 00 --> Res 3 SumAnz 0/00
18:14:13,02: iTelex(24440): Socket Empfang: (18/18) 02 01 1F 02 01 1F 02 01 1F 02 01 1F 02 01 1F 02 01 1F --> BufUsed 18
18:14:13,10: iTelex(24560): Socket Empfang: (3/3) 02 01 02 --> BufUsed 3

blau: Beide Stationen sind im Wartezustand, hier könnte ein Deadlock eintreten. Aber vielleicht muss Willis Vermittlung auch erstmal durchstellen, dann wäre alles richtig!
rot: Willi sendet das erste Zeichen (ein Bu), meine Station / Fs wird dadurch eingeschaltet.
grün: meine Station antwortet mit "ich habe noch nichts gedruckt, kiste läuft aber"
Danach wieder schwarz: Willi sendet Text. Warum denn jeden Code einzeln, und nicht gebündelt? Ist aber nicht syntaktisch falsch. Immer noch besser als jeden Code in einem TCP-Packet zu versenden.