Zweck des Ack-Telegramms im i-Telex-Protokoll

Fachforen für Entwickler und Bastler
Benutzeravatar

Topic author
FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Zweck des Ack-Telegramms im i-Telex-Protokoll

#11

Beitrag: # 15611Beitrag FredSonnenrein »

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.
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.

Fernschreiber
Rank 3
Rank 3
Beiträge: 230
Registriert: Sa 17. Dez 2016, 15:28
Wohnort: Münster
Hauptanschluß: 25060 schuett d
Kontaktdaten:

Re: Zweck des Ack-Telegramms im i-Telex-Protokoll

#12

Beitrag: # 15615Beitrag Fernschreiber »

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
Hauptnummer 25060
25061117 ufs lingen  T68d     Dw 890 
89899 schuett d        T1000   Dw 894  Hauptstelle
826433b vdm d         T100     Dw 891
841226 mizg d           Lo15     Dw 895
84635 norman d        T100     Dw 896
Benutzeravatar

detlef
Rank 12
Rank 12
Beiträge: 3542
Registriert: Do 28. Mär 2019, 09:10
Wohnort: Marburg
Hauptanschluß: 7822222 hael d

Re: Zweck des Ack-Telegramms im i-Telex-Protokoll

#13

Beitrag: # 15616Beitrag detlef »

Ich lerne auch gerade einiges dazu. :thumbup:
Gruß, Detlef

i-Telex: 7822222 (T1000), 114288 (F1300), 211230 (T100Z), 96868 (T37), 24394 (T68d)
Konferenzdienst: 11160 / 11161, Rundsender: 11162 / 11163 , Baudot-Bilder: 11166
Chat-GPT: 11168, Mail- und Fax-Dienst: 11170 / 11171, hist. Auskunft 1987: 40140, Wetterdienst: 717171
Benutzeravatar

Topic author
FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Zweck des Ack-Telegramms im i-Telex-Protokoll

#14

Beitrag: # 15621Beitrag FredSonnenrein »

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.
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

Topic author
FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Zweck des Ack-Telegramms im i-Telex-Protokoll

#15

Beitrag: # 15622Beitrag FredSonnenrein »

...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.
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Antworten

Zurück zu „Entwickler-Ecke“