Zweck des Ack-Telegramms im i-Telex-Protokoll

[FredSonnenrein]

Das i-Telex arbeitet beim Senden der "eingetippten" Daten wie folgt:
Es werden alle in der eingenen Station eingegebenen Zeichen (5-Bit-Codes) zunächst gespeichert und bei bestimmten Bedingungen dann als ein Datenblock ausgesendet.
Die Anzahl der gesendeten Zeichen wird summiert.
Ein Datenblock wird ausgesendet, wenn eine der folgenden Bedingungen erfüllt ist:
a) seit dem letzten eingegebenen Zeichen sind 0,8 Sekunden vergangen
oder b) es sind mehr als 20 Zeichen gepuffert
oder c) die Anzahl per Ack-Telegramm als "gedruckt" bestätigten Zeichen ist gleich der Summe der gesendeten Zeichen.

Somit sind Ack-Telegramme tatsächlich optional und dienen nicht der Verhinderung des Überlaufens des Puffers beim Empfänger, sondern dem optimierten Senden der 5-Bit-Daten durch den Sender.

Der Empfänger sendet die Ack-Telegramme mindestens alle 1,5 sekunden, jedoch auch sofort wenn der Empfangspuffer leer ist.

Ich wollte insgesamt vermeiden, dass sinnlos Übertragungs-Overhead verursacht wird (und der TCP-Stack des lahmen Atmel überläuft), wenn jeder 5-Bit-Code mit einem TCP-Paket übertragen wird.

Bei "kurzen" Übertragungen ist es aber tatsächlich doch so, dass jedes eingetippte Zeichen sofort gesendet wird (weil das letzte Ack-Telegramm bestätigte, dass der Empfänger "arbeitslos" ist) und das empfangene Zeichen auch sofort durch den Empfänger per Ack-Telegramm als "gedruckt" bestätigt wird uns somit der Sender wieder das nächste Zeichen sofort sendet (weil Bedingung c) erfüllt ist).

Nachtrag: Das Verfahren gilt spiegelbildlich für beide Übertragungsrichtungen, Sender und Empänger meint also nicht Anrufer und Angerufener sondern stets beide.

[detlef]

Ein Datenblock wird ausgesendet, wenn eine der folgenden Bedingungen erfüllt ist:
a) seit dem letzten eingegebenen Zeichen sind 0,8 Sekunden vergangen
oder b) es sind mehr als 20 Zeichen gepuffert
oder c) die Anzahl per Ack-Telegramm als "gedruckt" bestätigten Zeichen ist gleich der Summe der gesendeten Zeichen.

Das entpricht im Prinzip etwa dem, wie ich das in WinTlx implementiert habe. Nur hatte ich da an einer Stelle ein Und-Bedingung drin, statt Oder.
Deswegen war die Rückmmeldung per Ack-Telegramm obligatorisch. Mein interner Sendepuffer ist 16 Zeichen. Das heisst, nach dem Senden des KG war Schluss mit Senden, wenn keine Acks kommen.

Ich prüfe nochmal, ob ich die WinTlx-Logik nach den obigen i-Telex-Regeln noch etwas vereinfachen kann. Das kommt dann ja auch dem Konferenzdienst zugute.

Vielleicht wäre es gut, deine Beschreibung als als Beispiel in die Protokollbeschreibung aufzunehmen. Für die Implementierung ist das sehr hilfreich.

EDIT: Ich habe gerade nochmal überlegt und ich denke, das von dir beschriebene Vorgehen lässt sich nicht 1:1 auf einen automatischen Sender übertragen, wo die Daten mit mehr als 50 Baud anfallen können. Theoretisch könnte ich dann ja alle 0,8 Sekunden ein 20 Byte Paket schicken. Das würde den Empfänger überrennen. Es seit denn, man sorgt dafür, dass die Zeichen wirklich nur mit 50 Baud in den Ausgangpuffer geschrieben werden. Ich werde da nochmal drüber prüten.

Fred könntest du vielleicht die letzten beiden Beiträge hier abtrennen und als neuen Thread in die Entwicklerecke schieben? Mit dem KLKL-Server hat das ja nichts mehr zu tun.

[FredSonnenrein]

Vielleicht wäre es gut, deine Beschreibung als als Beispiel in die Protokollbeschreibung aufzunehmen. Für die Implementierung ist das sehr hilfreich.

Ist es doch schon, siehe Seite 9 oben.

EDIT: Ich habe gerade nochmal überlegt und ich denke, das von dir beschriebene Vorgehen lässt sich nicht 1:1 auf einen automatischen Sender übertragen, wo die Daten mit mehr als 50 Baud anfallen können. Theoretisch könnte ich dann ja alle 0,8 Sekunden ein 20 Byte Paket schicken. Das würde den Empfänger überrennen. Es seit denn, man sorgt dafür, dass die Zeichen wirklich nur mit 50 Baud in den Ausgangpuffer geschrieben werden. Ich werde da nochmal drüber prüten.

