Rundsenden funktioniert nicht immer

todo
Benutzeravatar

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

Re: Rundsenden funktioniert nicht immer

#31

Beitrag: # 26853Beitrag FredSonnenrein »

Das könnte daran liegen, dass Finn über den "Centralex" Server angebunden ist.

Was also du (Reinhold) schreibst, geht erst mal an den Rundschreiben-Server, dann von dort an den Centralex-Server und von dort dann zu Finn.

Viele Grüße,

Fred
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag:
ReinholdKoch
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: Rundsenden funktioniert nicht immer

#32

Beitrag: # 28970Beitrag BjoernS »

FredSonnenrein hat geschrieben: Fr 30. Jul 2021, 16:05
WolfgangH hat geschrieben: Fr 30. Jul 2021, 15:11 bei Pi-Telex kommt dann anstatt der Kennung immer das Datum und am Ende der Übertragung meckert er, daß die Kennung nicht übereinstimmt. Die Nachrichten kommen aber an, also eher ein kosmetisches Problem.
Paul ist hier nicht mehr aktiv?
Dann ist wohl das Pi-Telex irgendwo nicht kompatibel.
Paul ist als Schüler/Student immer mal sporadisch hier.
Für mich klingt das wie eine Variation von Hyrum's Law: Über die bestehende i-Telex-Protokollspezifikation hinaus werden alle beobachtbaren Verhaltensweisen der "klassischen" i-Telex-Hardware implizit Bestandteil des Protokolls, weil es immer einen Dienst gibt, der auf ein nicht explizit festgeschriebenes Implementierungsdetail vertraut. Ohne das als Vorwurf zu meinen, das macht es "Drittanbietern" leider etwas schwerer. :( (der sog. Bundespost-Faktor ;))

Konkret auf diesen Fall bezogen: Leider liegt das Verfahren, wie die Kennung ermittelt wird, nicht offen, deshalb konnte ich bisher nur orakeln und innerhalb der offiziellen Protokollspezifikation ausprobieren. (Weiteres Beispiel: Der Rundsendedienst ist recht "bestimmt" in seinem Sendeverhalten bzgl. WerDa; ohne lokale "Sperrmaßnahmen" laufen das Datumsbanner aus dem piTelex-Kern und die Antwort des angeschlossenen Fernschreibers ineinander. Wenn ich das damals richtig verstanden habe, umschifft die i-Telex-Ethernetkarte das inhärent, da sie nur Singletasking kann.)

Ich bin aber an einer Lösung interessiert, wie auch schon bei Problemen mit piTelex und anderen Diensten! :) Wenn es eine Spezifikation gibt über die Erwartungen des Dienstes bei einem Anruf, kann ich das in piTelex entsprechend anpassen. Überlegen kann man dann auch, es vielleicht Bestandteil der offiziellen Spec zu machen. Das würde für alle klare Verhältnisse schaffen.

Grüße


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

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

Re: Rundsenden funktioniert nicht immer

#33

Beitrag: # 28972Beitrag WolfgangH »

Hallo Björn,

ich habe zwar beruflich regelmäßig mit Software-Programmierern zu tun, leider ist mir deren Sprache immer noch nicht verständlich. Da geht es mir auch beim Gesetz vom Herrn Hyrum so. Bitte daher um Nachsicht, wenn ich da etwas falsch verstanden habe, aber ich sehe das anders.

Aus meiner Sicht besteht das Problem zwischen Pi-Telex und Rundsendedienst oder an einem der beiden. Das i-Telex ist da aus meiner Sicht gar nicht involviert.

Mein Verständnis vom Ablauf:
1. Teilnehmer (TN) ruft Rundsendedienst(RSD) 11150 an (i-Telex oder Pi-Telex ist egal)
2. RSD meldet sich mit Abfrage der Kennung und anschließender Eingabeaufforderung an TN
3. TN gibt die anzuwählenden Empfänger (E) ein
4. RSD wählt E an und fragt die Kennungen zwecks Verifizierung ab
5. RSD meldet Status der aufgebauten Verbindung an TN und fordert zum Übermitteln des Textes auf (Ende mit +++)
6. Nach erfolgter Übermittlung werden nochmals die Kennungen der E abgefragt und Verbindung zu den E beendet
7. RSD sendet ein Protokoll an den TN und beendet ebenfalls die Verbindung

