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

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

#11

Beitrag: # 22808Beitrag FredSonnenrein »

Hallo zusammen,
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 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).
Okay, mein "Massentext-Versendeprogamm" scheiterte dann wohl daran, dass es nach dem Durchwahl-Telegramm ein Ack oder ein Baudot-Data erwartet als Bestätigung, dass der angewählte Fernschreiber tatsächlich läuft. Ich muss aber selbst nochmal in den Trace schauen.
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 Nach dem alten Protokoll von 2016 benutze ich Acks (damals nichtmal mandatory) aber nicht als Heartbeat, war ebenfalls noch kein Thema.
Ack ist auch nicht zwingend, erleichtert halt den automatischen Sendern das Anpassen der Sendegeschwindigkeit an die Schreibgeschwindigkeit.
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 So kann es sein das bei keinem Baudotaustausch kein Ack auftaucht.
Ist okay so.
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 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.
So macht es das Original, ist aber nicht zwingend.
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 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.
Das ist eine Ergänzung (Empfehlung), weil sonst der Absender kein Zeichen bekommt, ob das Direct Dial Paket erfolgreich war oder nicht.
Heartbeat ist ja auch (theoretisch) zu verwenden, wenn der Sender bisher weder ein Direct Dial noch ein Baudot-Paket gesendet hat.
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 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.
Deshalb habe ich die Wiki-Version fortgeschrieben.
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 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.
Abwärtskompatibilität werde ich weiterhin mit overster Priorität anstreben, daher soll meinne Bibliothek auch mit Gegenstellen zusammen arbeiten, die nicht das Ack-Paket verwenden. Dann muss aber ggf. das Senden des ersten eigenen Zeichens ggf. auch Zeitgesteuert erfolgen (falls weder Ack noch das Datum vom Angerufenen empfangen wird).
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 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),
Kannst du bitte erklären, was dich genau stört? Eigentlich sollte in der Wiki-Version nichts drinstehen, was der alten Doc widerspricht, sondern nur zusätzliches.
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 in der die Kommentare (wer kann da eigentlich drin rumschreiben?)
Jeder, der ein Wiki-Account bei Alex beantragt und genehmigt bekommen hat.
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 deutlich zunehmen.
Kein schöner Zustand und soll auch behoben werden.
Ich werde natürlich alle Änderungen beobachten und ggf. zurückweisen, falls nicht zutreffend.
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 12:12 Sollten weiterhin tatsächlich keine Acks von mir kommen, bitte melden unter welchen Bedingungen, dann muss ich mal debuggen /tracen.
Offensichtlich ein Fehler auf meiner Seite. Ich prüfe es nochmal.
Fernschreiber hat geschrieben: Mi 30. Dez 2020, 21:54 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.
Danke für die Mühen, das sieht alles gut aus. Der Verbindungsaufbau ist der kritische Punkt, aber bitte mach noch keine neuen Analysen, wie gesagt vermute ich das Problem noch auf meiner Seite.
Fazit: Fühle dich bitte nicht zu irgenwelchen Änderungen genötigt, ich wollte nur verstehen, woran es hakte (zuerst).

Viele Grüße,

Fred
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag:
Fernschreiber
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

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

#12

Beitrag: # 22817Beitrag BjoernS »

Hallo zusammen,

noch eine Nebenbemerkung zum Thema Heartbeat/Acknowledge, das ist ein Bisschen ein Minenfeld:
  • Laut der Spezifikation darf Heartbeat immer gesendet werden, Acknowledge nur nach FS-Anlauf.
  • Typischerweise werden also vor dem FS-Anlauf Heartbeats gesendet, danach Acknowledges (man könnte auch dann noch gleichzeitig HB senden, das transportiert aber keine weitere Information).
  • Der Rundsendedienst 11150 hat aber scheinbar die Eigenheit, ein Heartbeat als "FS läuft" zu interpretieren. Das führt dazu, dass, wenn man von ihm angerufen wird, nach dem ersten eigenen Heartbeat direkt die WerDa-Abfrage zurückgesendet wird. Das läuft typischerweise mitten in den Datumsstempel rein und führt zu lustigen Ausdrucken.
Deshalb sendet piTelex in der aktuellen Version (seit diesem Commit) mangels einer offensichtlichen Lösung gar keine Heartbeats mehr. Mit FS-Anlauf beginnt der normale Acknowledge-Rhythmus.

