Frage zum Acknowledge

[detlef]

Ich bin gerade dabei, meine i-Telex-Routinen zu optimieren und brüte gerade über diesem Absatz aus der Protokollbeschreibung:

Note: Nomally the called i-Telex station prints out the current date and time after starting the local printer. To indicate that there is some data to print the first acknowledge data packet sent by the called station doesn't start with data byte of 0. But as soon as this locally generated text is completely printed the called station sends the acknowledge data packet with value 0 (so 06 01 00).
If the calling station started to transmitting data before the locally generated text was printed, the acknowledge packet with data byte 0 may be omitted.

Fred, kannst du das nochmal erklären? Ich verstehe es einfach nicht.

[FredSonnenrein]

Hallo Detlef,
Das i-Telex sendet im Acknowledge-Paket die Anzahl der gedruckten Zeichen.Zeichen ist als 5-Bit-Gruppen zu verstehen, ein Zeichen gilt bereits dann als "gedruckt", wenn das Startbit an der Schnittstelle anliegt.
Kodiert ist es etwas anders: Im Ack-Paket wird die Anzahl der Zeichen gesendet, die bisher von der Gegenstelle empfangen worden sind, abzüglich der Zeichen, die im "Verarbeitungspuffer" stehen. Das läuft "am Ende" auf das gleiche heraus.

Da aber das lokal gedruckte Datum (das wird ja nicht von der Gegenstelle erzeugt) auch in den genannten Verarbeitungspuffer geschrieben wird, ist die Zahl, die im Ack-Paket während des Druckens des lokalen Datums gesendet wird, theoretisch negativ.

Sobald das Datum fertig gedruckt ist, ist der Zähler der empfangenden Daten 0 und auch die Anzahl der Zeichen im Verarbeitungspuffer 0 und somit wird ein Ack-Paket mit dem Wert 0 geschickt.

Es ist aber nicht garantiert, dass dieses "Ack 0" Paket kommt, nämlich dann wenn die Gegenstelle bereits vorher irgendwas (z.B. WerDa) sendet.

Es ist garantiert, dass ein Ack-Paket gesendet wird, solbald der Verarbeitungspuffer leer ist.

Solange der Verarbeitungspuffer nicht leer ist, wird das Ack-Paket zeitgesteuert (alle 1 Sekunde etwa) gesendet.

Übrigens ist N_Buffer aus der Protokoll-Beschreibung nicht der genannte Verarbeitungspuffer, sondern der Puffer der vom lokalen Fernschreiber bereits gesendeten Zeichen, die aber noch nicht per Baudot-Data-Paket gesendet worden sind. Dieser Sendepuffer ist vorhanden, damit die TP-Pakete möglichst "ausgelastet" werden.

Grüße,

Fred

[detlef]

Da aber das lokal gedruckte Datum (das wird ja nicht von der Gegenstelle erzeugt) auch in den genannten Verarbeitungspuffer geschrieben wird, ist die Zahl, die im Ack-Paket während des Druckens des lokalen Datums gesendet wird, theoretisch negativ.

Was mich etwas verwirrt: Warum wird denn das lokal gedruckte Datum überhaupt bei Ack berücksichtigt? Das Datum wird lokal erzeugt und gehört ja eigentlich zu den gesendeten Daten. Andere gesendete Daten werden doch auch nicht bei Ack berücksichtigt, sondern nur empfangene Daten.

Wenn jetzt der angerufene Anschluss kein Datum und keine Kennung druckt aber stattdessen der Benutzer sofort mit dem Schreiben beginnen würde (was ja für den Anrufer den gleichen Effekt hat), dann würde das aber protokollmäßig anders aussehen. Diese Daten würden dann den Ack-Wert nicht einflussen, nehme ich an?

[FredSonnenrein]

Das Datum gehört sowohl zu den Daten, soweit richtig.

Damit es lokal gedruckt wird, muss es ja irgendwie auch an den lokalen Fernschreiber gesendet werden (der macht es ja nicht selbsttätig).

