Zähler im Acknowledge-Paket

Fachforen für Entwickler und Bastler
Antworten
Benutzeravatar

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

Zähler im Acknowledge-Paket

#1

Beitrag: # 19663Beitrag BjoernS »

Hallo zusammen,

habe gerade softwaremäßig ein kleines Problemchen, das möglicherweise aus einem Missverständnis meinerseits der i-Telex-Spezifikation resultiert. Dort steht zum Acknowledge-Paket ja, dass damit grundsätzlich die Zahl der empfangenen Zeichen dem Anderen mitgeteilt werden soll, damit dieser einschätzen kann, wie viel noch auszudrucken ist.

Das interpretiere ich erstmal so, dass ich meine aktuelle Druck-Pufferlänge übermittle. Wenn sich also jemand zu mir verbindet und das erste Baudot Data oder Direct Dial sendet, drucke ich Datum/Uhrzeit und sende das erste Acknowledge-Paket mit einem Wert von 24, da Datum/Uhrzeit ja noch zu drucken sind.

Jetzt steht in der Spezifikation bei Acknowledge ganz unten noch folgendes (frei übersetzt):
Anmerkung: Normalerweise druckt die gerufene i-Telex-Station nach dem Einschalten des Fernschreibers das aktuelle Datum und die aktuelle Uhrzeit. Um anzuzeigen, dass es Daten zum Ausdrucken gibt, beginnt das erste Acknowledge-Paket nicht mit einem Datenbyte von 0. Aber sobald der lokal erzeugte Text komplett gedruckt wurde, sendet die gerufene Station ein Acknowledge-Paket mit dem Wert 0.
Das muss ja heißen, dass ich mit einem Wert von (0-24) & 0xff beginne, oder 232. Das beobachte ich bei i-Telex-Gegenstellen auch regelmäßig.

Hat dieser Beginn "unter Null" noch einen anderen Hintergrund? Oder ist das nur dafür da, dass eine "&0xff"-Abkürzung ohne Probleme funktioniert?

(Denn wenn ich tatsächlich mit 24 beginne, verschluckt sich eine piTelex-Gegenstelle aktuell daran, der Zähler läuft über und es kommen 232 noch zu druckende Zeichen raus. Was zu einer dauerhaften Sendepause führt.)

Danke und Grüße


Björn
844767 twtr d
Benutzeravatar

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

Re: Zähler im Acknowledge-Paket

#2

Beitrag: # 19664Beitrag FredSonnenrein »