Ich vermute hier das Problem in Schritt 4.
Gruß
Wolfgang


Linz:
978310 whoe a - T100a ** 69558 kfrey d - T100s ** 21800 winter a - T38a ** 978333 =whoe a - Minitelex

Kirchham: (Nachrichtenabruf an Wochenenden, Feiertagen, ...)
56449 sche d - T37i ** 11913 hoellw a - LO 3000 (100 Baud) ** 244656 kirchh a - T68d
Benutzeravatar

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

Re: Rundsenden funktioniert nicht immer

#34

Beitrag: # 28977Beitrag BjoernS »

WolfgangH hat geschrieben: Mi 19. Jan 2022, 21:03 Aus meiner Sicht besteht das Problem zwischen Pi-Telex und Rundsendedienst oder an einem der beiden. Das i-Telex ist da aus meiner Sicht gar nicht involviert.
Mit ging es nicht darum, das Problem jemandem anzupinnen, sondern nur zu verdeutlichen, dass das Problem systemimmanent ist. Eine Spec vollständig und ohne Interpretationsspielraum zu schreiben ist nahezu unmöglich. Der "typische" Dienstentwickler testet dann beispielsweise gegen die zurzeit einzige Implementierung, und da die von ihm gewählten Testfälle funktionieren, macht er einen Haken dran. Eine andere, neue Implementierung erfüllt die Spec auch, füllt aber die darin enthaltenen "Freiräume" anders. Wenn dann der Dienst auf ein Detail innerhalb der Freiräume vertraut, ob absichtlich oder unabsichtlich, kracht's unter Umständen.

Anschauliches Beispiel:
  • Ein Dienst sendet WerDa und direkt im Anschluss weitere Daten, in den KG-Ablauf des Gegenüber hinein.
  • Die Spec sagt nichts über Gegenschreiben (wenngleich es beim "haushaltsüblichen" Vorbild zu Buchstabensalat führte)
  • i-Telex hat damit kein Problem, da aufgrund der Programmarchitektur (Implementierungsdetail) die Empfangsdaten aus Richtung Internet gesperrt sind, solange gesendet wird. (Wenn ich mich richtig erinnere :))
  • piTelex hat keine derartige Sperre und produziert "vorbildgetreu" Buchstabensalat.
Deswegen sagt Hyrum's law im übertragenen Sinne: Wenn dein System nur genug Nutzer hat, gibt es irgendwann für jede beobachtbare Verhaltensweise deiner Implementierung jemanden, der sich darauf verlässt, dass sie sich genau so verhält und nicht anders. Selbst wenn (oder gerade wenn) die zugehörige Spezifikation den Punkt offen lässt.

Dann einem der Beteiligten den Fehler in die Schuhe zu schieben ist m.E. nicht fair. Zusammenarbeit ist gefragt. :hehe:

Grüße :nacht:


Björn
Folgende Benutzer bedankten sich beim Autor BjoernS für den Beitrag (Insgesamt 3):
detlefWolfgangHobrecht
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: Rundsenden funktioniert nicht immer

#35

Beitrag: # 28979Beitrag Fernschreiber »

Hallo Wolfgang, hallo Björn, hallo auch alle anderen,