Weil dies im i-Telex einfach über den ohnehin vorhandenen Verarbeitungspuffer geschieht, wird quasi eine negative Zahl im Ack-Telegramm gesendet.

Das erfolgt nicht weil es notwendig ist, sondern weil es einfacher zu implementieren war (siehe vorherige Mail).

Anders ausgedrückt: an welcher Stelle würdest du den Zähler für das Ack-Telegramm bearbeiten?

[detlef]

Alles klar, wenn des eine Implementierungssache ist, dann verstehe ich das. Ich dachte es hätte vielleicht irgendeinen tieferen Hintergrund.

Danke für die Infos.

[Fernschreiber]

Auch ich bin damals über die ersten empfangenen Ack's mit "hohem bzw. negativen Wert" gestolpert. Das Protokol sagt ja nur zum Zweck und Einsatz (wenn überhaupt) etwas aus. Ich finde es etwas unglücklich, das diese "negativen" Werte gesendet werden obwohl die Gegenstelle noch nichts zu druckendes gesendet hat. Zudem ist die Implementierung eine clientinterne Sache ohne Aussenwirkung, Hauptsache der Zähler steht beim ersten Empfangszeichen auf "0" und zählt dann hoch. Ich zähle von Null an hoch sobald das erste empfangene zu druckende Zeichen in die Vermittlung zum FS geht. Dann kann ich das Datum auch einfach ausschalten ohne das zu berücksichtigen. Bei TW39 im Urstil gab es sowas zwischen Teilnehmern ja auch nicht. Es ist aber praktisch für den Gebrauch und darum lass ich es eingeschaltet. Innerhalb des i-Telex Systems ist das eigentlich kein Thema, da alles von Fred kommt und es funktioniert ja. Für Aussenentwickler sorgt es für Überraschung, also irgendwie damit umgehen und gut ist. Man kann es ja auch (negative Werte) auswerten und weiß definitiv das die Gegenseite "busy" ist (zumindest bei i-Telex Systemen).
Auch hier sollten sich mal Py-Entwickler melden und schreiben wie Sie es machen.
Gruß
Willi

[FredSonnenrein]

Einen tiefen Hintergrund außer "war für mich das einfachste" hat es nicht.

Andererseits ist es konsequent. Das Ack soll regelmäßig gesendet werden, sobald der Fernschreiber läuft.

Und ein Ack mit dem Zählerstand der der Anzahl der von der Gegenstelle gesendeten Zeichen entspricht, soll erst dann gesendet werden, wenn der Fernschreiber im Prinzip mit dem Drucken fertig ist. Was sollte also direkt nach dem Anlauf gesendet werden? Ack mit 0 wäre m.E. auch nicht ganz "richtig". Es würde im Prinzip keinen Unterschied machen.

Mit der Ack-Geschichte wollte ich sicherstellen, dass der Sender prüfen kann, ob ein nächstes Zeichen (z.B. ein Werda) sofort beim Empfang auf der Gegenseite wirkt (um z.B. ein Timeout für eine WIederholung des WerDa zu starten). Bereits bei dieser Situation würde ein Ack mit 0 gleich zu beginn der Verbindung dazu führen können, dass das Datum als Antwort auf das Werda missinterpretiert werden könnte.

[detlef]

WinTlx hat sich an dem "negativen" Ack-Wert zum Glück nicht gestört. Der negative Wert wurde einfach als sehr hoher Wert interpretiert und daher wurde einfach nichts gesendet. Solange bis dann per Ack ein Puffer-Stand von 0 signalisiert wurde.

Von daher finde ich das durchaus pragmatisch, also zumindest sollte es nicht stören.

[Fernschreiber]