Hallo Björn
BjoernS hat geschrieben: Di 21. Jul 2020, 10:33 habe gerade softwaremäßig ein kleines Problemchen, das möglicherweise aus einem Missverständnis meinerseits der i-Telex-Spezifikation resultiert. Dort steht zum Acknowledge-Paket ja, dass damit grundsätzlich die Zahl der empfangenen Zeichen dem Anderen mitgeteilt werden soll, damit dieser einschätzen kann, wie viel noch auszudrucken ist.
Wichtig ist, dass die gesamte Anzahl in dieser Verbindung jemals gedruckten Zeichen übermittelt wird.
Zeichen, die noch im Empfangspuffer sind, sollen nicht mitgezählt werden.
Denn würde nur "Pufferstand = x" übermittelt werden, dann würde nicht erkannt werden, dass noch y Zeichen irgendwo auf der Internet-Verbindung zwischen A und B unterwegs sind.
BjoernS hat geschrieben: Di 21. Jul 2020, 10:33 Das interpretiere ich erstmal so, dass ich meine aktuelle Druck-Pufferlänge übermittle. Wenn sich also jemand zu mir verbindet und das erste Baudot Data oder Direct Dial sendet, drucke ich Datum/Uhrzeit und sende das erste Acknowledge-Paket mit einem Wert von 24, da Datum/Uhrzeit ja noch zu drucken sind.
Siehe oben, die 24 ist falsch, da die Zeichen die du lokal druckst, gar nicht übertragen worden sind.
BjoernS hat geschrieben: Di 21. Jul 2020, 10:33 Jetzt steht in der Spezifikation bei Acknowledge ganz unten noch folgendes (frei übersetzt):
Anmerkung: Normalerweise druckt die gerufene i-Telex-Station nach dem Einschalten des Fernschreibers das aktuelle Datum und die aktuelle Uhrzeit. Um anzuzeigen, dass es Daten zum Ausdrucken gibt, beginnt das erste Acknowledge-Paket nicht mit einem Datenbyte von 0. Aber sobald der lokal erzeugte Text komplett gedruckt wurde, sendet die gerufene Station ein Acknowledge-Paket mit dem Wert 0.
Das muss ja heißen, dass ich mit einem Wert von (0-24) & 0xff beginne, oder 232. Das beobachte ich bei i-Telex-Gegenstellen auch regelmäßig.
Hat dieser Beginn "unter Null" noch einen anderen Hintergrund? Oder ist das nur dafür da, dass eine "&0xff"-Abkürzung ohne Probleme funktioniert?
Das war die einfachste Implementierung für mich. Natürlich wäre es genauso möglich, dass du solange Datum und Uhrzeit gedruckt wird, den Zählerstand 0 sendest. Und erst nach dem ersten tatsächlich empfangenen Zeichen dann 1, 2, 3 usw.
BjoernS hat geschrieben: Di 21. Jul 2020, 10:33 (Denn wenn ich tatsächlich mit 24 beginne, verschluckt sich eine piTelex-Gegenstelle aktuell daran, der Zähler läuft über und es kommen 232 noch zu druckende Zeichen raus. Was zu einer dauerhaften Sendepause führt.)
Das i-Telex ist da genügsamer... Das vergleicht einfach den eigenen Zählerstand der gesendeten Zeichen mit dem per ACK-Telegramm bestätigten Wert, wenn beide gleich sind, dann werden sofort ggf. gepufferte Sendedaten abgeschickt.
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: Zähler im Acknowledge-Paket

#3

Beitrag: # 19665Beitrag Fernschreiber »

Hallo Björn,
erstaunlich zu sehen wie jeder "Eigenbrötler" über die selben Punkte des Protokolls stutzt. Das ist noch nicht das Ende. Ich habe mich damals (2016) auch gewundert über die hohen Anfangswerte. Fred bestätigte mir das er das Datum tatsächlich zurückrechnet um dann mit 0 zu starten. Ich ignoriere das am Anfang und sende mein erstes Ack als angerufener wenn Daten eingelaufen und "verarbeitet" sind. Das Datum ist ja eine lokale Angelegenheit und hat mit Flusskontrolle nicht viel zu tun. Mein Ack wäre sowieso -26, da meine Uhrzeit inkl. der Sek ist. Als Anrufer bekomme ich das Datum allerdings von der Gegenstelle und schicke dann das Ack mit der entsprechenden Zahl nach Druck zurück. Mach es nicht zu pedantisch, auf ein paar Zeichen kommt es nicht an, es soll halt nur ein Hilfsmittel sein um überhaupt die Möglichkeit zur Flusskontrolle zu haben. Im Pi hast Du noch den Vorteil gegenüber dem AT-Maga, das da RX Systempuffer ohne Ende bereitstehen. Ob man das Ack nur sendet wenn sich was ändert oder als Heartbeat (dann u.U. mit jeweils dem gleichen Wert) ist ja auch noch eine Option. Das Protokoll lässt Raum für Implementierungen seiner selbst. Du musst auch damit rechnen, das Du keine Acks bekommst. Zwischen normalen Stationen mit 50 Baud-Maschinen ist das in der Regel überflüssig, es sei denn die TCP-Verbindung ist extrem schlecht. Aber Software-Endstellen wie Server brauchen das zwingend, da kein natürlicher Sendetakt bereitsteht. Da der Zähler nur bis 255 zählt, musst Du die Überläufe auch sauber berücksichtigen. Für manuelle oder kleinvolumige Verbindungen ist das alles nicht nötig, aber bei dem Extrem Baudot-Arts über Dauerfeuer während 45 Minuten ist der Server auf eine Rückmeldung zwingend angewiesen, ausser man sendet stumpf mit nur 4-5 Zeichen/s. Im KLKL-Server ist die Flußsteuerung bis ins Extrem getrieben, hat sich aber gelohnt. Hierzu ein Blick in https://telexforum.de/viewtopic.php?f=29&t=2245, da haben wir das lang und breit diskutiert.
Würde mich mal interessieren wie sich unsere beiden Systeme vertragen, "Schreib mal an" und bringe meine HDW/EMD in Bewegung.
Frohes programmieren weiterhin.
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

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