da ich den existierenden Rundsendedienst leider nicht nutzen kann,(Anwahl bleibt hängen, Rundschreiben kommen aber an) und Volker auch schon über eine Überarbeiting angefragt hatte, habe ich aus meinen Sourcen des Lochstreifenrecorders ein eigenes Produkt erstellt. Die Bedienung entspricht exakt den rosa Seiten des Telexbuches 87/88. Der Text wird (wie im Recorder) binär gespeichert sodaß auch Baudotarts oder komplexe Testtexte versendet werden können. Auch ich musste mich mit dem Problem eines Anrufdienstes auseinandersetzen, da nicht feststeht, was genau und wann passiert. Es kann halt das Datum/Zeit kommen oder auch nicht oder auch Gegenschreiben weil jemand die Anfangspause nicht versteht.
Ich habe bei der Verteilung eine Lösung gefunden, die (nach Erkennen des Kriteriums FS Läuft) prinzipiell erstmal 10 s wartet ob etwas einläuft. Kommt in dieser Zeit nichts, wird der KG abgefragt, der Rest ist dann relativ einfach. Kommt etwas in der Wartezeit,wird versucht das Datum/Zeit zu erkennen, danach Abfrage des KG, kommt irgend etwas nicht identifizierbares, muß halt gewartet werden bis das Gegenschreiben endet, vorher macht ein Werda kein Sinn oder Auslösung. In der EDS Zeit war das ja genauso, Datum/Uhrzeit waren zu- oder abbuchbar. Das Gegenschreiben hat die Rundschreibeeinrichtung generell als Grund für einen Abbruch gesehen, beim Auftraggeber wie später dann bei den Zustellungen.
Ich hoffe in ein paar Tagen mal eine Testversion freizugeben, kämpfe momentan noch mit der quasiparallelen Verteilung und dem darausfolgenden Ergebnisjournal.
Zur Klarstellung: Die damalige Rundsendeeinrichtung (und auch meine Version) hat nach erfolgreicher Übernahme der Nummern und des Textes (möglichst vom Lochstreifen aus Zeit und Timeoutgründen) die Zielnummern offline angewählt und nach Erledigung einen Rückruf an den Auftraggeber gemacht um die pos/neg-Meldung abzusetzten. Das hatte den Vorteil, das der Auftraggeber gebührenmässig günstiger davonkam, er während der Zustellung wieder erreichbar war und sich selbst zur Kontrolle auf den Verteiler setzten konnte.

Mal sehen wie das dann so läuft.

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

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

Re: Rundsenden funktioniert nicht immer

#36

Beitrag: # 28980Beitrag Fernschreiber »

Hallo Björn,
da warst Du gerade schneller wie ich. Ich teile Deine Einschätzung ganz und denke, wir haben alle als Entwickler bisher ganz gut performed und Fred stellt halt den historisch gewachsenen Kern mit einer Vielzahl von existierenden Systemen dar. Da muß man sich um des Gelingen Willens halt letztendlich anpassen. Was es zu vermeiden gilt ist das sich eine technische Parallelwelt entwickelt.
Übrigens macht auch meine Software Buchstabensalat bei Gegenschreiben. Ich halte den Informationsfluß so einfach wie möglich (wie früher). Beim i-Telex frage ich mich daher gerade, ob dann noch das gewollte zeitgleiche Gegenschreiben zwecks Unterrichtung der Gegenstelle über Probleme möglich ist.
Gruß
Willi
Folgende Benutzer bedankten sich beim Autor Fernschreiber für den Beitrag (Insgesamt 2):
BjoernSobrecht
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

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

Re: Rundsenden funktioniert nicht immer

#37

Beitrag: # 28984Beitrag FredSonnenrein »

Hallo zusammen,

1. Gegenschreiben
Ja, das i-Telex (genauer: Die Ethernet-Karte) sendet keine Daten an den lokalen Fernschreiber, solange von diesem Daten empfangen werden (also lokal geschrieben wird). Allerdings wird ein gepuffertes Zeichen sofort nach dem empfangenen Stopbit gesendet. Gegenschreiben ist also möglich.

2. Timing
Wenn das i-Telex auf "Datum drucken" konfiguriert wird, dann wird sofort nach Anlauf des eigenen Fernschreibers das Datum an den lokalen Fs und/oder an den Anrufer geschickt. Da der Fs beim Anrufer aber möglicherweise gerade erst anläuft, sind am Anfang des Datenblocks mit dem Datum 5 Bu-Umschaltungen enthalten. Die genügen meistens, um die Anlaufphase zu "überbrücken".
Das piTelex macht es anders: Es sendet zunächst eine "Einschaltquittung" an den Anrufer und dann nach ein bis zwei Sekunden das Datum.
Und dieser Unterschied ist vermutlich das Problem beim Rundsendedienst. Dieser sendet das "WerDa" wohl dann zum ungünstigen Zeitpunkt.

3. Verwendung von WerDa
Generell halte ich es für einen schlechten Stil, dass eine angerufene Station ein WerDa aussendet. Beim "normalen" Telexen macht dies nur der Anrufer. Willis Lösung ist auf jeden Fall korrekt, wobei die 10 Sekunden eine m.E. zu lange Zeit sind. Psychologisch erwartet der Mensch nach 2 Sekunden eine Antwort auf einen abgegebenen Reiz. Ähnliche Intervalle setze ich bei meinen Entwickungen an. Da die 10 Sekunden von Willis Implementierung für die Verbindung vom Rundsendedienst zum Empfänger gelten, sind sie aber unkritisch, da der Angerufene meist gar nicht am Fernschreiber ist und falls doch sowieso in der Rolle des Abwartenden ist.