Ich habe mich an den "negativen" Ack's auch nicht gestört, sind nur beim Tracen aufgefallen bei der Suche nach dem sogenannten "Startzeichen" , welches den Beginn der Baudotübertragung signalisiert. Damals konnte Fred ad hoc dazu auch nichts sagen bis Ihm das mit dem internen Druck einfiel. Alles war geklärt und gut, obwohl ich den Hintergrund damals nicht wirklich verstand. Mit seinem letzten Beitrag rundet sich das allerdings ab. Will der Anrufer die Kennung abfragen, was früher die Vermittlung in der Mitte gemacht hat, braucht er schnellstmöglich einen Synchronpunkt um das nicht zu schnell zu machen um dann das Datum als Kennung zu werten. Andererseits kommt das Datum ja auch zügig zum Anrufer, das könnte man ja abwarten. Ich hätte diese gesamte Einleitungsprozedur an den Standort des Anrufers gelegt, dann wäre alles immer synchron. Aber es ist so wie es ist und gut.
@ Fred:
Allerdings stellt sich mir eine neue Frage. Fred schrieb: (um z.B. ein Timeout für eine WIederholung des WerDa zu starten).
Eine Verzögerung der KG-Abfrage kann ich ja jetzt verstehen, aber eine Wiederholung???
Nächste Überlegung: nach welchem Kriterium geschieht eine KG-Abfrage eigentlich. Es ist auf dem Papier schlichtweg nicht zu erkennen ob dies manuell oder maschinell erfolgt ist. Bei ED1000 Anschlüssen als Anrufer wäre das historisch richtig, bei TW39 mit Tastaturwahl diskutabel und bei TW39 mit Impulswahl dürfte keine Abfrage erfolgen.
Drittens: Zuschreiben von Datum/Zeit:
In TW39 Urtechnik nicht realisiert
Historisch konnte jeder Teilnehmer im EDS entscheiden, ob er das Datum bei ankommenden/ und oder abgehenden Verbindungen zugeschrieben haben möchte. Für eine Vermittlung ein leichtes, wie ist das im i-Telex realisiert? Ich weiß das es je Port ein/ausschaltbar ist. Was passiert wenn der Anrufer es aktiviert hat, der Angerufene aber nicht. Erscheint es trotzdem bei beiden auf dem Papier?
Letztendlich: Versuchst Du im i-Telex via Ethernet das unvermeidliche Endstellen-Halduplex auf der Vollduplexstrecke irgendwie zu sortieren, sprich wenn eine Seite beginnt zu schreiben, das (durch Laufzeit) noch unverstümmelte Gegenschreiben abzufangen und jeweils in einen Puffer zu legen um es in einer Pause dann zuzustellen?

Gruß
Willi

[FredSonnenrein]

Hallo Willi und alle anderen,

Ich hätte diese gesamte Einleitungsprozedur an den Standort des Anrufers gelegt, dann wäre alles immer synchron. Aber es ist so wie es ist und gut.

Der Anrufer weiß doch wie spät es ist. Die Uhrzeit des Angerufenen ist interessant, da dieser abwesend ist und in einer anderen Zeitzone sein könnte.

Fred schrieb: (um z.B. ein Timeout für eine WIederholung des WerDa zu starten).
Eine Verzögerung der KG-Abfrage kann ich ja jetzt verstehen, aber eine Wiederholung???

Wenn keine Antwort auf das Werda kommt, sendet der Mensch nach einer kurzen Wartezeit nochmal ein Werda. Es könnte ja auf dem Übertragungsweg eine Verstümmelung gegeben haben oder die Maschine der Gegenstelle "klemmt".
So macht es auch die Automatik bei der Tastaturwahl.

Nächste Überlegung: nach welchem Kriterium geschieht eine KG-Abfrage eigentlich. Es ist auf dem Papier schlichtweg nicht zu erkennen ob dies manuell oder maschinell erfolgt ist.

