Neuimplementierung von i-Telex

[damarco]

Dann schieße ich zurück, es gibt eine IEEE und die hat das Protokoll standardisiert. Wenn man sich daran nicht hält muss man sich auch nicht wundern wenn es nicht funktioniert.

Aber ernsthaft es mag sein das man mit einem AVR noch vieles in der Hand hat, aber mit einem OS eben nicht mehr. Dieser hält sich an dem Standard und zumindest unter Linux kann man Flags setzen das auch 1Byte sofort gesendet. werden, sonst wird es Fragmentiert. Also mit anderen Paketen zusammen gepackt. lwIP vom ESP32 hat auch wieder so seine Tücken...

Die Flusskontrolle ist eine ganz andere Baustelle und ich habe mir auch schon überlegt wie man das Problem löst.

[Fernschreiber]

Ich werde von Fred ja immer etwas schräg angeschriebenm aber in meinen Implementationen gilt :50 Baud auf der gesamten Strecke alse ein Baudotpaket in ein TCP Paket. Normalerweise Unsinn, aber in diesm Fall bringt es ja doxh nichts effektiv zu arbeiten, der Fluss muß im Mittel sowieso 50 /75 Baud bleiben, sonst droht Unsynchronität. Es macht schlicht keinen Sinn, den Kölner Dom mit Lichtgeschwindigkeit zu übertragen und den Client dann 45 Minuten drucken zu lassen, während der Server dann auf einen nächsten Meniepunkt wartet. Es soll auch Clientsysteme geben, die fast keinen Puffer bereitstellen können. Also: wer mit mir Kontakt aufnimmt, bekommt alles zeitnah in Tröpfchenform, auch von den Servern. Alles im Rahmen der Flußkontrolle, die je nach Puffer im Client die Geschwindigkeit des Senders von 50 Baud moderat erhöhen oder absenken kann (analoger Modus). Client ohne Flußkontrolle werden stumpf mit 50 Baud beliefert, auch wenn es dann eben mal hakelt.
Im Protokoll steht lediglich die maximale Payload (aktuell 50),seit 2016 (mein Einstieg) niemals eine minimale, warum auch. Das ist einer der vielen Punkte im Protokoll, die nach eigener Vorstellung implementiert werden können, es muß halt nur kompatibel bleiben.
Am Rande: meine Server senden grundsätzlich 2 WR, um defekten Dämpfern eine zweite Chance zu geben. Das gilt allerdings nicht für den Dienst Testtexte,denn der soll Fehler ja aufdecken.
Gruß
Willi

[detlef]

Dann schieße ich zurück, es gibt eine IEEE und die hat das Protokoll standardisiert. Wenn man sich daran nicht hält muss man sich auch nicht wundern wenn es nicht funktioniert.

Der IEEE-Standard wurde nicht für Fernschreiber gemacht. Wir verbinden hier keine IT-Systeme. Wir simulieren ein Fernschreibnetz so realistisch wie möglich.

Nachtrag: Du diskutierst nach wie vor über technische Standard und wie man dies und jenes lösen kann. In keinem deiner Beiträge finde ich das wieder, was die Anwender wollen. Zum Beispiel die verzögerungsfreie synchrone Kommunikation. Ich bin gespannt.

[damarco]

Doch doch lese mal weiter oben, ich habe das Argument mit auf die Liste genommen. Obwohl das nicht einfach zu lösen sein wird, aber ich halte das für machbar.

Den Frame immer 50 Byte groß zu machen sollte bei keinen System ein Problem darstellen denke ich. 50 Byte ist dieser ja nur physikalisch groß, durch das Telegramm im Header ist die spezifische Länge ja lesbar.

Ja eben genau das ist das Problem 4 Seiten Text sind in einen Paket drüben aber noch nicht ausgedruckt und die Verbindung muss gehalten werden weil ja niemand weis ob da noch was nachkommt. Also kann man auch die Zeichen einzeln Senden und mit 50 Baud sollte das auch mit einen AVR am anderen Ende kein Problem sein. Die Trafic müsst dieser auch verarbeiten können.... Es gibt im Telegramm auch kein BUSY Type womit der Empfänger laut STOP brüllen kann.

[M1ECY]

Have to admit, the technical elements of this discussion see me completely baffled.

84 posts so far, and as far as I can tell no actual mission statement.

When developing a project, surely it needs a defined set of requirements before jumping into development?

In the case of a replacement for the Ethernet card, or more correctly the beating heart of I-Telex, how does this design process work?

