Fehlermeldungen vom I-Telex

Technischer Support bei Problemen mit i-Telex sowie dessen Komponenten.

Moderator: FredSonnenrein

Benutzeravatar

BjoernS
Rank 8
Rank 8
Beiträge: 174
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Fehlermeldungen vom I-Telex

#21

Beitrag von BjoernS »

Moin Willi!
Fernschreiber hat geschrieben: Mi 25. Mai 2022, 12:02 das mit der Bemerkung das auch ohne "03" Paket die Welt nicht untergeht war darauf bezogen, das ein Abbruch einer TCP-Verbindung nicht immer steuerbar ist. [...] Bei "echter" Unterbrechung ( Fehler irgendwo in Übertragungsstrecke) ohne Reconnect kommt dann diese (ich nenne es statt Fehler- mal Hinweis-) Meldung. Das dieser Effekt auch zwischen i-telex-Hardware auftritt zeigt doch, das die End to End Verbindungen so stabil nicht sind.
Dass TCP-Verbindungen übers Internet oft abreißen, habe ich bisher so nicht beobachten können. TCP ist sehr fehlertolerant, z.B. liegt der native TCP-Sitzungs-Timeout einer bestehenden Verbindung je nach Einstellung im Betriebssystem meist im Stundenbereich. Da viele Anwendungen (und ggf. Firewalls dazwischen) ungeduldiger sind, wird oft ein Timeout der Anwendung darübergelegt -- inkl. eines Mechanismus zum Offenhalten der Verbindung, siehe Heartbeat/Acknowledge. Wenn dieser Timeout zuschlägt, schließt die Anwendung aktiv die TCP-Verbindung. Oder das Betriebssystem hat aus irgend einem Grund die Anwendung selbst abgeschossen, oder eine Firewall hat die Geduld verloren, und weitere ankommende Pakete werden mit RST quittiert, was einer Trennung gleichkommt.

Wenn bei einer bestehenden TCP-Verbindung mal Pakete verloren gehen, passiert mit der Verbindung erstmal nichts, die Anwendungen könnten problemlos weiterwarten und das Protokoll kümmert sich -- sobald es wieder eine funktionierende Route für die Pakete gibt -- um die Anforderung der verlorenen Pakete und bringt die "nachgelieferten" wieder in die richtige Reihenfolge.

Im Übrigen benutzt auch der Centralex zu jedem "Kunden" eine dauerhafte TCP-Verbindung, und das scheint doch recht stabil zu laufen. (Hat da jemand Erfahrungen dazu? :?)
Fernschreiber hat geschrieben: Mi 25. Mai 2022, 12:02 Nicht umsonst nutzt HTTP das TCP in Basisversion u.a. nur als 1mal- (one shot) Verbindung.
Seit HTTP/1.1 nicht mehr (anno 1999, Keepalive-Option). Wegen der Leistungsprobleme, die das ständige Verbinden und Trennen für jede Einzelanfrage verursachen.
Fernschreiber hat geschrieben: Mi 25. Mai 2022, 12:02 Es liegt auch in der Natur der Sache das ein pi leichter und öfter seinen Dienst versagen kann ( und damit kein "03" mehr schicken kann egal wie es programmiert ist) wie der AT-Mega im i-Telex.
Da komme ich jetzt nicht mehr mit ... Auf meinem Pi läuft piTelex wochenlang ohne Unterbrechung bzw. Fehler. Der gelegentliche geplante Neustart ist nur bei Kernelupdates nötig. Was für einen prinzipiellen Vorteil hat der ATmega denn hier? :?
Fernschreiber hat geschrieben: Mi 25. Mai 2022, 12:02 Zu deinem Statement in #11:
1.Wenn wir trennen, z.B. wegen ST-Bedienung
Selbst wenn Du ausschliessen kannst das in deinem Code keine Lücke besteht das zu umgehen, ist da auch noch das OS. Das macht den Socket u.U.
zu (getrieben von internen oder externen Einflüssen) , das kriegtst du garnicht so schnell mit und schreibst noch in den Sendepuffer, welcher dann auch weg ist. Kommt natürlich nie an.
Diese Betriebssystemfehler bekomme ich im Programm zumindest mit (Socket-Schreibfehler). Die sind aber wirklich extrem selten. Ich kann dir aus den Logs meines Pi vmtl. keine fünf davon zusammenklauben.

