Diskussionen und Fragen zum i-Telex-Binärprotokoll

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

Diskussionen und Fragen zum i-Telex-Binärprotokoll

#1

Beitrag: # 17768Beitrag FredSonnenrein »

Hallo zusammen,

da nun doch so einige Implementierungen vorhanden sind, die das i-Telex-Protokoll verwenden, möchte ich hier einen entsprechenden Diskussions-Faden aufmachen.

Generell ist unter den folgenden Links stets eine aktuelle Protokoll-Beschreibung aufzufinden:

https://svn.code.sf.net/p/itelex/code-0 ... cation.doc
https://svn.code.sf.net/p/itelex/code-0 ... cation.pdf

Gleich zur Abgrenzung: Das Protokoll zur Teilnehmer-Server-Kommunikation ist dort zwar auch beschrieben, sollte aber bei Bedarf an anderer Stelle diskutiert werden.

Alle Entwürfe zu Diskussion von Neuerungen werden hier eingestellt:

https://svn.code.sf.net/p/itelex/code-0 ... _draft.doc

Angeregt durch diesen Beitrag schreibe ich gleich mal die erste Erläuterung zum Versions-Paket:

Bisher ist tatsächlich nur Version 1 genutzt, wobei gerade eine Erweiterung auf Version 2 in Arbeit ist. Entwarnung vorweg: Version 2 ist nur für "Spezialisten" sinnvoll und wird voraussichtlich in das "original" i-Telex nicht integriert werden.

Das Versions-Paket hat den Zweck, dass Erweiterungen machbar sind, ohne dass alle Anwender des i-Telex wegen Inkompatibilität ausgeschlossen werden.

Somit gilt der Grundsatz: Version 1 sollten alle Implementierungen beherrschen. Daher ist das Versionspaket nicht zwingend in jeder Kommunikation enthalten. Beispielsweise sendet ein "besetztes" i-Telex das Reject-Paket ohne "Versionsvorspann".

Dennoch sendet ein "original" i-Telex beim Verbindungsaufbau als erstes ein Versionspaket und beantwortet dieses im Regelfall auch. Alle "Fremd-Implementierungen" sollten dies auch tun.

Generell zur Arbeitsweise des "original" i-Telex: Das Programm ist ensprechend einer Zustandsmaschine strukturiert. In einer großen "Endlosschleife" werden alle denkbaren Ereignisse ausgewertet und behandelt. Daher ist es nicht ohne weiteres möglich, den Ablauf der Kommunikation exakt strukturiert vorzugeben.

Und nun freue ich mich auf Fragen und Anregungen.
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag (Insgesamt 2):
Fernschreiberdetlef
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

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

Re: Diskussionen und Fragen zum i-Telex-Binärprotokoll

#2

Beitrag: # 17775Beitrag detlef »

FredSonnenrein hat geschrieben: Mo 20. Apr 2020, 11:42 Gleich zur Abgrenzung: Das Protokoll zur Teilnehmer-Server-Kommunikation ist dort zwar auch beschrieben, sollte aber bei Bedarf an anderer Stelle diskutiert werden.
Das fände ich auf jeden Fall wichtig. Denn in Bezug auf den Teilnehmerserver hätte ich einige Wünsche/Vorschläge, wenn dort mal eine Erweiterung ansteht.

Beim i-Telex-Protkoll brennt mir im Moment nichts auf den Nägeln.

Zu dem Thema "automatischer Wechsel von Ascii nach Baudot-Texting" möchte ich noch anmerken, dass es mich auch gewundert hat, dass i-Telex unter bestimmten Umständen den fliegenden Wechsel von Ascii nach Baudot bei einer bestehenden Verbindung vollzieht. Ich war davon ausgegangen, dass Ascii oder Baudot zu Beginn einmal ausgehandelt werden und dan bestehen bleiben. WinTlx und die Dienste, die auf der WinTlx-Implementierung basieren, wären damit aktuell überfordert.