It is clear that the concept of the interface cards is proven and sound - each card working closely to the original technology of switching, yes,maybe not with relays and step by step switching, but the feel of the system here is right - this relies on one Atmel per extension, and is hot swappable, and simple to use.

With a different "Ethernet Card" is this functionality to be retained? the ability to hot swap interface cards without reboot?

Talking of reboot, the current system is basically instant - no waiting for thousands of lines of code to be ready, no delays while an operating system boots, and then begins to process the software needed to make the card and then system work?

Change is a good thing, but only when the change is to improve the current situation. As far as I can see, there is a lot of discussion over minute detail at present, but until the parameters for the end goal are set, all of this work is perhaps wasted? It feels to me that the current discussion is actually aimed at starting a project from the middle and then trying to work out a solution at each end?

I wish you good luck.

Sean

[FredSonnenrein]

Dann schieße ich zurück, es gibt eine IEEE und die hat das Protokoll standardisiert.

a) ich bin Hobbyist und habe Quick&Dirty programmiert. Funktioniert dennoch hinreichend gut.
b) welches Protokoll hat die IEEE standardisiert? i-Telex sicher nicht. TCP ja, weicht das i-Telex davon ab? Wenn ja, wo?

Wenn man sich daran nicht hält muss man sich auch nicht wundern wenn es nicht funktioniert.

Was funktioniert nicht?
Woran wurde sich nicht gehalten?
Es wäre schön wenn etwas mehr konkret angesprochen wird als nur "X ist besser als Y" thematisiert wird.

Aber ernsthaft es mag sein das man mit einem AVR noch vieles in der Hand hat, aber mit einem OS eben nicht mehr. Dieser hält sich an dem Standard und zumindest unter Linux kann man Flags setzen das auch 1Byte sofort gesendet. werden, sonst wird es Fragmentiert. Also mit anderen Paketen zusammen gepackt. lwIP vom ESP32 hat auch wieder so seine Tücken...

"Mit einem OS nicht mehr" schreibst du. Wir brauchen mehrere OS? Ja richtig: Eines für einfache, aber Hardwarenahe Funktioenen und ein flexibleres und leistungsfähiges für die Kommunikation über das Netz.

Die Flusskontrolle ist eine ganz andere Baustelle und ich habe mir auch schon überlegt wie man das Problem löst.

Her mit den Vorschlägen.

Viele Grüße, Fred

[FredSonnenrein]

Den Frame immer 50 Byte groß zu machen sollte bei keinen System ein Problem darstellen denke ich. 50 Byte ist dieser ja nur physikalisch groß, durch das Telegramm im Header ist die spezifische Länge ja lesbar.

Warum soll der Frame stets 50 Byte groß sein? Welche Vorteile bringt dies?
Wie bereits erwähnt: i-Telex soll möglichst syncchron zum Tippen auf Fernschreiber A die getippten Zeichen auf Fernschreiber B ausdrucken.
In seltenen Fällen ist Fernschreiber A durch ein "Dienst" ersetzt, welcher in nahezu beliebiger Geschwindigkeit Daten sedet, aber grundsätzlich auch mit dem Ziel der Ausgabe auf einem Fernschreiber.

[Fernschreiber]