Kommt gut rein, Grüße


Björn
844767 twtr d
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

#13

Beitrag: # 22818Beitrag FredSonnenrein »

Hallo Björn,
BjoernS hat geschrieben: Do 31. Dez 2020, 18:35Deshalb sendet piTelex in der aktuellen Version (seit diesem Commit) mangels einer offensichtlichen Lösung gar keine Heartbeats mehr. Mit FS-Anlauf beginnt der normale Acknowledge-Rhythmus.
Das ist aber auch nicht gut, da dann, falls die Anlaufphase eines echten Fs mal länger dauert, ein Timeout eintreten kann.
Das Verhalten des Rundsendedienstes ist da offensichtlich falsch.
Allerdings verstehe ich noch nicht, wie das Werda "zwischenfunken" kann...
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

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

#14

Beitrag: # 22824Beitrag BjoernS »

Hallo Fred,

in diesem Fehlerfall passiert folgendes: Während die Zeichen für das Banner in den Sendepuffer für den lokalen FS geschrieben werden, kommt das WerDa schon per i-Telex-Verbindung rein (noch bevor der Acknowledge-Zähler 0 wird) und wandert mitten dazwischen. Der FS bekommt jetzt nach dem WerDa direkt weitere Daten gesendet und das überlagert sich intern ... auch beim T1000 führt das zu seltsamen Ausdrucken.

Wir haben aber gerade mit Reinhold Fehlersuche an anderer Stelle betrieben* und es haben sich dabei Änderungsansätze ergeben, die auch dieses Problem nachhaltiger lösen könnten (wenn auch nur per Symptombehandlung):
  • Empfangene i-Telex-Daten so lange zurückhalten, bis das Banner ganz gedruckt ist.
  • Nachdem ein WRU gedruckt wurde, 20(+1) Zeichen lang Zwangspause für Daten von extern, damit der Kennungsgeber ungestört ablaufen kann
Das bringt schlimmstenfalls die Gegenstelle aus dem Takt, aber das ist sie sowieso bereits, wenn sie mit einem WerDa "dazwischen funkt". Wenn sich das stabil bewährt, sollte das Heartbeat auch wieder ohne Nebenwirkungen zu aktivieren sein.

Ist ein wenig schade, dass einige Dienste nicht quelloffen entwickelt werden -- das würde die Harmonisierung des "i-Telex-Ökosystems" etwas vereinfachen.

Grüße und frohes Neues :beer:


Björn

* Fernschreiber mit automatischer KG-Abfrage bei Verbindungsaufbau wie T1200SD, eingehende Anrufe mit automatischer KG-Auslösung von i-Telex bei Tastaturwahl -- letzteres war nur wegen eines lokalen Konfigurationsproblems ein Thema
Folgende Benutzer bedankten sich beim Autor BjoernS für den Beitrag (Insgesamt 2):
detlefReinholdKoch
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

#15

Beitrag: # 22826Beitrag Fernschreiber »

Hallo Björn,

der Punkt 1 in dem Commit hat sich ja von alleine erledigt, war ja nicht sehr das erhoffte Ergebnis.
Im Punkt 2 nur damit wir das gleiche Verständnis haben: Ack = 0
(meaning printer is running and all data has been printed, matching the
spec)
Diese Aussage gilt wirklich nur am Beginn einer Verbindung, jedes weitere Ack = 0 bedeutet x mal 255 +1 Zeichen wurden an den FS übergeben.
Im Ack stehen die verarbeiteten Zeichen, den evt. Pufferinhalt bzw. ob alles gedruckt ist kann nur der Versender berechnen.

