Rundsender und Nachrichtendienst

[xachsewag]

Hallo Detlef,

das ist mir auch schon aufgefallen. Seit ein paar Wochen kommen 80% der Rundsendungen auf meiner Hauptmaschine an. Allerdings eben nicht immer. Bis jetzt kamen sie alle zuverlässig auf meiner 53134 an.

[detlef]

Das ist sehr merkwürdig. Ich habe seit Monaten nichts am Rundsender verändert.
Habt ihr vielleicht in den letzten Wochen ein i-Telex-Update gemacht?

[detlef]

Ich hab' jetzt die Rundsendung auch mit WinTlx probiert, egal welche Nummer meiner Maschinen ich eingebe, alles kommt nur auf dem Lo15 (97486) heraus.
Wenn ich allerdings mit WinTlx direkt eine meiner Maschinen anwähle, komme ich auch immer auf die richtige.
Liegt das jetzt an dem Rundsendeprogramm oder vielleicht doch an meinem i-Telex?

Sorry, da hatte ich jetzt noch mal einen Denkfehler drin. Du hattest das ja mit WinTlx gestestet und nicht mit dem Rundsender (hatte ich ja auch so vorgeschlagen). Das liegt einfach daran, dass ich im Moment viel um die Ohren habe und immer nur mal kurz reinschauen kann.

WinTlx und Rundsender sind zwei verschiedene Baustellen. Die verwenden nicht die gleichen i-Telex-Routinen. Von daher war meine Schlussfolgerung, dass der Rundsender ein generelles Problem mit der Durchwahl hat, erst mal falsch.

Ich werde das alles in den nächsten Tagen/Wochen nochmal systematisch durchtesten. Da ich jetzt hier ein funktionierendes piTelex habe, kann ich das auch gleich mittesten.

Im Moment habe ich noch kein klares Bild, was da wann schiefläuft. Und vor allem, was sich da in den letzten Wochen geändert haben könnte.

[TEHA]

Sorry, da hatte ich jetzt noch mal einen Denkfehler drin. Du hattest das ja mit WinTlx gestestet und nicht mit dem Rundsender

