Telexforum.de

Hallo,
ich entwickele ein eigenes "i-Telex". Damit dies mit anderen i-Telex-Geräten zusammenarbeitet, hätte ich gerne gewusst, wie beim gerufenen Fernschreiber die Zustände "besetzt" und "kein FS angeschlossen" abgefragt werden.
Kann man den Quellcode (wahrscheinlich C++?)bekommen?
Gruß
Karl

Aha, auf welcher Plattform denn?

Hier gibt's die i-Telex-Quellen:
https://sourceforge.net/p/itelex/code-0 ... ree/trunk/

Für besetzt usw. gibt's das Reject Packet.

Hast du die i-Telex-Protokoll-Beschreibung?
https://sourceforge.net/p/itelex/code-0 ... format=raw

Hallo Detlef,

herzlichen Dank für die Links!!!
Gruß
Karl

Bei Unklarheiten einfach hier nachfragen. Fred ist natürlich als Autor der Experte, aber es gibt schon einige, die sich durch die Dokumentation gearbeitet und das implementiert haben. Die können natürlich auch ganz gut nachvollziehen, welche Fehler man bei der Implementierung machen kann.

Ich hatte z.B. anfangs großzügige Sende- und Empfangspuffer vorgesehen, mit getrennten Bu/Zi-Flags für beide Richtungen. Sowas funktioniert gar nicht. Spannend wird es dann auch, wenn zwei Alternativ-Implementierungen aufeinander treffen. i-Telex ist relativ genügsam und nimmt einem Protokollfehler kaum übel. Als dann erstmals Willis i-Telex-Implementierung online war (z.B. KLKL-Liste), lief das mit WinTlx erstmal gar nicht, weil WinTlx sich an zwei Stellen nicht exakt an die Protokollbeschreibung hielt.
Deswegen möglichst nicht nur gegen i-Telex testen sondern auch frühzeitig gegen Alternativ-Software.

Du hattest die Frage noch nicht beantwortet, für welche Plattform du das i-Telex implementierst.

Hallo Detlef,

Dankeschön für‘s antworten, ich war wieder zu langsam.

Zum Thema „Gutmütigkeit“ des i-Telex:

Meine Maxime ist: bei Protokoll-Fehlern nicht die beleidigte Leberwurst sein, sondern dem Spruch „der Klügere gibt nach“. Deutlicher ausgedrückt: alles Unbekannte wird ignoriert.

Hallo Entwickler,
zu dem Thema muss ich jetzt auch mal was schreiben. Ich habe 2016/17 mit der Implementierung des damaligen Protokolls (2015/2016 bewusst nur Baudot) , vielen Tests an Olaf's Station und einiger Korrespondenz mit Fred begonnen und auch lauffähig gemacht (Python3). Zu dieser Zeit gab es kaum Mitstreiter, sodas nur i-Telex als Gegenstationen übrig blieben. Natürlich sind im Laufe der Zeit kleinere Optimierungen oder auch Korrekturen durchgeführt worden. Das Protokoll war damals wie eine "Bibel" und ich habe mich strikt daran gehalten (war das professionell so gewohnt). Auch Fred hat darauf hin einige Stellen erweitert oder korrigiert. Mit zunehmender Anzahl Programmierer steigt leider auch die Lesart eines solchen Dokuments.
Wie Detlef schon erwähnte, sind unsere Lesarten verschieden , das Protokoll etwas schwammig und Änderungen eingeflossen. Die Nutzung der Ack-Pakete auch als Heartbeat bzw. Nutzung der Zählerstände als Flusskontrolle ist einfach nicht exakt beschrieben. Das Protokoll ist eine Sache, die Implementierung eine Andere. Hier würde ich von Fred einen Anhang erwarten, der beschreibt wie es im i-Telex genau abläuft. Das Protokoll liefert z.B. nur die Basis für Flusskontrolle, welche damals als evt. zukünftig beschrieben war. So sind Detlef und ich letztendlich wieder etwas schlauer geworden.
Weiterer Punkt war zufällig Detlefs Auskunft bzw. Chat. In beiden hatte er keine Protokollverhandlung eingebaut. Damit war eine Nutzung von meiner Seite ausgeschlossen. Detlef hat dann etwas angepasst, so das es dann ging. Ein Blick in das 2015er Protokoll unter Punkt
2.2.7 Version packet
Using this packet the connected stations can handle out which version of the i-telex protocol is supported. Currently, there is only version 1 defined, but in future there may be enhanced versions. If a station receives a version packet with a version number it can handle, the station has to “answer” with a version packet including the same version number as receive.

in der aktuellen Version von 2019 steht:
2.3.7 Version packet
Using this packet, the connected stations can handle out which version of the i-telex protocol is supported. Currently, there is only version 1 defined, but in future there may be enhanced versions. If a station receives a version packet with a version number it can handle, the station should “answer” with a version packet including the same version number as receive.

Natürlich kann man hier am "Using" rumdefinieren, aber nirgendwo ,auch in allen Beispielen ist die Protokollverhandlung in Frage gestellt. Jedes i-Telex sendet ein solches Paket bei Beginn aus, wenn das kein "Using" ist.
Zwischen "has to answer" und "should answer" besteht natürlich ein himmelweiter Unterschied. Das sich ein Protokoll so ändert, ist "ungewöhnlich". Noch bizarrer ist aber der Umstand, das i-Telex Stationen ein Fehlen dieses Pakets hinnehmen und weitermachen. Das berührt nicht den Slogan " alles unbekannte wird ignoriert". Für mich ist das Fehlen des Versionspaketes ein Hinweis auf Fremdanruf eines nicht-i-telex-Systems und dann breche ich nach einigen Sek. ab, habe auch nie Probleme mit Suchautomaten gehabt.

Weder Detlef noch mir ist da ein Fehler unterlaufen, letztlich liegt der Ball bei Fred, mal die Implementierung (auch historisch/Versionstypisch) offenzulegen.
Es gibt noch mehrere kleine Beispiele (z.B. Reaktionszeiten beim Interworking .......), die man dann bei Fred erfragen muss.
Also Entwickler, nur das Protokoll alleine bringt den grundlegenden Durchblick, aber keinen garantierten Erfolg.
Es wäre in diesem Zusammenhang doch mal interessant, wenn sich Entwickler mit eigenen i-telex-Lösungen hier mal melden würden um ein Crosscheck zu machen. Vielleicht tauchen da auch noch zu lösende Probleme auf, von denen wir untereinander nichts wissen.

Das Protokoll ist ja nur auf der Übertragungsebene nutzbar, woher die Events kommen und wie kommenden Informationen in der Hardware umgesetzt
werden, ist ja so individuell wie jede Realisierung. Auch das wäre mal interessant zu erfahren.

Ich möchte aber darauf hinweisen, das bisher immer ein guter und hilfsbereiter Umgang untereinander stattfand und keine "beleidigte Leberwurst" entstanden ist. Schliesslich ist das Lösen von Schwierigkeiten auch intensive Kommunikation (via Telex) und hilft das System zu verstehen und sinnvoll zu erweitern. Lernen kann man dabei auch noch.

Machen wir weiter so.
Grüsse aus der mechanischen Telex Vst (TW39-HDW, seit kurzem auch TWM-EMD) Münster
Willi

Hallo Willi,
Danke für deinen Konstruktiven Beitrag.

Diesen habe ich als Anlass für diesen neuen Faden genommen.

VIel Spaß!