Wobei ich mir im Moment gar nicht sicher bin, welche dieser Dienste überhaupt Ascii unterstützen bzw. damit getestet wurden. Zum Zeitpunkt der Implementierung bin ich davon ausgegangen, dass alle Clients (also Anrufer) Baudot-Texting unterstützen.
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: Diskussionen und Fragen zum i-Telex-Binärprotokoll

#3

Beitrag: # 17777Beitrag FredSonnenrein »

detlef hat geschrieben: Mo 20. Apr 2020, 13:11 Zu dem Thema "automatischer Wechsel von Ascii nach Baudot-Texting" möchte ich noch anmerken, dass es mich auch gewundert hat, dass i-Telex unter bestimmten Umständen den fliegenden Wechsel von Ascii nach Baudot bei einer bestehenden Verbindung vollzieht. Ich war davon ausgegangen, dass Ascii oder Baudot zu Beginn einmal ausgehandelt werden und dan bestehen bleiben. WinTlx und die Dienste, die auf der WinTlx-Implementierung basieren, wären damit aktuell überfordert.
DIese Thema wurde bereits viel diskutiert.
Ich werde diese Möglichkeit als "not recommended" darstellen, also "nicht garantiert". Für das i-Telex war es einfacher zu implementieren, allerdings hat das auch schon zu Schwierigkeiten geführt. Das i-Telex wird es weiter selbst erlauben, aber nicht "aktiv" benutzen.
detlef hat geschrieben: Mo 20. Apr 2020, 13:11 Wobei ich mir im Moment gar nicht sicher bin, welche dieser Dienste überhaupt Ascii unterstützen bzw. damit getestet wurden. Zum Zeitpunkt der Implementierung bin ich davon ausgegangen, dass alle Clients (also Anrufer) Baudot-Texting unterstützen.
Nur Klaus' einfacher Adapter ist m.W. der einzige "echte" Client, der KEIN Binärmodus kann, außerdem ist der Wetterdienst von Frank pur Ascii.
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: Diskussionen und Fragen zum i-Telex-Binärprotokoll

#4

Beitrag: # 22740Beitrag Fernschreiber »

Ich habe heute mal wieder ein Deja-vu gehabt. Die Telegraphenstelle Paderborn ist von mir aus nicht erreichbar, gleichwohl kann Reinhold mir problemlos Telexe schicken. Wir haben es zunächst auf die erhöhte Last der letzten Tage geschoben. Als es heute wieder nicht ging und Reinhold mir schrieb das seine Telegraphenstelle an einem Pi-Telex hängt, welches auf ein Update wartet, habe ich eine Ahnung gehabt. Der Trace hat dann letzte Gewissheit gebracht. Da er mich anschreiben kann, ist diese Richtung OK. Das ich nicht durchkomme, liegt mal wieder am
Communication-Protokoll. Anscheinend gibt es richtungsabhängige unterschledliche Versionen. Ich sende wie vorgeschrieben ein Versionspaket mit der Version 1. Wird dies nicht bestätigt, bleibe ich in dem Layer hängen, bekomme noch Zeit/Datum zugestellt und löse dann aus. Scheint halt keine i-telex Gegenstelle zu sein. Dieses Thema hatte ich schon mit Detlef und Fred hier diskutiert. Ich möchte den/ die Programmierer des pi-telex bzw. alle die sich diesen Schuh anziehen wollen daher bitten, diesen Faden:
https://telexforum.de/viewtopic.php?p=17767#p17767
komplett durchzulesen. Man gelangt dann wieder dank Fred, der diese Ecke extra eingerichtet hat, an diesen Punkt hier. Ich will mich auch nicht wiederholen, der " Faden" sagt eigentlich alles. Lasst uns alle an einem Strang ziehen und das Protokoll so wie gedacht handhaben, dann wissen ältere und auch zukünftige Eigenentwickler woran sie sind. Es ist ausserdem immer wieder unnötiger Aufwand, Traces zu machen und auszuwerten.
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

BjoernS
Rank 3
Rank 3
Beiträge: 199
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Diskussionen und Fragen zum i-Telex-Binärprotokoll

#5

Beitrag: # 22778Beitrag BjoernS »

Hallo Willi,

