Noch'n kleines Projekt - WinTelex

[DF3OE]

Johannes,
die Teilnehmerserver und Ports sind bewusst NICHT vorkonfiguriert....

[380170JFK]

Henning,

weißt du den Port der Server auf Anhieb?

[kulo74]

Deswegen ist das jetzt eine Beta-Version zum Testen.

Erster Test schaut gut aus - bis jetzt konnte ich keine Fehler bzw. Probleme feststellen.

[damarco]

Hallo Detlef,
kannst du mir mal kurz deine Flusskontrolle erklären?

Ich bin da auf ein Problem gestoßen und zwar sendet winTlx die Daten zu schnell und zwar so schnell das dein berechneter ACK Count zwei mal überläuft. Offenbar hängt das mit dem Prüfsender zusammen der die Daten in den Buffer schreibt. du sendest immer Pakete mit nur 5 Zeichen drin und das sehr kurz hintereinander. Nun könnte man meinen das wenn der ACK Count vom Empfänger hinterher hinkt das winTlx auch die Sendrate anpasst. Zudem scheinst du auch keinen Sicherheitshaken drin zu haben das die Daten nicht schneller gesendet werden können wie es aus der Baudrate möglich wäre. Meldet ein Empfänger z.Bsp mehr Zeichen als Verarbeitet zum Zeitpunkt in Bezug zur Baudrate darf es nicht passieren das der Sender mit 300 Baud Daten hinterher schiebt. wenn noch Daten im Sendebuffer sind.

Die Flusskontrolle muss in einen gewissen Rahmen erfolgen, wenn der Empfänger zu langsam ist ok aber er darf nie grob schneller sein als die eingestellte Baudrate.

Ich will es nur verstehen was passiert und wo das Problem in meinem Code besteht Das Problem tritt nur auf wenn man den Testtext z.Bsp 10 mal sendet und auch nicht immer es kommt eben darauf an ob die Bedingung erfüllt ist das dein kalkulierter ACK zweimal überläuft da der Empfänger > 512 Zeichen hinterher hängt. Es würde auch nicht auftreten wenn durch die Flusskontrolle nicht immer weiter Daten nachgeschoben würden.

[detlef]

Welche Version von WinTlx hast du denn getestet? In älteren Versionen waren schon mal Fehler drin.

Das mit der Baudrate verstehe ich nicht. i-Telex kennt keine Baudrate. Denn man weiß ja nicht, was für ein Endgerät angeschlossen ist. Das kann ein Fernschreiber mit 50, 100 oder 200 Baud sein. Oder ein Dienst, der die Daten viel schneller annehmen kann.
Die Baudrateneinstellung in WinTlx ist nur ein Behelf, damit die Zeichen einigermaßen gleichmäßig angezeigt werden.

Ansonsten wird schon das von Fred beschriebene Verfahren eingesetzt und in der Praxis funktioniert es ja mit i-Telex und piTelex.

Das ist aber jetzt schon bestimmt zwei Jahre her, dass ich zuletzt Änderungen an der Übertragung gemacht habe. Deswegen müsste ich mir das im Detail selber noch mal anschauen.

[damarco]

2.1.5 und ich merke ein bisschen alt 27.09.2022

Nun naja ich versuche mich an der Baudrate zu orientieren und das es bei bedarf schneller werden kann ist dann er optional. Ja mit einen echten System kann das Verhalten nicht auftretet da ja die Karten die Daten mit der Eingestellten Rate verarbeiten selbst der AB.

Es ist ja nicht so das der Empfänger 512 Zeichen hinterher hängt sondern der Überlauf von 1Byte breiten ACK scheint nicht berücksichtigt zu werden. Die Variable darf nicht zweimal überlaufen. Auch sein Sendcounter ist nur 1Byte groß und kann mehrmals überlaufen und dann klappt der Vergleich mit dem empfangenen ACK nicht mehr....

Ich gehe davon aus das ich auf meiner Seite einen Denkfehler drin habe....

[detlef]

Mit dem Überlauf habe ich auch schon gekämpft und ich hatte da auch schon Fehler drin.
Ich stecke aktuell gerade in einem anderen Projekt. In 2-3 Wochen könnte wir uns das gerne mal zusammen anschauen. Vorher schaffe ich das nicht.

Und teste mal bitte mit einer aktuellen WinTlx-Version. Die verhält sich vielleicht anders.