Um hier Erfahrungen zu sammeln, schreibe ich den gesamten Verkehr über den Telex-Port meiner Maschine auf der Transportebene mit. Gelegentlich sieht man mal eine TCP Retransmission. Größere Zuverlässigkeitsprobleme habe ich bisher keine finden können, mit Ausnahme des gelegentlich holprigen WLAN. Hier habe ich alle paar Tage bis Wochen ein Verbindungsausfall von wenigen Sekunden, i.d.R. fehlgeschlagenes Roaming. Dementsprechend versagt selten mal ein Verbindungsselbsttest, den piTelex alle 20 s ausführt. In der Regel überschneiden sich die beiden aber nicht.

Grüße


Björn
844767 twtr d

Fernschreiber
Rank 8
Rank 8
Beiträge: 195
Registriert: Sa 17. Dez 2016, 15:28
Wohnort: Münster
Hauptanschluß: 25060 schuett d
Kontaktdaten:

Re: Fehlermeldungen vom I-Telex

#22

Beitrag von Fernschreiber »

Hallo Björn,
wir haben da wohl verschiedene Backgrounds und auch Erfahrungen gesammelt. Das brauchen wir hier nicht weiter breittreten. Fakt bleibt aber das die
Hinweismeldungen sowohl zwischen t-telex wie auch (vermehrt) zwischen i-telex und Alternativsystemen auftreten.
Deine Beschreibung des TCProtokolls ist richtig, wir setzen aber mit den Timeouts des i-telex Protokolls sehr enge Grenzen reizen das TCP nicht aus.
Zudem besteht zwischen der Socketrealisierung einer Ethernetkarte und dem pi ein grosser Unterschied bezüglich der Ressourcen. Während erstere wohl sehr viel Einsatz des Rechners belegt (Fred schrieb mal er müsste sich um die Reihenfolge der Pakete selbst kümmern) und kaum Speicher hat, ist die Lage beim Pi eher komfortabel. Viel Speicher und reichlich Ressourcen. Der Centralex-Server hat hier schon des öfteren zu Diskussionen geführt, aber erst dann wenn die Erreichbarkeit über einen gewissen Zeitraum ausfällt und auffällt. Zudem wird das oft in Chat behandelt und ist dann weg.
Die HTTP Änderung ist richtig, ich kenne aber keinen normalen Webseitenserver der das anbietet. Bei Verbindungen die eine feste Zuordnung zwischen Browser und Server brauchen (Einkaufsysteme o.ä. die nicht echtzeitsynchron sein können) ist das eine Erleichterung, denn die Loadbalancer machen sonst Ärger, die "sticky Einträge" dort sind auch nur bedingt wirksam.
AT-Mega vs. PI: meine Erfahrung zeigt, das ein Mikrokontroller um Welten stabiler Läuft wie ein Pi. Meine Projekte mit der C-Control und dem 128 Mega laufen seit Jahren unermüdlich und brauchen keinen Support. Ein Pi dagegen mit frischem OS macht es dagagen nichtallzulange, dafür sind zuviel Dinge auch in den Lite-Versionen enthalten, die man nicht braucht. All das zu entfernen macht keinen Spass und birgt das Risiko von zusätzlicher Instabilität. Auch wenn der Pi nicht gerade abstürzt, macht er dann noch was er soll? Ich habe hier zwei 3er liegen die scheinen dauerhaft zu performen, machen aber am Tag mehrere Reboots, merkt man nur wenn man dran arbeitet oder mal ins Log schaut. Nach 20s ist der Spuk vorbeiund alles läuft wieder. Ist Denen nicht abzugewöhnen, andere Steckernetzteile (%V/5A)haben kaum etwas geändert. Es ist Spielzeug zum gelegentlichen Gebrauch, sei es als Arbeitsplatzrechner oder Mediacenter, aber die entsprechende Webseite angeklickt kann dennoch zu einem Stillstand führen. Einer völlig abgespeckten OS Variante von Stretch oder etwas kompatiblen als Betriebsrechner würde ich allerdings noch eine Chance geben. Wie ich vor Jahren hier schon mal schrieb, ich würde damit nicht mal eine Waschmaschine steuern. Es soll ja eine Industrievariante geben, vielleicht ist die stabiler. Von der C-Control gab es eine Version mit Kfz-Zulassung. Gefühlt laufen die Pi2 mit Jessie als OS wesentlich stabiler, die sind auch als Telexconverter im Einsatz.
Bei den Logs muss jeder selber entscheiden was er protokollieren möchte und wie. Ich logge nur im Bedarfsfall.
Mit welchem OS arbeitest Du auf dem Pi? Ich habe bisher halt das offizielle Angebot genutzt weil ich nicht noch mehr Zeit nur mit dem Konfigurieren des Betriebssystems verbringen wollte, für's Hobby reichts ja. Wenn Du zufällig weisst wie ich im Apache Webserver die permanente TCP-Variante einstellen kann, bin ich dran interessiert.