Automatische Sender und Stationen, die NICHT das Ack-Telegramm verwenden, passen halt nicht zusammen. Falls keine Ack-Telegramme vom automatischen Sender empfangen werden, kann dieser nur "raten" wie schnell der Empfänger ist.
Im zweifelsfall läuft DESSEN Empfangspuffer über. "Selbst schuld".
Mit dem Ack-Packet besteht ja sogar die Möglichkeit, dass schnellere Geräte auch die Daten schneller zugeführt bekommen.

Fred könntest du vielleicht die letzten beiden Beiträge hier abtrennen und als neuen Thread in die Entwicklerecke schieben? Mit dem KLKL-Server hat das ja nichts mehr zu tun.

Erledigt.

[detlef]

Mit dem Ack-Packet besteht ja sogar die Möglichkeit, dass schnellere Geräte auch die Daten schneller zugeführt bekommen.

Ja, den Effekt hatten wir schon, als Franz, Reinhard und ich im Konferenzdienst waren. Die Kommunikation zwischen Konferenzdienst, WinTlx und der ESP-Lösung von Reinhard war so schnell, dass Franz mit seinem i-Telex nicht dazwischen kam.

Automatische Sender und Stationen, die NICHT das Ack-Telegramm verwenden, passen halt nicht zusammen. Falls keine Ack-Telegramme vom automatischen Sender empfangen werden, kann dieser nur "raten" wie schnell der Empfänger ist.
Im zweifelsfall läuft DESSEN Empfangspuffer über. "Selbst schuld".

Aber wenn mich so ein automatischer Sender mit einem 20 Byte-Paket spätestens alle 0,8 Sekunden zuballert, dann kann ich Acks schicke wie ich will. Er wird den Empfänger überrennen, wenn dieser die Daten intern nur mit 50 Baud verarbeiten kann.

[FredSonnenrein]

Aber wenn mich so ein automatischer Sender mit einem 20 Byte-Paket spätestens alle 0,8 Sekunden zuballert, dann kann ich Acks schicke wie ich will. Er wird den Empfänger überrennen, wenn dieser die Daten intern nur mit 50 Baud verarbeiten kann.

Da hast du nochmal was falsch verstanden:
Die 0,8 Sekunden beziehen sich auf Schreibpausen. D.h. wenn weniger als 20 Zeichen im Puffer, noch nicht alle gesendeten Zeichen per Ack bestätigt sind, dann wird trotzdem ein Baudot-Data-Paket gesendet, wenn 0,8 Sekunden lang keine zusätzlichen Zeichen in den Puffer gekommen sind.
Der Algorithmus entsprechend Eingangsbeitrag würde die 20 Zeichen Pakete ohne Verzögerung senden, falls sehr viele Daten im Puffer sind.
Somit sollte ein automatischer Sender eher auf die Ack-Pakete "achten" und wenn keine solche kommen dann mit einer Geschwindigkeit die Baudot-Pakete senden, die dieser für richtig hält...

[Fernschreiber]

Die Flusskontrolle im klkl-Server basiert auf den Ack's des i-Telex. Nur mit Zeiten braucht man da nicht kommen. Es wird eine mittlere Geschwindigkeit von 50 Baud (6.6 Zeichen/s) angestrebt. Damit im Puffer der Gegenstelle etwas aufgestaut wird ( zur Überbrückung kurzer Verzögerungen) ist die Geschwindigkeit anfangs leicht höher. Ab einem Schwellwert (derzeit 10 Pakete) wird pro Zeichen >10 wieder gebremst (4ms/Paket). Dadurch pendelt sich eine mittlere Geschwindigkeit ein, die die gewünschte Pufferbelegung hält. Das funktioniert selbst bis zum Ende des Dauerfeuers einer klkl-Liste mit ca. 12000 Zeichen über etwa 30 Minuten (6,6/s). Das funktioniert mit einer statischen Sendeschleife über diesen Zeitraum nicht, entweder es treten Unterbrechungen auf (<50 Baud) oder der RX-Puffer läuft über (>50 Baud). Die TCP-Strecke ist kein zeitkonstantes Medium, daher dieser Aufwand. Eine genaue Beschreibung gibt es wenn alles stabil ist und Thomas etwas Luft dafür hat.
Gruss
Willi

[detlef]

Hallo Willi,

das Problem ist die Gegenrichtung. Der klkl-Server sendet derzeit keine Ack-Telegramme. Das sendende System bekommt daher keinen Handshake.
Das i-Telex-System sendet Acks in beide Richtungen und daran hatte ich mich orientiert.

Ich habe das jetzt in WinTlx angepasst. Aber so ganz optimal finde ich das nicht.

Gruß, Detlef