Ich schließe mich Sean mal ein bischen an. Diese Diskussion ist noch weit entfernt von dem was mal werden soll. Hier wird gerade das i-telex Protokoll diskutiert wie es wohl alle Entwickler (Jochen, Detlef ich) mit Fred schon mal durchgekaut haben. Auch ich tat mich damit (2016- jetzt) etwas schwer (z.B das mickrige halbe Durchwahlbyte oder der irre Thread bzgl. des Namensfelds im Tln-Server und vieles mehr). Aber letzdenendes muß man feststellen, das Fred aus seiner damaligen Sicht ein stabil laufendes immer wieder im Rahmen der Möglichkeiten angepasstes (Hobby) System (siehe bzgl. der Stromspartechnik die schnelle Bereitstellung der Ports) entwickelt hat, welches in grösserer Stückzahl weltweit existiert. Aus diesem Grund kann eine Neuentwicklung einzelner Kartren (speziell Netzwerkkarte) nur derart erfolgen, das die Karte nach aussen vollkompatibel bleibt, mit allen Einschränkungen die da jetzt sind (z.B. Eth: nach innen I2c, nach aussen IPV4 ). Warum wird hier alles infrage gestellt? Das schließt nichr aus, das in einer neuen Karte mehr als eine Verbindung möglich sein kann oder IpV6 tauglichkeit schon mal implementiert wird. Aber am Protokoll selber kann sich nichts ändern. Wer jetzt darüber diskutiert wieviel Payload in ein TCP-Telegramm soll oder wie eine Flußsteuerung aussehen kann der sollte im Forum mal unter diesen Stichworten suchen. War alles schon mal da. Das Thema OS oder nicht sollte der Entwickler sebst festlegen. Jochens und auch meine Entwicklung (i-telex an mechanische Vst) basiert auf pi-Hardware. In beiden Fällen dürfte die Abarbeitungsgeschwindigkeit des i-telex Protokolles (bei Lochstreifenbetrieb max. 50/75 Baud = ca. 100-150 ms / Zeichen) kein Thema sein, auch die sinnvolle optimierung (verkleinern) der default TX/RX Buffer wirkt da optimierend. Im i-Telexprotokoll wird es kein neues Byte (Busy) geben schätze ich, diesen Zustand kann man sich aus den Acknowledge-Paketen errechnen. Diese sind nicht "mandatory", aber ich meine jeder hat sie bisher implementiert. Was soll den passieren wenn der Empfänger anscheinend nicht mehr drucken kann? Wo ist da der Fehler und was macht die sendende Netzwerkkarte mit dieser Info, geht ab jetzt alles in den Puffer für bessere Zeiten oder sollt man nach Timeout auslösen? Sowas obliegt dem Programmierer, und zwei von dreien werden es anders lösen. Mit dem Protokoll kann und muß man leben, da geht kein weg dran vorbei.
Sollte diese Neuimplementierung aber in die Richtung einer wirklichen weiteren I-Telex-Version mit erweiterten Funktionen gehen, kommt man aus Kompatibilitätsgründen dennoch nicht an dem jetzigen Zustand vorbei und sollte das in einem speziellen Thread führen,
Wer glaubt das eine logische Implementierung des Protokolls reicht, wird sich auf eine spannende Zeit einstellen müssen, denn die Freiräume in der ablauftechnischen Implementierung sind groß und sind unter den oben genannten Entwicklern im Detail bestimmt verschieden ausgelegt (z.B. Timeouts, Wiederholungen). Auch bei den Diensteentwicklungen haben sich immer mal wieder Verständnisprobleme gezeigt, wo jeder irgendwie Recht hatte aber das Interworking klappte nicht. Es gibt eine markante Aussage von Fred zu seinem System: man kann jedes Paket jerdezeit senden, der Empfänger entscheidet ob er es zu dem Zeitpunkt annimmt oder nicht, toleranter geht es wohl nicht.

Gruß
Willi

[detlef]

Wer glaubt das eine logische Implementierung des Protokolls reicht, wird sich auf eine spannende Zeit einstellen müssen, denn die Freiräume in der ablauftechnischen Implementierung sind groß und sind unter den oben genannten Entwicklern im Detail bestimmt verschieden ausgelegt (z.B. Timeouts, Wiederholungen). Auch bei den Diensteentwicklungen haben sich immer mal wieder Verständnisprobleme gezeigt, wo jeder irgendwie Recht hatte aber das Interworking klappte nicht.

Ja, das ist spannend bei den Diensten, wo eben auch alle möglichen Systeme anrufen. i-Telex und piTelex mit allen Versionen, die irgendwann mal veröffentlicht wurden. Auch die mit Fehlern, um die man dann zusätzlich zur Protokoll-Implementierung noch herumprogrammieren muss.

[damarco]

Hallo also ich muss ehrlich gestehen das ich zunächst keine mehr Lust hatte mir darüber Gedanken zu machen. Aber nun die ersten Ansätze sind vorhanden, ich kann eine Verbindung aufbauen und einen Text auf dem Schreiber ausgeben

Mein Ansatz war wir denken Historisch und wollen auch daran festhalten also definieren wir das auch in eine Art "Leitung". Man kann Leitungen anlegen und ganz altmodisch verwenden, alles ist ein Pointer auf eine interne Struktur der als Referenz fungiert.

Man kann mit einer Leitung wählen,angerufen werden oder Aufgängen -> alles weitere macht der interne Code. So die Idee, der knifflige Teil kommt noch. Ich habe das jetzt so gebaut mich passiv zu verhalten, also ich schicke eine Kommando beim Aufbau und warte ob was zurück kommt.

Gleich noch zwei dumme Fragen:

Wie viele Zeichen umfasst die Kennung? Weshalb will mein iTelex immer nur die Version 1 akzeptieren -> weil ASCII ausgeschaltet wurde? Wer macht beim END,REJECT die Socket zu? Ich kenne das zu das der Server den Socket schließt, außer bei MQTT da man kann bei Fehlern der Client den Socket zu machen.