Gruß
Willi
Folgende Benutzer bedankten sich beim Autor Fernschreiber für den Beitrag (Insgesamt 2):
roliwWolfgangH
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

BjoernS
Rank 8
Rank 8
Beiträge: 174
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Fehlermeldungen vom I-Telex

#23

Beitrag von BjoernS »

Moin Willi.
Fernschreiber hat geschrieben: Mi 25. Mai 2022, 19:21 Fakt bleibt aber das die Hinweismeldungen sowohl zwischen t-telex wie auch (vermehrt) zwischen i-telex und Alternativsystemen auftreten.
Ja richtig, um mal auf das Thema zurückzukommen ;) Habe jetzt u.A. mit Franz etwas herumprobiert, er bekam währenddessen die Meldung nur im Anschluss an einen Anruf von 11151. Leider kann ich seine Seite nicht mitschreiben, aber der Anruf von 11151 an mich zeigte keine Auffälligkeiten, die das Problem auslösen könnten. Nur das Version-Telegramm wurde zweimal geschickt (Dienst: 0x06 0x01 0x01, Antwort: 0x06 0x01 0x01, Dienst nochmal: 0x06 0x01 0x01).
Fernschreiber hat geschrieben: Mi 25. Mai 2022, 19:21 Die HTTP Änderung ist richtig, ich kenne aber keinen normalen Webseitenserver der das anbietet.
Hmm, mal sehen ...

Code: Alles auswählen

$ wget -d https://www.telexforum.de/
DEBUG output created by Wget 1.20.3 on linux-gnu.
[...]
--2022-05-26 21:33:43--  https://www.telexforum.de/
Resolving www.telexforum.de (www.telexforum.de)... 85.13.151.217
Caching www.telexforum.de => 85.13.151.217
Connecting to www.telexforum.de (www.telexforum.de)|85.13.151.217|:443... connected.
Created socket 3.
Releasing 0x00005583c654da60 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x00005583c654dc40
certificate:
  subject: CN=telexforum.de
  issuer:  CN=R3,O=Let's Encrypt,C=US
X509 certificate successfully verified and matches host www.telexforum.de

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.20.3 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: www.telexforum.de
Connection: Keep-Alive <=========================== "Magst du Keep-Alive?"

---request end---
HTTP request sent, awaiting response... 
---response begin---
HTTP/1.1 200 OK
Date: Thu, 26 May 2022 19:33:43 GMT
Server: Apache
Cache-Control: private, no-cache="set-cookie"
Expires: Thu, 26 May 2022 19:33:43 GMT
Referrer-Policy: strict-origin-when-cross-origin
[...]
Upgrade: h2,h2c
Connection: Upgrade, Keep-Alive <=========================== "Jo, lass mal so machen"
Vary: Accept-Encoding,User-Agent
Keep-Alive: timeout=2, max=1000
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