Viele Grüße,

Fred
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag (Insgesamt 5):
FernschreiberBjoernSWolfgangH380170JFKobrecht
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

TEHA
Rank 6
Rank 6
Beiträge: 568
Registriert: Mo 26. Apr 2021, 19:12
Wohnort: Unterfranken
Hauptanschluß: 97486 thkbg d

Re: Rundsenden funktioniert nicht immer

#38

Beitrag: # 29328Beitrag TEHA »

Ich habe zwar schonmal nach diesem Fehler gefragt viewtopic.php?p=26789#p26789 , aber vielleicht weiß inzwischen jemand, woran das liegt?
Kommt bei mir jedesmal nach einer Rundsendung.
Der Fernschreiber bricht auf einmal die Teilnehmerbestätigung ab und schreibt diese Fehlermeldung. :?

Noch eine Frage:
Was bedetet das (=) bzw. das (x) bei den bestätigten Teilnehmernummern?

Rundsenden-Meldung.jpg
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Grüße von Thomas

97486 thkbg d - Lo15c (Hauptanschluß 24/7 online)
631276 ziabg d - Lo15b
622155a semi d - Lo15a
97205 thufr d - T37h
663727 kretz d - T100
643517 hys d - T68d
(Streifenschreiber - bitte nur Kurznachrichten!)
Lorenz Lo15b (Schmaltastatur)
Siemens T68f
Benutzeravatar

Franz
Rank 12
Rank 12
Beiträge: 3103
Registriert: Do 18. Mai 2017, 15:15
Wohnort: Dreieich
Hauptanschluß: 411898 bfsz d

Re: Rundsenden funktioniert nicht immer

#39

Beitrag: # 29329Beitrag Franz »

Hallo Thomas, solche "Quittungen" bekomme ich auch regelmäßig beim Rundsenden.
Soweit ich weiß bedeutet das (x), dass sich unter der angerufenen Nr. ein anderer KG gemeldet hat als erwartet, und (=) dass der erwartete KG sich gemeldet hat (Nicht 100% sicher) ....
Aber wie schon mal erwähnt, die Quittungsausgabe ist unzuverlässig, wichtig für den Empfang der Rundsendung ist die Ausgabe am Anfang, zu welchen Stationen eine Verbindung aufgebaut wurde, und/oder welche occ oder nc ist......
VG
Franz
411898 bfsz d + T100 (Schmaltastatur :thumbsup: )
411744 eddd d + T100 (Schmaltastatur :thumbsup: )
886747z bmwi d + T100Z (Schmaltastatur :thumbsup: ) )
4189939 eddz d + T100S (Volltastatur :/ )
Alle erreichbar von 06.00 - 22.00 Uhr lokal
Benutzeravatar

obrecht
Rank 6
Rank 6
Beiträge: 503
Registriert: Fr 26. Jun 2020, 18:53
Wohnort: Aachen
Hauptanschluß: 833539 fili d

Re: Rundsenden funktioniert nicht immer

#40

Beitrag: # 29331Beitrag obrecht »

ah, das beruhigt mich ein bisschen. Ich benutze ja pitelex und habe denselben Effekt, den Fehler hatte ich offensichtlich zu Unrecht bei pitelex vermutet. Einziger Unterschied: ich bekomme nicht diese "interne Meldung", die Verbindung bleibt "hängen", und ich muss sie per ST beenden.

Was das x und das = angeht, müsste ja bei 844767 auch ein = stehen, da KG und Rufnr passen, oder hab ich da was falsch verstanden?
Viele Grüße,
Rolf

833538 obrac d  24/7  (FS220)
833539 fili d   24/7  (T100a)
833540 rowo d   24/7  (T100/R) 
71920 actelex d 24/7  (T68d)
833541 obby d   24/7  (T37h)
833142 rolf d   24/7  (Lo15A) (pi-telex ist endlich fertig!)
Antworten

Zurück zu „Dienste“