Noch'n kleines Projekt - WinTelex

[damarco]

So ich bin jetzt weiter und zwar passiert folgendes. Durch den Nagelalgorithmus wird das ACK verzögert gesendet und nun passiert komischerweise etwas das die Windows Seite ein Paket per ACK bestätigt was schon längst als empfangen gilt. Jenes Paket mit Nutzdaten und gesetzten ACK flag mit einer schon bestätigten Sequence ID wird bei bei mir als ungültig nicht durchgereicht und auch nicht später per ACK bestätigt.

Das Problem ist das Detelf eine Sequence von vielen kleinen Paketen sendet, z.Bsp wenn 8 Byte zu senden sind macht Detlef 3 Pakete daraus mit 5,2,1 Byte. Irgend etwas im Zusammenhang mit dem Wlan was ja eine eigene Sicherungsschicht besitzt geht dann in die Hose. Es tritt ja auch nicht immer auf um so bescheidener der Empfang um so höher ist auch die Fehlerquote. Zumal auch Pakete mit unterschiedlichen Laufzeiten auftreten, im Normalfall kommen diese ja so an wie sie versendet werden -> "1234" aber durch unterschiedliche Laufzeiten und Fehlern kommt dann "2143" auf der Gegenseite an. Das ist kein Problem durch den TCP/IP Stack wird das wieder richtig zusammengesetzt....

Fazit: das kurze hintereinander senden von Paketen mit kleiner Payload ist ein Problem und das gab es auch schon zu Telnet Zeiten. Man kann ja die Payload auch größer machen oder sie in einem Paket zusammenfassen.

[detlef]

So tief bin ich ins TCP/IP-Protokol noch nicht eingestiegen. Nagle-Algorithmus habe ich schonmal gehört.

Ich sende spätestens alle 100 ms das was ich im Ausgangspuffer habe. Wenn da jemand im entsprechenden Rhytmus tippt, dann kommt evtl. alle 100 ms ein Zeichen. Wenn ich das Sendeintervall erhöhe, dann bekommt man ein spürbares Delay zwischen tippen und dem Ausdruck auf einem daneben stehenden Fernschreiber.

Ich habe mal eine Version 2.2.4 abgelegt, wo neben der Puffergröße auch das Sendeintervall einstellbar ist. Nur mal so zum Ausprobieren.

Meine Dienste verwenden ja den gleichen Sendealgorithmus wie WinTlx. Und die werden mit piTelex verwendet und ich habe noch nicht gehört, dass da Zeichen verloren gehen. Aber es kann natürlich sein, dass die meisten LAN verwenden und dass das so selten vorkommt, dass es einfach nicht auffällt.

[damarco]

Hallo,

Danke probiere ich mal aus was passiert. Aber ich bin dazu geneigt das erst mal bei Seite zu legen, um es mit der eigenen Applikation nachzuvollziehen.

Wie gesagt es ist jetzt kein Thema das man großer Aufmerksamkeit schenken sollte bis die Ursache wirklich geklärt ist.

[damarco]

Hallo Detlef,

ich meine noch ein Bug gefunden zu haben und zwar tritt das in der Konsole beim Gegensenden auf. Das Problem ist wohl das dein Decoder sich die Ebene nicht merkt und oder herstellt. Das führt dazu wenn die Gegenstation weiter sendet und keine Umschaltung erfolgt bei dir in der Konsole Käse angezeigt wird.

Kurz, durch das Gegensenden sendet winTelex ZI und danach sendet die Gegenstelle weiter im BU Mode. Es sollte eigentlich ein y kommen wird aber bei dir als 6 decodiert. Bis eben die Gegenseite wieder umschaltet, läuft die Konsole urtümlich im ZI Mode.

Version 2.2.3

Code: Alles auswählen

07.07.2025 11:06:33.989 Debug [ItelexProtocol] [DecodePacket] recv baudot data 48 "kaufen sie jede woche vier gute bequeme pelze x"
07.07.2025 11:06:34.069 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 00 (rem_ack=0 send=0 rem_buf=0)
07.07.2025 11:06:35.000 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 00 (rem_ack=0 send=0 rem_buf=0)
07.07.2025 11:06:35.993 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 00 (rem_ack=0 send=0 rem_buf=0)
07.07.2025 11:06:36.985 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 00 (rem_ack=0 send=0 rem_buf=0)
07.07.2025 11:06:37.398 Debug [ItelexProtocol] [SendCmd] Send packet BaudotData 02 01 02 (rem_ack=0 send=0 rem_buf=0)
07.07.2025 11:06:37.510 Debug [ItelexProtocol] [SendCmd] Send packet BaudotData 02 05 08 1B 10 1C 1D (rem_ack=0 send=1 rem_buf=1)
07.07.2025 11:06:37.620 Debug [ItelexProtocol] [SendCmd] Send packet BaudotData 02 06 1D 19 15 04 1F 0D (rem_ack=0 send=6 rem_buf=6)
07.07.2025 11:06:37.732 Debug [ItelexProtocol] [SendCmd] Send packet BaudotData 02 04 1C 14 04 12 (rem_ack=0 send=12 rem_buf=12)
07.07.2025 11:06:37.997 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 01 (rem_ack=1 send=16 rem_buf=15)
07.07.2025 11:06:38.067 Debug [ItelexProtocol] [SendCmd] Send packet BaudotData 02 01 04 (rem_ack=1 send=16 rem_buf=15)
07.07.2025 11:06:38.990 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 07 (rem_ack=7 send=17 rem_buf=10)
07.07.2025 11:06:39.069 Debug [ItelexProtocol] [SendCmd] Send packet BaudotData 02 05 1B 1E 1F 19 0C (rem_ack=7 send=17 rem_buf=10)
07.07.2025 11:06:39.181 Debug [ItelexProtocol] [SendCmd] Send packet BaudotData 02 01 06 (rem_ack=7 send=22 rem_buf=15)
07.07.2025 11:06:39.986 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 0D (rem_ack=13 send=23 rem_buf=10)
07.07.2025 11:06:40.194 Debug [ItelexProtocol] [SendCmd] Send packet BaudotData 02 05 01 09 17 1B 09 (rem_ack=13 send=23 rem_buf=10)
07.07.2025 11:06:41.004 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 13 (rem_ack=19 send=28 rem_buf=9)
07.07.2025 11:06:41.990 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 19 (rem_ack=25 send=28 rem_buf=3)
07.07.2025 11:06:43.017 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:44.017 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:45.017 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:46.020 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:47.015 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:48.013 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:49.019 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:50.020 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:51.022 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:52.015 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:53.017 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:54.017 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:55.017 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:56.019 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:57.027 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:58.033 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:06:59.058 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:07:00.054 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:07:01.052 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:07:02.079 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:07:03.097 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:07:04.099 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:07:05.110 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:07:06.120 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:07:07.105 Debug [ItelexProtocol] [DecodePacket] recv ack cmd  06 01 1C (rem_ack=28 send=28 rem_buf=0)
07.07.2025 11:07:07.736 Debug [ItelexProtocol] [DecodePacket] recv baudot data 48 "6 1234567890,.:-+=/()[CR][LF]kaufen sie jede woche v"

[detlef]

Gegensenden ist ja so eine Sache und eigentlich nicht erlaubt. Bei echten Fernschreibern kommt da nur Müll raus.

Was genau machst du? Im Log sieht man beim Senden den Klartext nicht. Sendest du mit WinTlx ein ZI, nachdem die Gegenstelle BU gesendet hat und gerade weitere Zeichen auf der BU-Ebene sendet?