---response end---
200 OK
[...]
2022-05-26 21:33:44 (704 KB/s) - ‘index.html’ saved [76423]
Ich würde sagen, dann gehört das Telexforum zu den anormalen :D
Fernschreiber hat geschrieben: Mi 25. Mai 2022, 19:21 AT-Mega vs. PI: meine Erfahrung zeigt, das ein Mikrokontroller um Welten stabiler Läuft wie ein Pi. [...] Es ist Spielzeug zum gelegentlichen Gebrauch, sei es als Arbeitsplatzrechner oder Mediacenter, aber die entsprechende Webseite angeklickt kann dennoch zu einem Stillstand führen.
Okay, ich sehe du bist durch deine negativen Erfahrungen gezeichnet ... vielleicht habe ich ja ein "Dienstagsprodukt" ;)
Fernschreiber hat geschrieben: Mi 25. Mai 2022, 19:21 Mit welchem OS arbeitest Du auf dem Pi? Ich habe bisher halt das offizielle Angebot genutzt weil ich nicht noch mehr Zeit nur mit dem Konfigurieren des Betriebssystems verbringen wollte, für's Hobby reichts ja.
Raspberry Pi OS 10, noch.
Fernschreiber hat geschrieben: Mi 25. Mai 2022, 19:21 Wenn Du zufällig weisst wie ich im Apache Webserver die permanente TCP-Variante einstellen kann, bin ich dran interessiert.
Die ist Standard seit HTTP/1.1 und kann im core-Modul konfiguriert werden. Permanent ist im WWW allerdings relativ, außer du hast Clients die alle paar Sekunden neue Anfragen abschicken. Serverseitig musst du vmtl. auch den Timeout hochsetzen. Je nachdem, was genau die Anwendung ist. Und der Client muss es natürlich auch unterstützen.

Grüße


Björn
Folgende Benutzer bedankten sich beim Autor BjoernS für den Beitrag:
WolfgangH
844767 twtr d
Benutzeravatar

WolfgangH
Rank 11
Rank 11
Beiträge: 467
Registriert: So 3. Jan 2021, 21:42
Wohnort: Kirchham (A)
Hauptanschluß: 978310 whoe a

Re: Fehlermeldungen vom I-Telex

#24

Beitrag von WolfgangH »

Hallo zusammen,

zuerst möchte ich einmal sagen, daß ich das super finde, was ihr hier macht und mit welcher Akribie ihr an die Sache herangeht. Da ich mich aber nicht auskenne, habe ich mich bisher zurückgehalten, ich möchte nicht stören.

Zu den Raspberries möchte ich aber kurz meine Erfahrungen schildern. Leider ist die Qualität recht unterschiedlich. Die Dinger wurden ursprünglich als Demo und Schulungsobjekt entwickelt mit dem Ziel möglichst günstig zu sein. Günstig heißt leider nicht hochwertig. Ich habe selber 3 Geräte regelmäßig bis permanent im Einsatz.
Am stabilsten läuft bei mir das Modell 1B als Wetterstation. Selbst mit SD-Karte läuft das System schon 7 Jahre, der letzte beabsichtigte Restart war vor ca. 3 Jahren. Am instabilsten läuft bei mir das Modell 3B, es schmiert nach ca. 3 Wochen regelmäßig ab. Dank Festplatte muß ich nicht mehr jedes mal die SD-Karte neu aufsetzen. Ich kann mich noch an einen Testbericht erinnern, in dem stand, daß man mit dem Blitz eines Fotoapparates einen Reset der CPU herbeiführen kann.

Ich will damit sagen, die Qualität der Raspberries ist bewußt nicht sehr hochwertig und sehr unterschiedlich, daher kann auch jeder eine andere Erfahrung damit haben.
Folgende Benutzer bedankten sich beim Autor WolfgangH für den Beitrag (Insgesamt 4):
BjoernSFernschreiberReinholdKochFranz
Gruß
Wolfgang


Linz:
- 978310 whoe a - T100a
- 69558 kfrey d - T100s
- 978333 =whoe a - Minitelex
Kirchham: (Nachrichtenabruf an Wochenenden, Feiertagen, ...)
- 56449 sche d - T37i
- 11913 hoellw a - LO 3000 (100 Baud)
Benutzeravatar

BjoernS
Rank 8
Rank 8
Beiträge: 174
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Fehlermeldungen vom I-Telex

#25

Beitrag von BjoernS »

Moin Wolfgang!
WolfgangH hat geschrieben: Fr 27. Mai 2022, 15:32 Am instabilsten läuft bei mir das Modell 3B, es schmiert nach ca. 3 Wochen regelmäßig ab. Dank Festplatte muß ich nicht mehr jedes mal die SD-Karte neu aufsetzen.
Betreibst du den ganz ohne SD-Karte? (Denn die sind eine beliebte Fehlerquelle für Abstürze, neben dem Netzteil.)