Zu den Heartbeats:
Dieses ist tatsächlich das einzige Paket, welches nach dem Direkt-Dial als Lebenszeichen erlaubt ist, solange der angerufene FS noch nicht läuft.
Dieses abzuschalten, ist ein Problem wie Fred schon schrieb. Ein HB sollte alle 4 Sek die Verbindung aufrechterhalten. Wie die Empfänger nun ihren Empfangszeitraum einstellen, ist unbekannt. Sinnvoll wäre ja irgend etwas um 6 Sek. Ich habe es über eine Ini-Datei grosszügig auf 10 Sek gesetzt. Aber auch das kann u.U. knapp werden wenn der FS im lokalmodus läuft oder über eine Stromspartechnik (z.B. Funksteckdose) erst eingeschaltet werden muß und das FAG200 zusätzlich 3 Sek Selbsttest macht, bevor der FS200 Strom bekommt. Ganz zu schweigen von meiner mechanischen Vst mit HDW/EMD Technik, wo zwei bis drei Wähler eingestellt werden müssen und das evt. Besetztzeichen abgewartet werden muß (Gesamtzeit max 9 Sek), bei Besetzt dann das ganze mit anderer Nummer nochmal. Im i-Telex hat Fred bisher ca 20 Sek eingeplant, für die Anlassversion sogar 30 Sek. Ich wäre mal wieder einer der Betroffenen, die bei solchen Dingen mit Einschränkungen zu rechnen haben weil ein Dienst sich merkwürdig verhält und einige Clients daraufhin angepasst werden. Wenn diese Idee von mehreren Entwicklern unabhängig weitergetrieben wird, schaffen wir uns die von mir schonmal erwähnten "unsichtbaren Cluster".
Euere Ideen und Versuche solche Dinge via Clientanpassung dennoch lauffähig zu halten in allen Ehren, aber wackelt da der Schwanz nicht mit dem Hund???
Selbst wenn alles Regelkonform abläuft, Automaten wie Rundsendedienst, klkl-/Diensteserver/ Auskunft sind nun mal auf gewisse Zeichenketten wie Endezeichen Irrungszeichen usw. angewiesen. Da kann man dem Dienst keinen Vorwurf machen, wenn Diese Zeichen im Text zur optischen Verschönerung eingebaut werden und dann alles verwirren. Ein Blick in die alten Telexbücher bezüglich wie man richtig mit dem Telexdienst umgeht füllt nicht umsonst mehrere Seiten. Das ist dann ein Problem der Anwender.
Ich habe gerade gelesen das ihr mit Reinhold Debuging macht. Das Wort Symptombehandlung trifft es und klingt netter wie Workaround, beides rangiert bei mir aber am Rand der Verschlimmbesserung.
Trotzdem viel Erfolg bei Reinhold, den ich hoffentlich irgendwann mit Fernschreiber als Tst erreichen kann.
Frohes neues Jahr
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
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

#16

Beitrag: # 22827Beitrag FredSonnenrein »

Hallo zusammen,
BjoernS hat geschrieben: Fr 1. Jan 2021, 12:22 in diesem Fehlerfall passiert folgendes: Während die Zeichen für das Banner in den Sendepuffer für den lokalen FS geschrieben werden, kommt das WerDa schon per i-Telex-Verbindung rein (noch bevor der Acknowledge-Zähler 0 wird) und wandert mitten dazwischen.
Ich hätte ja vermutet, dass der "Banner" als Block in einem Rutsch in den Sendepuffer RIchtung lokaler Fs wandert und somit das WerDa sowieso nur an das Ende eingereiht werden kann. Daher fand ich das "dazwischenfunken" sehr merkwürdig.
Zum Thema "noch bevor": Das ist auch nicht verboten, Daten zu senden, wenn der Ack-Zähler noch "unfertig" anzeigt. Der Ack-Zähler soll halt ein Überlaufen verhinden.
BjoernS hat geschrieben: Fr 1. Jan 2021, 12:22 Der FS bekommt jetzt nach dem WerDa direkt weitere Daten gesendet und das überlagert sich intern ... auch beim T1000 führt das zu seltsamen Ausdrucken.
Das der "echte" Sender nach einem WerDa auch auf den entsprechenden Text wartet, ist klar.
Mein automatisches Sendeprogramm wartet nach einem Werda bis der Ack-Zähler dem Stand aller gesendeter Zeichen entspricht und danach mindestens drei Sekunde Funkstille am Stück sind.
BjoernS hat geschrieben: Fr 1. Jan 2021, 12:22 Wir haben aber gerade mit Reinhold Fehlersuche an anderer Stelle betrieben* und es haben sich dabei Änderungsansätze ergeben, die auch dieses Problem nachhaltiger lösen könnten (wenn auch nur per Symptombehandlung):
  • Empfangene i-Telex-Daten so lange zurückhalten, bis das Banner ganz gedruckt ist.
  • Nachdem ein WRU gedruckt wurde, 20(+1) Zeichen lang Zwangspause für Daten von extern, damit der Kennungsgeber ungestört ablaufen kann