[Fernschreiber]

Hallo Detlef,
ich glaube wir reden hier leicht aneinander vorbei. Das Problem ist die Richtung Server zum Client, egal welcher. Da ist die Datenmenge ungleich grösser wie die paar Eingaben zur Menüauswahl. Der Server ist auf die Ack's vom Client angewiesen. Der Client brauch in diesem Fall keine zum reagieren. Da die Software aber aus meiner i-Telex-Technik stammt, sendet sie sehrwohl Ack's zum Client, sogar für jedes Baudotzeichen einzeln. Das heisst bei Eingabe einer Auswahl sofort ein Ack für jedes Zeichen. Habe die Ausgabe aber während der Entwicklung deaktiviert , da es wohl nicht mehr als 25 Ack's inkl. KG werden dürften im Gegensatz zu den tausenden in der Gegenrichtung. Was verstehst du unter Handshake, die Heartbeats werden aber doch alle 4sek gesendet, sie sind doch der Urgedanke. Im Protokoll von 2015 (mit dem ich entwickelt habe) steht nur, das auch Ack's "useful" wären aber nichtmal "mandatory" sind. Ich sende mit dem Heartbeat-Timer in der Regel Heartbeats, nur wenn sich die Zeichendifferenz geändert hat, kommt vom Timer ein Ack. Ich gebe die Ack's aber wieder frei damit das korrekter abläuft. Würde mich aber interessieren, was Du mit den paar Zeichen in diesem Fall machst?. Bei symmetrischer Anwendung sind sie durchaus sinnvoll wenn die User schreiben wie die Teufel oder Lochstreifen laufen.
Gruß, Willi

[detlef]

Hallo Willi,

ich hatte die Ack's nach der Protokollbeschreibung vom April 2019 als mandatory interpretiert, aber so ganz eindeutig ist das nicht formuliert. Und Fred hat ja bereits bestätigt, dass die i-Telex-Firmware Ack's nicht zwingend benötigt. Deswegen habe ich die WinTlx-Software jetzt so angepasst, dass sie auch ohne Ack's funktioniert. Das war also kein Fehler des klkl-Servers, wie ich zunächst dachte.
Trotzdem halte ich das Senden von Ack's für sinnvoll.
Mit Handshake meinte ich die Ack's. Das ist ja eine Art Flusssteuerung. Ich habe mich daran orientiert, was die i-Telex-Firmware tut. Die sendet gar keine Heartbeats sondern stattdessen nur Ack's, so dass der Sender immer über den Pufferstand der Empfängers informiert ist.
Du hast natürlich Recht, dass das Senden von Ack's bei Anwendungen wie dem klkl-Server nicht unbedingt notwendig ist. Bei WinTlx ist das anders, damit können ja größere Datenmengen in beide Richtungen geschickt werden.

Ich finde es aber toll, dass klkl-Server und WinTlx trotz der Unterschiede bei der der Implementierung inzwischen eigentlich ganz gut zusammenarbeit.

Gruß, Detlef

[Fernschreiber]

Hallo Detlef,
da denken wir ja doch ziemlich gleich in unserem Bestreben. Aber so ist das mit Spezifikationen. Lassen sie auch nur einen Millimeter Spielraum, wird Dieser unbewusst je nach lesart interpretiert. Dazu kommt noch die Historie. Wenn Du die 2015'er Version kennst(?), damit der ist kein lauffähiges System zu programmieren, ohne Gegenstelle und Fred's Infos nebenbei ging damals nichts. Mittlerweile ist die Doku wesentlich erweitert und hilft ganz gut. Leider sind wir als ThirdParty-Produkt permanent darauf angewiesen, diese Dinger zu lesen um aktuell zu bleiben z.B. Ascii.Abfrage des Tln.Servers oder Nutzung einstelliger Durchwahlen. Zweites musste ich nachbauen, da es mittlerweile Nutzter mit diesen Nummern gibt. Es wird definitiv viele i-Telexstationen geben, die nie upgedatet werden, läuft ja oder hat keine Ethernetkarte (vielleicht Telexphone). Und wer nicht im Forum mal rumschaut, kriegt garnichts mit. Ich habe in meinem i-Telex Py Derivat auch keine Flusssteuerung drin, ist selbst bei Lochstreifen nicht nötig. Durch die Server-Applikation habe ich damit gerechnet, aber die Implementierung und Justierung der Parameter ist dann doch Umfangreicher wie gedacht und abhängig von der Gegenstelle. Da kann auch mal eine ohne Ack's antelexen, da muss halt ein statischer Wert herhalten. Ich bin aber durchaus positiv angetan, wenn jemand wie Du mal etwas extremer testet und tiefer reinschaut. Es ist erstmal überraschend (evt. lästig), zwingt aber zum (Um/Über)denken und damit zum Verbessern der Lösung.
Gruß
Willi