nur eine kurze Anmerkung von mir, da ich bei Reinholds piTelex nicht primär involviert bin. Ich vermute stark, dass er eine recht alte Version hat, älter als die, die wir (du/ich) bei unseren Versuchen benutzt haben. Mit der aktuellen sollte das Problem nicht mehr auftreten (Reinhold/Jochen: Meldet euch bitte bei Problemen! :)).

(Im Übrigen, wen es interessiert, als Anmerkung zum verlinkten Diskussionsfaden: Als ich die Versionslogik von piTelex an Freds Spezifikation angepasst habe, bin ich darauf gestoßen, dass eine wörtlich exakte Implementierung zu einer Endlosschleife führt, denn jene sagt sinngemäß: "Wenn eine Station ein Versionspaket mit einer unterstützten Versionsnummer empfängt, sollte sie eines mit der gleichen Nummer senden." Wenn das beide Seiten tun, sind sie gelinde gesagt länger beschäftigt ...

Die Altversion von piTelex hat -- als Anrufer -- bei Empfang eines Version-Paketes als Antwort immer ein solches gesendet, was mit einem gleich handelnden Angerufenen zur Endlosschleife führte. Das Ganze ist auf piTelex-Seite jetzt "intellenter" gelöst, siehe hier. Als Anrufer sendet piTelex immer ein initiales Versionspaket, als Angerufener wird keines gesendet. Bei Empfang eines Versionspaketes passiert immer das gleiche, es wird die empfangene Version gespeichert und mit der eigenen verglichen. Bei Unterschieden wird eine Neuaushandlung gemäß Spezifikation versucht; ist diese erfolgreich werden keine Versionspakete mehr versendet, besteht ansonsten das Gegenüber auf der unterschiedlichen Version, wird ein Reject verschickt und die Verbindung ausgelöst.)

Grüße


Björn
844767 twtr d

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

Re: Diskussionen und Fragen zum i-Telex-Binärprotokoll

#6

Beitrag: # 22782Beitrag Fernschreiber »

Hallo Björn,
Da wären wir wieder bei der Lesart des Dokuments. Ich habe damals auch mit Frad diskutiert wie er sich das genau gedacht hat. Die Aushandlung geht immer vom Anrufer aus. Er sendet das erste Versionspaket. Auf dieses muß der "Angerufene" reagieren. Entweder ist die Antwort gleich der vorgeschlegenen oder kleiner. Dann muß der "Anrufer" reagieren. Sendet Dieser die neue Version zurück, passt alles und Ende. Wenn nicht geht's in die nächste Runde. Spätestens bei "1" ist Schluss. Wichtig ist, das bei Einem die gesendete Version mit der empfangenen Version passt, dann gibt es keine Endlosschleife (siehe Antwort unten). Im schlimmsten Fall eine Abweisung oder Ende.
Hier meine damalige Frage an Fred (2016):
Wird der Abschluß der Aushandlung nochmals von der Gegenseite bestätigt?
Wenn eine Verbindung bei Gleichstand (V1>V1)aufgebaut wird, bekomme ich nach Sendung des Paketes
sofort die Antwort mit der gleichen Version zurück. Damit kann die Aushandlung als beendet
angesehen werden.
Schicke ich ein Paket mit der Version >1 (z.B.3) ,kommt lediglich ein Paket mit Version 1 zurück,
das war's. Auch wenn ich das bestätige, kommt nichts versionsabhängiges mehr. Nach dem ersten
Baudotzeichen kommt dann Datum/Uhrzeit usw.
Nach dem Protokollpapier scheint es mir aber, das noch ein Antwortpaket zurückkommen sollte, oder
heißt "kein Paket" demnach akzeptiert? Dann bräuchte ich es bei gleicher Version auch nicht.
Vielleicht übersehe ich hier etwas, bitte kläre mich da mal auf , ich will nur sichergehen das in
meiner Software der richtige Endpunkt der Aushandlung benutzt wird.
Die Antwort:
Eine Protokollversion gilt dann als vereinbart, wenn eine Seite die gleiche Versionsnummer sendet wie vorher die Gegenseite. Egal wer angefangen hatte.

