Rundsenden funktioniert nicht immer

[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

[BjoernS]

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

[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.

[BjoernS]

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.

Grüße


Björn

[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

[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

[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

[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

[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

[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?