Aber krass, hängt der sich auf oder startet er einfach neu?
WolfgangH hat geschrieben: Fr 27. Mai 2022, 15:32 Ich kann mich noch an einen Testbericht erinnern, in dem stand, daß man mit dem Blitz eines Fotoapparates einen Reset der CPU herbeiführen kann.
Ja, interessanter Fall. Ein IC der Spannungsversorgung (Abwärtswandler NCP6343) ist empfindlich gegen helles Licht, z.B. ein Xenonblitz aus kurzer Entfernung oder ein grüner Laserpointer (Bild siehe hier). Normales Tageslicht reicht nicht, und mit Gehäuse ist das erst recht kein Problem mehr.

Der IC ist von Onsemi, beheimatet in den USA ... haben die denn den Ruf einer Billigklitsche? Bei einem µC kann man sowas natürlich nicht dem Hersteller anlasten, denn da ist man selbst für die Spannungsversorgung verantwortlich ... ;)

Grüße


Björn
Folgende Benutzer bedankten sich beim Autor BjoernS für den Beitrag (Insgesamt 3):
ReinholdKochFranzWolfgangH
844767 twtr d
Benutzeravatar

WolfgangH
Rank 11
Rank 11
Beiträge: 467
Registriert: So 3. Jan 2021, 21:42
Wohnort: Kirchham (A)
Hauptanschluß: 978310 whoe a

Re: Fehlermeldungen vom I-Telex

#26

Beitrag von WolfgangH »

BjoernS hat geschrieben: Fr 27. Mai 2022, 16:32 Betreibst du den ganz ohne SD-Karte? (Denn die sind eine beliebte Fehlerquelle für Abstürze, neben dem Netzteil.)

Aber krass, hängt der sich auf oder startet er einfach neu?
So ganz ohne SD-Karte geht es m.W. leider nicht, aber ich habe das System so konfiguriert, daß von der Karte nur das notwendigste gelesen wird. Geschrieben wird dann auf der Magnetplatte. Die Anleitung habe ich mir aus irgend einem Forum oder einem YT Video entnommen. Ich vergesse sowas immer.

Ja, die SD-Karten sind auch so ein leidiges Thema. Leider mußte ich da just mit Sandisk Mirco SD-Karten schlechte Erfahrungen sammeln. Ich hielt die immer für hochwertig, aber 3/3 Karten machen Probleme, egal ob in der Digitalkamera, im Raspberry, im Handy oder im Tablett. Leider merkt man das erst, wenn es schon zu spät ist.

Meine Erfahrung mit dem instabilen Raspberry ist, daß er dann komplett einfriert und auf gar nichts mehr reagiert. Nach dem Reset meckerte er immer, daß das Dateisystem auf der Karte kurrupt war. Nachvollziehbar aber lästig.

Angeblich gibt es zum Raspberry auch stabilere und qualitativ höherwertige Alternativen, die nur geringfügig teurer sind, ich habe mich damit allerdings nicht auseinander gesetzt.

Danke für die Links zum Raspberry 2 mit dem Xenon Blitz Problem. Vermutlich habe ich es damals im Video von Dave schon gesehen, aber auch längst wieder vergessen. :scratch:
Gruß
Wolfgang


Linz:
- 978310 whoe a - T100a
- 69558 kfrey d - T100s
- 978333 =whoe a - Minitelex
Kirchham: (Nachrichtenabruf an Wochenenden, Feiertagen, ...)
- 56449 sche d - T37i
- 11913 hoellw a - LO 3000 (100 Baud)
Benutzeravatar

BjoernS
Rank 8
Rank 8
Beiträge: 174
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Fehlermeldungen vom I-Telex

#27

Beitrag von BjoernS »

Moin Wolfgang!
WolfgangH hat geschrieben: Fr 27. Mai 2022, 21:15 Ja, die SD-Karten sind auch so ein leidiges Thema. Leider mußte ich da just mit Sandisk Mirco SD-Karten schlechte Erfahrungen sammeln. Ich hielt die immer für hochwertig, aber 3/3 Karten machen Probleme, egal ob in der Digitalkamera, im Raspberry, im Handy oder im Tablett. Leider merkt man das erst, wenn es schon zu spät ist.