Wenn ich also eine Station anrufe, sollte auf meinen Versionsvorschlag auf jeden Fall eine Antwort kommen, ob es passt oder nicht.
So hat sich Fred auch im Thread geäussert.
Bleibt also spannend.
Gruß
Willi
Folgende Benutzer bedankten sich beim Autor Fernschreiber für den Beitrag:
BjoernS
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

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

Re: Diskussionen und Fragen zum i-Telex-Binärprotokoll

#7

Beitrag: # 22784Beitrag FredSonnenrein »

Hallo zusammen
Fernschreiber hat geschrieben: Di 29. Dez 2020, 23:10 Hallo Björn,
Da wären wir wieder bei der Lesart des Dokuments. Ich habe damals auch mit Frad diskutiert wie er sich das genau gedacht hat. Die Aushandlung geht immer vom Anrufer aus. Er sendet das erste Versionspaket. Auf dieses muß der "Angerufene" reagieren. Entweder ist die Antwort gleich der vorgeschlegenen oder kleiner. Dann muß der "Anrufer" reagieren. Sendet Dieser die neue Version zurück, passt alles und Ende. Wenn nicht geht's in die nächste Runde. Spätestens bei "1" ist Schluss. Wichtig ist, das bei Einem die gesendete Version mit der empfangenen Version passt, dann gibt es keine Endlosschleife (siehe Antwort unten). Im schlimmsten Fall eine Abweisung oder Ende.
Genau so ist es gedacht. Ich habe die Spezifikation gerade mal aktualisiert...
Fernschreiber hat geschrieben: Di 29. Dez 2020, 23:10 Hier meine damalige Frage an Fred (2016):
Wird der Abschluß der Aushandlung nochmals von der Gegenseite bestätigt?
Wenn eine Verbindung bei Gleichstand (V1>V1)aufgebaut wird, bekomme ich nach Sendung des Paketes
sofort die Antwort mit der gleichen Version zurück. Damit kann die Aushandlung als beendet
angesehen werden.
Schicke ich ein Paket mit der Version >1 (z.B.3) ,kommt lediglich ein Paket mit Version 1 zurück,
das war's. Auch wenn ich das bestätige, kommt nichts versionsabhängiges mehr. Nach dem ersten
Baudotzeichen kommt dann Datum/Uhrzeit usw.
Nach dem Protokollpapier scheint es mir aber, das noch ein Antwortpaket zurückkommen sollte, oder
heißt "kein Paket" demnach akzeptiert? Dann bräuchte ich es bei gleicher Version auch nicht.
Vielleicht übersehe ich hier etwas, bitte kläre mich da mal auf , ich will nur sichergehen das in
meiner Software der richtige Endpunkt der Aushandlung benutzt wird.
Die Antwort:
Eine Protokollversion gilt dann als vereinbart, wenn eine Seite die gleiche Versionsnummer sendet wie vorher die Gegenseite. Egal wer angefangen hatte.

Wenn ich also eine Station anrufe, sollte auf meinen Versionsvorschlag auf jeden Fall eine Antwort kommen, ob es passt oder nicht.
So hat sich Fred auch im Thread geäussert.
Auch alles richtig.

Wenn wir aber schon beim Diskutieren sind:
@Willi: Sehe ich es richtig, dass deine Implementierung keine ACK-Pakete sendet?

Viele Grüße,

Fred
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag (Insgesamt 2):
BjoernSFernschreiber
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: Diskussionen und Fragen zum i-Telex-Binärprotokoll

#8

Beitrag: # 22790Beitrag Fernschreiber »

Hallo Fred, Björn und alle anderen,