Letzteres mache ich auch unabhängig vom Werda: Solange lokal getippt wird, werden kommende Zeichen im Puffer gelassen und nicht an den Fs gegeben. Ist zwar nicht "orischinol", aber ich finde es gut so...
BjoernS hat geschrieben: Fr 1. Jan 2021, 12:22 Das bringt schlimmstenfalls die Gegenstelle aus dem Takt, aber das ist sie sowieso bereits, wenn sie mit einem WerDa "dazwischen funkt". Wenn sich das stabil bewährt, sollte das Heartbeat auch wieder ohne Nebenwirkungen zu aktivieren sein.
Wovon kommt die Gegenstelle aus dem Takt?
BjoernS hat geschrieben: Fr 1. Jan 2021, 12:22 Ist ein wenig schade, dass einige Dienste nicht quelloffen entwickelt werden -- das würde die Harmonisierung des "i-Telex-Ökosystems" etwas vereinfachen.
Wichtger wäre, dass man sich auch an die Spezifikation hält und nicht etwas hineininterpretiert, was dort nicht steht :D

Fernschreiber hat geschrieben: Fr 1. Jan 2021, 13:54 der Punkt 1 in dem Commit hat sich ja von alleine erledigt, war ja nicht sehr das erhoffte Ergebnis.
Im Punkt 2 nur damit wir das gleiche Verständnis haben: Ack = 0
(meaning printer is running and all data has been printed, matching the
spec)
Diese Aussage gilt wirklich nur am Beginn einer Verbindung, jedes weitere Ack = 0 bedeutet x mal 255 +1 Zeichen wurden an den FS übergeben.
Das stimmt so nicht. Aufeinanderfolgende Ack mit dem selben Datenwert heißen, dass in dem Zeitraum dazwischen keine Zeichen gedruckt worden sind. Das original i-Telex verwendet das Ack-Telegramm quasi anstelle des Heartbeat, solange die Verbindung steht.
Fernschreiber hat geschrieben: Fr 1. Jan 2021, 13:54 Im Ack stehen die verarbeiteten Zeichen, den evt. Pufferinhalt bzw. ob alles gedruckt ist kann nur der Versender berechnen.
Korrekt.
Fernschreiber hat geschrieben: Fr 1. Jan 2021, 13:54 Zu den Heartbeats:
Dieses ist tatsächlich das einzige Paket, welches nach dem Direkt-Dial als Lebenszeichen erlaubt ist, solange der angerufene FS noch nicht läuft.
Dieses abzuschalten, ist ein Problem wie Fred schon schrieb. Ein HB sollte alle 4 Sek die Verbindung aufrechterhalten. Wie die Empfänger nun ihren Empfangszeitraum einstellen, ist unbekannt. Sinnvoll wäre ja irgend etwas um 6 Sek. Ich habe es über eine Ini-Datei grosszügig auf 10 Sek gesetzt.
Die 4 Sekunden sind eigentlich auch ziemlich "hart". Beim i-Telex würden auch 15 Sekunden reichen...
Fernschreiber hat geschrieben: Fr 1. Jan 2021, 13:54 Aber auch das kann u.U. knapp werden wenn der FS im lokalmodus läuft oder über eine Stromspartechnik (z.B. Funksteckdose) erst eingeschaltet werden muß und das FAG200 zusätzlich 3 Sek Selbsttest macht, bevor der FS200 Strom bekommt. Ganz zu schweigen von meiner mechanischen Vst mit HDW/EMD Technik, wo zwei bis drei Wähler eingestellt werden müssen und das evt. Besetztzeichen abgewartet werden muß (Gesamtzeit max 9 Sek), bei Besetzt dann das ganze mit anderer Nummer nochmal. Im i-Telex hat Fred bisher ca 20 Sek eingeplant, für die Anlassversion sogar 30 Sek. Ich wäre mal wieder einer der Betroffenen, die bei solchen Dingen mit Einschränkungen zu rechnen haben weil ein Dienst sich merkwürdig verhält und einige Clients daraufhin angepasst werden. Wenn diese Idee von mehreren Entwicklern unabhängig weitergetrieben wird, schaffen wir uns die von mir schonmal erwähnten "unsichtbaren Cluster".
Welcher Timeout angewendet werden muss, möchte ich eigentlich nicht festlegen. Es muss halt mehr als 4 Sekunden sein plus "vermutete" Zeiträume für temporäre Verbindungsunterbrechungen auf TCP-Ebene.
Fernschreiber hat geschrieben: Fr 1. Jan 2021, 13:54 Euere Ideen und Versuche solche Dinge via Clientanpassung dennoch lauffähig zu halten in allen Ehren, aber wackelt da der Schwanz nicht mit dem Hund???
Selbst wenn alles Regelkonform abläuft, Automaten wie Rundsendedienst, klkl-/Diensteserver/ Auskunft sind nun mal auf gewisse Zeichenketten wie Endezeichen Irrungszeichen usw. angewiesen. Da kann man dem Dienst keinen Vorwurf machen, wenn Diese Zeichen im Text zur optischen Verschönerung eingebaut werden und dann alles verwirren. Ein Blick in die alten Telexbücher bezüglich wie man richtig mit dem Telexdienst umgeht füllt nicht umsonst mehrere Seiten. Das ist dann ein Problem der Anwender.
Ich habe gerade gelesen das ihr mit Reinhold Debuging macht. Das Wort Symptombehandlung trifft es und klingt netter wie Workaround, beides rangiert bei mir aber am Rand der Verschlimmbesserung.
Trotzdem viel Erfolg bei Reinhold, den ich hoffentlich irgendwann mit Fernschreiber als Tst erreichen kann.
Frohes neues Jahr
So sehe ich das auch.
Wann immer jemand meint eine Lücke in der Spec zu sehen, nur her damit.
Ich möchte allerdings keine unnötigen Einschränkungen einbauen, die nur einen Grund in "bequemer" Implementierung haben.
Diskutieren können wir über alles...