Ich habe mal kurz reingeschaft. Grundsätzlich sollte WinTlx das Senden einstellen, wenn es vom Empfänger per Ack einen Pufferfüllstand >= 16 Zeichen signalisiert bekommt. Dass WinTlx die Pakete so schnell sendet, dass es zwischen zwei Ack's zu einem Überlauf kommt, kann ich mir irgendwie nicht vorstellen.

Ich muss das aber, wie gesagt, selbst mal überprüfen. Ist einfach zu lange her.

[damarco]

Immer langsam, alles Ok ich bastel bei mir noch herum...

Es scheint so zu sein das beim starten vom Senden es ein Problem gibt wenn sich der ACK Wert vom Empfänger nicht unmittelbar ändert. Dieser wird ja beim iTelex 3sec und bei dir 1sec gesendet. Wenn zum Beispiel das senden des ACK vor 150ms -> ein Zeichen(50 BAUD) liegt kommt natürlich auch noch der alte ACK Wert weil das Zeichen noch nicht geschrieben wurde. Du sendet immer munter Zeichen hinterher und stellst dann einen nochange Timout fest das der Empfänger nichts schreibt.

Jener Timeout ist mein Sargnagel da du auch munter meinen Eingangspuffer füllst mit über 50..70 Zeichen. Eigentlich wie du schon sagt müsste der Sender warten und wenn wirklich ein ACK Timeout auftritt die Zeichen mit der eingestellten Baudrate senden.

So mach ich das, ist der ACK Wert ungültig oder fehlt dieser plötzlich wird nach der Baudrate das nächste senden terminiert. Läuft der Eingangspuffer über wird die Verbindung zurückgewiesen. Die Ursache kann man ja in der Reject Antwort übergeben.

[detlef]

WinTlx prüft vor jedem Senden eine Pakets den letzten empfangenen Ack-Wert. Es gibt kein Timeout.
Und wie gesagt, es gibt beim i-Telex-Protokoll keine Baudrate. Die ist nirgends im i-Telex-Protokoll erwähnt und wäre eine Änderung der Spezifikation.

Wie gesagt, teste bitte mit der aktuellen Version. Dann kann ich das auch überprüfen.

Der Ack-Wert muss auch nicht regelmäßig gesendet werden. Man muss den eigentlich nur senden, wenn er sich ändert. Deswegen kann der auch nicht plötzlich fehlen.

[damarco]

Also ich habe jetzt die aktuelle Version 2.2.1 vom 10.12.2024 und da werden mir leider im Debug Fenster keine send und resv Messages angezeigt.
Zudem tritt der Timeout auch bei Connects mit einen iTelex System auf und außerdem von mein Connect komischerweise als Ascii erkannt, gesendet wird aber baudotcode. Keine Ahnung weshalb die Meldung im Debugfenster erscheint.

Also es gibt wohl Versionen da setzt das senden des ACK aus irgend einen Grund aus und das habe ich bei meinem System auch schon nachvollziehen können.

Das das man sich an der Baudrate orientiert ist ja nichts falsches, denn es ist am Ende nichts anderes als den Füllstand des Buffers zu beeinflussen. Wenn das System mit 50 Baud läuft und man mit 300 Baud rein sendet ist Pufferüberlauf nicht weit. Die Reaktion darauf ist nicht im Protokoll definiert, bei mir kommt dann der Reject um der Gegenstelle anzuzeigen da ist was schief gelaufen.

Die Pakete sinnvoll zu verteilen ist auch nichts falsches, als Burst 5 Zeichen direkt hintereinander zu senden macht wenig Sinn wenn diese ohnehin schon vorliegen. Dann kann man auch die vollen 48 Zeichen ausnutzen und das einen einem Paket und wenn als Gegenstelle ein Mikrocontroller wartet ohnehin.

Ich mach das so das die Zeichen zunächst vom Timing nach der Baudrate versendet werden -> wenn ich 48 Zeichen Sende warte ich bis zum 38 Zeichen = 5700ms. In dieser Zeit muss ein ACK kommen und wenn nicht wird das nächste Paket wieder nach der Baudrate und den Pufferstand terminiert. Kommt kein ACK nach einer Zeit X sind nachfolgende ungültig und es geht ohne Flusskontrolle nach der Baudrate weiter.

Wenn die Gegenstelle die Zeichen schneller Verarbeitet als die Kalkulierte Rate werden nicht vorher weitere Daten versendet. Das verhält nicht genau als wenn man mit einem Itelex mit 50Baud in eins mit 100Baud rein sendet. Es geht eben nicht schneller und anderes herum wird die 100Baud Gegenstelle langsamer.