Re: Zähler im Acknowledge-Paket

#4

Beitrag: # 19669Beitrag BjoernS »

Moin zusammen,

danke für die Klarstellung Fred! :) Damit kann ich schaffen.
Fernschreiber hat geschrieben: Di 21. Jul 2020, 12:05 erstaunlich zu sehen wie jeder "Eigenbrötler" über die selben Punkte des Protokolls stutzt. Das ist noch nicht das Ende. Ich habe mich damals (2016) auch gewundert über die hohen Anfangswerte. Fred bestätigte mir das er das Datum tatsächlich zurückrechnet um dann mit 0 zu starten. Ich ignoriere das am Anfang und sende mein erstes Ack als angerufener wenn Daten eingelaufen und "verarbeitet" sind. Das Datum ist ja eine lokale Angelegenheit und hat mit Flusskontrolle nicht viel zu tun. Mein Ack wäre sowieso -26, da meine Uhrzeit inkl. der Sek ist. Als Anrufer bekomme ich das Datum allerdings von der Gegenstelle und schicke dann das Ack mit der entsprechenden Zahl nach Druck zurück. Mach es nicht zu pedantisch, auf ein paar Zeichen kommt es nicht an, es soll halt nur ein Hilfsmittel sein um überhaupt die Möglichkeit zur Flusskontrolle zu haben. Im Pi hast Du noch den Vorteil gegenüber dem AT-Maga, das da RX Systempuffer ohne Ende bereitstehen. Ob man das Ack nur sendet wenn sich was ändert oder als Heartbeat (dann u.U. mit jeweils dem gleichen Wert) ist ja auch noch eine Option. Das Protokoll lässt Raum für Implementierungen seiner selbst. Du musst auch damit rechnen, das Du keine Acks bekommst. Zwischen normalen Stationen mit 50 Baud-Maschinen ist das in der Regel überflüssig, es sei denn die TCP-Verbindung ist extrem schlecht. Aber Software-Endstellen wie Server brauchen das zwingend, da kein natürlicher Sendetakt bereitsteht. Da der Zähler nur bis 255 zählt, musst Du die Überläufe auch sauber berücksichtigen. Für manuelle oder kleinvolumige Verbindungen ist das alles nicht nötig, aber bei dem Extrem Baudot-Arts über Dauerfeuer während 45 Minuten ist der Server auf eine Rückmeldung zwingend angewiesen, ausser man sendet stumpf mit nur 4-5 Zeichen/s. Im KLKL-Server ist die Flußsteuerung bis ins Extrem getrieben, hat sich aber gelohnt. Hierzu ein Blick in https://telexforum.de/viewtopic.php?f=29&t=2245, da haben wir das lang und breit diskutiert.
Würde mich mal interessieren wie sich unsere beiden Systeme vertragen, "Schreib mal an" und bringe meine HDW/EMD in Bewegung.
Frohes programmieren weiterhin.
Danke für die weiteren Tipps Willi. Habe das ACK anfangs mehr als "Druckerkontrolle" denn als "Verbindungsflusskontrolle" verstanden, aber das wird jetzt klarer. Hätte ich den anderen Thread vorher gelesen ... das ist genau die Ecke in der ich auch Probleme bekam (Deadlock). Fairerweise muss ich zugeben, dass ich an Jochens erster Implementierung herumgefummelt und diese damit verschlimmbessert habe :lol:

Und du hast (Heb-)Drehwähler bei dir im Einsatz? :o :thumbsup: Sehr cool das. Den Platz habe ich leider nicht. :)

Grüße


Björn
844767 twtr d
Antworten

Zurück zu „Entwickler-Ecke“