Meine Erfahrung mit dem instabilen Raspberry ist, daß er dann komplett einfriert und auf gar nichts mehr reagiert. Nach dem Reset meckerte er immer, daß das Dateisystem auf der Karte kurrupt war. Nachvollziehbar aber lästig.
Ja, das Hauptproblem sind die ständigen Schreibzugriffe von GNU/Linux. Ist aber beängstigend, dass du da auch in Digitalkamera und Telefon Probleme mit Sandisk hast, das lief bei mir besser bisher :o

Wenn man beim Pi alle Logdaten etc. auf der Karte behalten will (mache ich auch), geben die Karten irgendwann auf, die sind ja nur für Anwendungen mit geringerer Schreibhäufigkeit gedacht. Wenn du sie dann neu aufsetzt kommt das Problem sicher wieder. Ich benutze da gerne Sandisk High Endurance, das sind Karten für Dauer-Videoaufzeichnungen.

Es gibt da auch Konstruktionen, dass man ein RAM-Dateisystem über die Karte legt, die Änderungen werden dann nur im RAM gehalten und man kann alle x Stunden wegspeichern. Habe ich aber noch nicht ausprobiert.

Grüße


Björn
Folgende Benutzer bedankten sich beim Autor BjoernS für den Beitrag:
WolfgangH
844767 twtr d
Benutzeravatar

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

Re: Fehlermeldungen vom I-Telex

#28

Beitrag von FredSonnenrein »

Hallo zusammen,

ein schöner großer Thread ist hier während meiens Urlaubs entstanden. Ich werde nun mal den einen und anderen Punkt aufgreifen und erklären:
Franz hat geschrieben: Mi 11. Mai 2022, 19:39 in der letzten Zeit, seit etwa Umstellung von DSL 50 Mbit auf 1Gbit/s Kabel (vor ca. 8 Wochen), häufen sich bei mir die I-Telex Fehlermeldungen. Ich kann nicht nachvollziehen wie oft und genau oder wann sie kommen.... Heute als ich mit Reinhold und Werner im Museum Heustenstamm ein paar Teste an mich nach Hause geschickt habe, kam NACH jedem Verbindungsaufbau, der gut und ok war, bei mir diese Fehlermeldung.
Mehrfache Fehler beim Senden ins Netz
Es war heute bei uns niemand sonst zu Hause, der Internet benutzt hat, also kann es an einer Überlastung der Leitung (100 Mbye /sec !!)) nicht gelegen haben.
So ganz grob vom Bauchgefühl vermute ich den Standard-Vodafone-Primitiv-Router, bei dem man im Menü sehr wenig einstellen kann.

Vielleicht hat jemand von Euch ähnliche Erfahrungen gemacht.

Besten Dank im Voraus .....
Dieser Fehler wird vom i-Telex gedruckt, wenn das "Betriebssystem" keine Daten mehr zur Übertragung an die Gegenstelle annimmt. Und zwar nicht beim ersten Fehler (der vielleicht wieder verschwindet), sondern erst beim 10. Auftreten (obwohl in den allermeisten Fällen keine Besserung eintritt).

Weitere Folge (außer des Druckens dieser Meldung) ist, dass die IP-Verbindung getrennt wird und daraufhin die anrufende Station einen Neuaufbau der IP-Verbindung versucht. Die gerufene Station wartet dazu nach ungewollter Trennung 30 Sekunden darauf, dass erneut eine IP-Verbindung vom ursprünglichen Anrufer eingeht. "Ungewollte Trennung" ist dadurch erkennbar, dass kein Ende-Telegramm (Code 0x03) empfangen oder gesendet wurde.

Schlägt dies auch fehl, wird die Verbindung endgültig getrennt.

Es kann also sein (bzw. in dem geschilderten Fall ist es so), dass die Verbindung getrennt wurde (muss nicht an Problemen des eigenen Anschlusses liegen, kann auch in der Gegenstelle begründet sein), und ein Wiederaufbau erfolgreich war.

Falls der Wiederaufbau der Verbindung nicht erfolgt, passiert folgendes: Bei Ablauf der 30 Sekunden Wartezeit wird die Fehlermeldung gedruckt
Zeitueberschreitung bei Wiederaufnahme der Verbindung
Diese Meldung "überschreibt" die erste Fehlermeldung, da Fehlermeldungen während einer bestehenden Verbindung nicht gedruckt werden.