Auch von mir hier nochmal ein frohes neues Jahr.

Fred
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag:
380170JFK
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

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

#17

Beitrag: # 23545Beitrag BjoernS »

Hallo nochmal,

bei mir kam die letzten Wochen einiges dazwischen, deshalb hat es etwas gedauert ... :schwitz:
FredSonnenrein hat geschrieben: Fr 1. Jan 2021, 16:05 Zum Thema "noch bevor": Das ist auch nicht verboten, Daten zu senden, wenn der Ack-Zähler noch "unfertig" anzeigt. Der Ack-Zähler soll halt ein Überlaufen verhinden.
Ah ja, wertvolle Info ... im Nachhinein betrachtet aber logisch. (Obwohl die guten Umgangsformen das Abwarten des Datumsaudrucks beinhalten könnten.)
FredSonnenrein hat geschrieben: Fr 1. Jan 2021, 16:05 Letzteres mache ich auch unabhängig vom Werda: Solange lokal getippt wird, werden kommende Zeichen im Puffer gelassen und nicht an den Fs gegeben. Ist zwar nicht "orischinol", aber ich finde es gut so...
Aha! :lol: Das gibt natürlich im Zweifel auch weniger Reibung mit Diensten.
FredSonnenrein hat geschrieben: Fr 1. Jan 2021, 16:05 Wovon kommt die Gegenstelle aus dem Takt?
Naja, wenn z.B. ein Dienst max. 2 s auf die WRU-Antwort wartet, der lokale FS aber noch mit Drucken des Datums beschäftigt ist. Aber eher Nebenkriegsschauplatz.
FredSonnenrein hat geschrieben: Fr 1. Jan 2021, 16:05 Wichtger wäre, dass man sich auch an die Spezifikation hält und nicht etwas hineininterpretiert, was dort nicht steht :D
:lol: :thumbup:

Grüße


Björn
844767 twtr d
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

#18

Beitrag: # 23553Beitrag FredSonnenrein »

Ich habe eben nochmal den Abschnitt der Spezifkation über das ACK-Paket gelesen und dabei eine Ungenauigkeit bemerkt. Es war nicht deutlich genug, dass noch in einem Empfangspuffer befindliche Zeichen im ACK-Paket nicht mitgezählt werden sollen, sondern erst beim Drucken eines Zeichens der Zähler inkrementiert werden soll.
Das i-Telex inkrementiert den Zähler beim "Auslösen" des Start-Bits.
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“