Im "Original" erfolgt die Kennungsabfrage ja durch die Vermittlung.
Hintergrund dabei ist, dass bei dem Anrufer die Maschine ja schon läuft, sonst wäre das Eintasten der Nummer nicht möglich. Andererseits hätte der Anrufer ohne die KG-Antwort kein Indiz dafür, dass die Verbindung fertiggestellt ist. Dabei ist zu beachten, dass die ED1000 Schnittstelle älter ist als die Ethernet-Karte und schon bei der Modem-Verbindung (altes "TxP2") funktionierte. DIe Modem-Karte (Analog-Leitungskarte) hatte keine Uhr und konnte somit auch keine Uhrzeit drucken.
Außerdem ist die Uhrzeit-Ausgabe ja ausschaltbar.
Anstelle des automatischen WerDa hätte natürlich auch lokal ein anderes Indiz verwendet werden können, z.B. der Abdruck von "CONNECTED" oder so. Aber das WerDa war halt historisch korrekt.

Bei ED1000 Anschlüssen als Anrufer wäre das historisch richtig, bei TW39 mit Tastaturwahl diskutabel und bei TW39 mit Impulswahl dürfte keine Abfrage erfolgen.

WIe bereits geschrieben, bei Tastaturwahl eine Art "Notwendigkeit". Dabei ist ED1000 zwar in Deutschland immer mit Tastaturwahl verwendet worden, die Geräte (auch das AGT) konnten aber auch Impulswahl übertragen. Demnächst gibt es eine neue ED1000-FIrmware, die auch Impulswahl (Wählscheibe) kann.

Drittens: Zuschreiben von Datum/Zeit:
In TW39 Urtechnik nicht realisiert

RIchtig. Da aber die Uhrzeit wie oben geschrieben vom Angerufenen kommt, weiß diese Station nicht ob der Anrufer ein ED1000 hat oder nicht. Außerdem ist die Uhrzeit ein nettes Feature, warum sollte man es den Wählscheiben-Liebhabern vorenthalten?

Historisch konnte jeder Teilnehmer im EDS entscheiden, ob er das Datum bei ankommenden/ und oder abgehenden Verbindungen zugeschrieben haben möchte. Für eine Vermittlung ein leichtes, wie ist das im i-Telex realisiert?

Es ist je Ethernet-Karte einstellbar, ob die Uhrzeit gar nicht, nur lokal, nur beim Anrufer oder (default) bei beiden gedruckt werden soll.
Dies wirkt aber nur auf die ankommenden Verbindungen. Bei abgehenden Verbindungen entscheidet die Gegenstelle (logischerweise).

Ich weiß das es je Port ein/ausschaltbar ist. Was passiert wenn der Anrufer es aktiviert hat, der Angerufene aber nicht. Erscheint es trotzdem bei beiden auf dem Papier?

Dann bei keinem der beiden. Dieses Verhalten ist diskussionswürdig, da aber das Datum mit normalen Baudot-i-Telex-Telegrammen übertragen wird, kann der Anrufer es nicht beeinflussen.

Letztendlich: Versuchst Du im i-Telex via Ethernet das unvermeidliche Endstellen-Halduplex auf der Vollduplexstrecke irgendwie zu sortieren, sprich wenn eine Seite beginnt zu schreiben, das (durch Laufzeit) noch unverstümmelte Gegenschreiben abzufangen und jeweils in einen Puffer zu legen um es in einer Pause dann zuzustellen?

Ja, gepuffert wird immer auf der Empfängerseite. Es werden kommende Baudot-Daten in einen Puffer geschrieben (der in meinen ersten Beiträgen erwähnte "Verarbeitungspuffer"), dessen Inhalt wird aber nur dann an den eigenen Fernschreiber gesendet, wenn von diesem gerade nicht geschrieben wird.
Es könnte somit passieren, dass beide Seiten "wild" schreiben, die "Gegenantwort" wird stets erst dann gedruckt, wenn man selbst aufhört. Wobei schon Tipp-Pausen unter einer halben Sekunde als Schreibpause angesehen werden (genaue Zahlen müsste ich nachschauen).

Viele Grüße,

Fred