Beide Fehlermeldungen haben übrigens die "Priorität" 2, d.h. sie werden überhaupt nur dann gedruckt, wenn der Anwender bei "Level für Druckausgabe von Meldungen" einen Wert von 2 oder größer eingetragen hat. Ansonsten werden die Meldungen vollständig unterdrückt.

...auf andere diskutierte Punkte werde ich separat antworten.

Viele Grüße,

Fred
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag (Insgesamt 3):
BjoernSFernschreiberWolfgangH
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 531075 (Creed75), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

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

Ende-Paket / Fehlermeldungen vom I-Telex

#29

Beitrag von FredSonnenrein »

Hallo zusammen,

und noch ein paar Erläuterungen zum Ende-Paket:

Ich hatte in der vorherigen Nachricht erläutert, dass das Ende-Datenpaket (0x03) die Aufgabe hat, störungsbedingte Trennungen der IP-Verbindung von gewollten Trennungen zu unterscheiden.

Der normale Ablauf ist:
A sendet das Ende-Paket
B empfängt dieses und trennt sofort die IP-Verbindung
A wartet maximal 5 Sekunden auf die Trennung von der Gegenstelle, trennt danach aber ggf. selbst.

Probleme gibt es dann, wenn A kein Ende-Paket sendet (weil B dann an eine störungsbedingte Trennung der IP-Verbindung 'glaubt'). B druckt dann ggf. das "Zeitueberschreitung bei Wiederaufnahme der Verbindung".

Dasselbe passiert ggf. auch, wenn A das Ende-Paket sendet, aber sofort auch die IP-Verbindung trennt. Aufgrund von Mängeln (?) im Betriebssystem kommt dann das Ende-Paket gar nicht mehr in der i-Telex-Anwendung an.

Wenn B mit einem Ende-Paket 'antwortet' dann ist dies dem i-Telex als Station A egal. Denn es kann ja auch sein, dass tatsächlich beide Stationen gleichzeitig einen absichtlichen Verbindungsabbau initiieren, dann "überkreuzen" sich die Ende-Telegramme auf dem Verbindungsweg.

Zur Formulierung
The receiving station should switch off the printer and should close of the TCP connection.
Da steht "sollte", weil es der Station freigestellt ist, noch irgendwelche "Nachlaufinformationen" auszudrucken.
Wenn die Station was anderes macht, wird die Funktion der aktiv trennenden Station nicht beeinträchtigt (da diese ggf. auch selbst die IP-Verbindung trennt).

Zur Formulierung
The station which receives this packet may immediately close the TCP connection.

DIes ist als "Erlaubnis" formuliert im Gegensatz zum "Muss" in
The sending station shall wait for the opposite station to close the TCP connection.
(Erklärung siese oben).
Tatsächlich ist das Senden irgendwelcher Informationen (z.B. eines Ende-'Echo') auf den Empfang des Ende-Telegramms freigestellt. Es ist nicht definiert, was mit diesen Daten auf der A-Seite passiert. Logischerweise wird es ignoriert werden, da A gerade seinen Fernschreiber abgeschaltet hat (nach wirksamen Bedienen der Schlusstaste kann der Fernschreiber in A nichts mehr drucken).

Meine Wahl von "shall", "should" und "may" ist also schon mit Bedacht gewählt.
BjoernS hat geschrieben: Di 24. Mai 2022, 21:54 And now for something completely different: "The sending station shall wait for the opposite station to close the TCP connection." :mentor: "shall" bedeutet soviel wie "must", aber das tut piTelex z.B. nicht. Wenn ich den Code richtig lese, aber auch i-Telex und WinTlx nicht. Da wird direkt die eigene Seite der Verbindung geschlossen.
Jein. Der Sender des Ende-Telegramms (im i-Telex) schließt die Verbindung nach einer angemessenen Wartezeit. Aber niemals sofort.

VIele Grüße,

Fred
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag (Insgesamt 4):
BjoernSdetlefFernschreiberWolfgangH
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 531075 (Creed75), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Antworten

Zurück zu „Technischer Support (nur i-Telex)“