habe gerade in den Code geschaut. Ich sende ein Ack-Paket (6) zurück sobald ein einzelnes Baudotzeichen an den externen UART übergeben wurde (etwas übertrieben vielleicht, ermöglicht aber eine sehr feine Flußsteuerung zusammen mit den Servern). Nach dem alten Protokoll von 2016 benutze ich Acks (damals nichtmal mandatory) aber nicht als Heartbeat, war ebenfalls noch kein Thema. So kann es sein das bei keinem Baudotaustausch kein Ack auftaucht. Sollte das zwischenzeitlich ein Problem geworden sein, können die HB problemlos durch Ack ersetzt werden, deren Inhalt dann aber längere Zeit gleich bleiben würde. Das habe ich aber nirgends als zwingend gelesen. Gleichzeitig habe ich in der aktuellen Fassung gelesen, das die angerufene Seite nach starten des FS ein Ack verschicken soll, auch wenn der Anrufer nichts gesendet hat. Das gab es in den älteren Versionen auch nicht, wie auch mit einem nicht zwingend notwendigen Paket. Mein Sytem ist Stand 2016/2017. Warum also ein Ack senden dessen eigentlicher Sinn entfällt. Sollte es allerdings auch als Startzeichen für die Gegenseite benutzt werden (wie letztlich die ersten Baudotzeichen) ist das etwas anderes, finde ich aber nirgens unter Beschreibung des Ack. Da in der Regel vom angerufenen das Datum ausgesendet wird, dürfte dieser Effekt auch meist verdeckt werden. Trotzdem wären klärende Worte bzg. Abwärtskompatibilität angebracht, falls Diese irgendwann nicht mehr besteht.
Welches Protokoll ist eigentlich verbindlich? Die Sourcen die Fred eingangs (in diesem Thread) angeführt hat(Doc/PDF) sind mir wesentlich genehmer wie die Version im wiki (stehe ich sehr reserviert gegenüber), in der die Kommentare (wer kann da eigentlich drin rumschreiben?) deutlich zunehmen.
Sollten weiterhin tatsächlich keine Acks von mir kommen, bitte melden unter welchen Bedingungen, dann muss ich mal debuggen /tracen.
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

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

Re: Diskussionen und Fragen zum i-Telex-Binärprotokoll

#9

Beitrag: # 22797Beitrag Fernschreiber »

Hallo nochmal,
also wer mich antelext, bekommt nach Versendung von Telegrammen des Typs 2 und deren Weiterleitung sofort ein Ack mit einem Wert +1 zum Vorherigen, siehe Debugtrace. Sollte mich wundern wenn die gehende Technik das pötzlich anders macht, kann ich aber erst nachher vor ort testen. Das hier ging glücklicherweise mit dem Webinterface (Browser) und RDP.Session auf dem Pi vom warmen Küchenherd aus.
Legende: >F1 (F1an) bedeutet aus der Fernebene (TCP) empfangen, F!> (F1ab) bedeutet zur Fernebene gesendet, >F2 (F2an) bedeutet vom UART empfangen, F2> (F2ab) bedeutet zum UART gesendet. Das sind Begriffe aus der Ü-Technik, wie ich sie aus der TF- und PCM-Technik gewohnt bin.
Zu erkennen ist deutlich der Ablauf:
Im Socket wird in der Funktion allrec ein Baudotpaket (Typ2, Länge 1) empfangen; dessen Binärwert wird in der nächsten Zeile dargestellt (>F1 + Wert. Dieser Wert geht sofort durch F2> zum UART. Danach wird sofort ein Ackpaket unter F1> mit den Typ 6, Länge 1 und um 1 erhöhten Nutzwert zum Vorherigen erzeugt und an die Gegenstelle versendet.

Gruß
Willi
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
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

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

Re: Diskussionen und Fragen zum i-Telex-Binärprotokoll

#10

Beitrag: # 22807Beitrag Fernschreiber »

Hallo die 2te,

habe gerade die gehende Leitung auch getraced. Alles wie im Trace vorher, habe den KG von der angerufenen Seite empfangen, die entsprechenden Ack's gehen umgehend raus. Da die eigentliche Sendefunktion für alle TCP-Pakete zuständig ist, muss es funktionieren.
Eine Kontroille auf Netzwerkebene habe ich daher nicht vollzogen, das ist immer aufwändig.
Gruß
Willi
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
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
Antworten

Zurück zu „Entwickler-Ecke“