Doch, ich habe den Rundsender mit WinTlx getestet (hab' davon extra einen screenshot gemacht):

WinTlx-Rundsendedienst-test.JPG

[detlef]

Ich meinte den gleichzeitigen Anruf bei deinem T100. Das hattest du mit WinTlx gemacht. Ich hatte das aber auf den Rundsender bezogen.
Dass der Rundsender mit WinTlx funktioniert, das ist sichergestellt. Ich nehme ja auch immer WinTlx zum testen.

[detlef]

Ich habe heute einige Tests gemacht. Zunächst nur von und zu meiner i-telex-Anlage mit neuester Firmware 966. Die
Weiterleitung habe ich deaktiviert.
Ich habe Rundsendungen sowohl an meine Hauptnummer als auch an eine Durchwahlnummer geschickt. Und zwar sehr viele im Laufe des Tages. Teilweise bis zu drei Sendungen an die gleiche Nummer, aber auch gemischt in allen möglichen Kombinationen.

Dabei ist es kein einziges mal vorgekommen, dass eine Rundsendung am falschen Fernschreiber rauskam. Allerdings habe ich zwei kleinere Fehler gefunden, die die wiederholte Anwahl bei besetzt ('occ') betreffen. Da hat der Rundsender früher als vorgesehen aufgegeben und bei Rundsendungen an die gleiche Nummer ist er durcheinander gekommen. Der Effekt war dann aber nur, dass die wiederholte Anwahl ausgeblieben ist. Keine Abbrüche oder falsche Empfangsgeräte oder ähnliches.

Eben gerade habe ich noch ein paar Test mit dem piTelex gemacht und ich bin der Meinung, dass die aktuelle piTelex-Version einen Bug bei eingehenden Verbindungen hat. Das Paket mit der Protokoll-Version wird häufig nicht beantwortet. Das konnte ich sowohl mit Anrufen mit meinem i-Telex als auch mit WinTlx als auch mit dem Rundsender reproduzieren.

Man sieht auch in der Log-Ausgabe des i-Telex, dass das i-Telex ein Paket #7 (Protokoll-Version) schickt, aber vom piTelex keine Antwort kommt.
Dem i-Telex ist das egal, das ignoriert solche Fehler und macht einfach weiter. Meine Routinen sind ist da etwas pingeliger und warten brav auf das Paket #7 und wenn das nicht kommt, gibt es irgendwann ein Timeout.

Ich habe jetzt als Hack eingebaut, dass WinTlx und der Rundsender vor der Protokoll-Version erst noch eine Heartbeat-Paket senden. Möglicherweise behebt das das Problem, weil piTelex das erste gesendete Paket anscheinend nicht vollständig empfängt.

Im piTelex-Quelltext konnte ich das Problem noch nicht lokalisieren. Möglicherweise hängt das auch mit Selbsttest zusammen. Ich werde den morgen mal testweise deaktivieren. Vielleicht löst das das Problem auf der piTelex-Seite.

Außerdem waren das jetzt wieder nur Anruf an die eigene IP-Nummer, wo es ja schon Probleme gab. Für Anrufe an Rolfs piTelex war es jetzt schon etwas spät.

[detlef]

Grrr!

Ich habe jetzt glaube ich auch das Problem von Thomas gefunden.

Das hier steht im Wiki zum Version-Packet:

The length (2nd byte) value of this packet may be from 1 to 20 (total length 3 to 22 bytes), although it's recommended to use only values between 1 and 6, due to a bug in some i-Telex's ethernet board firmware versions (865 to 877).

Thomas hat die Firmware-Version 870.

Ich wusste von dem Problem und hatte das Version-Packet meiner Dienste schon auf eine Länge von 7 gekürzt. Es soll aber nicht länger als 6 sein.

Der Effekt beim den betroffenen i-Telex-Versionen ist, dass das i-Telex durch das überlange Version-Packet fälschlicherweise temporär in den ASCII-Modus schaltet und deshalb das Extension-Packet nicht mitbekommt, das die Durchwahl enthält.

Ich korrigiere das morgen und dann testen wir nochmal.

Das hat jetzt aber nichts mit dem piTelex-Problem zu tun.

[detlef]

Heute Nachmittag habe ich noch einen Fehler gefunden. Diesmal im Rundsender. Der könnte die Ursache dafür sein, die Verbindungen speziell zu piTelex-Systemen manchmal abgebrochen sind. Das muss man jetzt mal beobachten.

Für die Insider: Probleme mit dem Acknowledge.

[detlef]

Der aktuelle Stand: Es läuft noch nicht ganz rund beim Senden an piTelex-Teilnehmern. Die Kennungsgeberabfrage funktioniert noch nicht zuverlässig. Ich bin noch nicht dahinter gekommen, woran es genau liegt.
Was mir aufgefallen ist, ist dass das piTelex sehr, sehr viele Acknowledge-Pakete sendet. Viel mir als norwendig wären. Aber das dürfte kein Problem sein.

Mal wieder etwas technisch:

Aus irgendeinen Grund kommt das Acknowledge-Zähler aus dem Tritt und dann stimmt die Anzahl der Zeichen im Puffer beim Client nicht mehr mit der errechneten Menge des Dienstes überein. Der Dienst macht dann nach einen kurzem Timeout einen Reset bzw Resync des lokalen Acknowledge-Zählers, aber wenn das gerade dann passiert, wenn der Kennungsgeber abgefragt wird, dann kommt es zu Fehlern. Der Dienst schickt dann die WRU-Abfrage zu früh (obwohl der Client noch druckt) und überhaupt kommt alles durcheinander.
Ich vermute noch einen Fehler im Rundsendedienst. Das ist etwas schierig zu testen, weil der Fehler im Moment nur bei größeren Verteilern auftritt. Das ist irgendeine Timing-Geschichte. Und ich will die Teilnehmer nicht zu sehr mit ständigen Testsendungen nerven.

[detlef]

Franz hatte gestern wieder Probleme mit dem Abschließen der Nachricht mit "+++".
Ich habe noch keine Ahnung, wodurch dieser Fehler reingekommen ist und ich kann ihn nicht nachvollziehen. Weder mit einem i-Telex noch mit meinem WinTlx.
Schreibt doch mal ein paar Rundschreiben, damit ich sehen kann, was da passiert.