Neuimplementierung von i-Telex

damarco · #71

Danke, ich hatte das schon mal in der Hand vor ein paar Monaten und dann habe ich doch wieder in den svn gesucht.

Für den Teilnehmerserver benötige ich das ja auch wenn ich die Nummer auflösen möchte..

#72

Ist ja beschrieben, dass das auflösen der Nummer auch ohne Geheimzahl geht

damarco · #73

08 Loopback test 1 random payload 2 to 254
09 Remote config 1 PIN + sub command + config data 3 to 254

Da hat sich der Fehler wieder eingeschlichen. Wenn der Header 2 Byte lang ist kann die Payload nur 253 Byte groß sein. Sonst läuft die Variable Länge die 1 Byte groß ist über... Besser wäre es gewesen damals die Länge gleich 2 Byte Platz zu geben so wäre die ganze MTU nutzbar. Aber ich denke man hat sich gedacht wegen dem wenigen Speicher im AVR braucht man so große Telegramme nie....

#74

damarco hat geschrieben: ↑Sa 23. Mär 2024, 16:35 Besser wäre es gewesen damals die Länge gleich 2 Byte Platz zu geben so wäre die ganze MTU nutzbar. Aber ich denke man hat sich gedacht wegen dem wenigen Speicher im AVR braucht man so große Telegramme nie....

Nicht nur nicht brauchen. Wegen dem beschränkten Speicher vieler Microcontroller darf man gar keine größeren Pakete verschicken. Woher sollen kleinere Controller sonst den Platz für den Pufferspeicher nehmen. Wobei man kleine Systeme auch platt bekommt, wenn man viele Pakete in einen Frame packt. Ist das eigentlich in den Specs reglementiert? Ideal fände ich, wenn nur ein i-Telex-Packet pro Ethernet-Frame erlaubt wäre.

Wenn du einem Fernschreiber 2000 1500 Zeichen schickst, dann braucht der 4 Minuten, um die auszudrucken. Da ist dann nichts mehr synchron - das ist dann der piTelex-Effekt. Ausserdem kann der Acknowlege mit solchen Datenmengen auch nicht umgehen.

Also in solchen Größenordnungen würde ich erst gar nicht denken. Es hilft nix, an jedem zweiten Absatz anzumerken, was man (vielleicht) hätte besser machen können (oder einfach nur anders). Das i-Telex-Protokoll ist halt wie es ist und es funktioniert.

#75

Hallo Marco,

irgendwie habe ich noch ein Verständnisproblem, bitte entschuldige dass die Antwort so lange gedauert hat.

damarco hat geschrieben: ↑Sa 23. Mär 2024, 16:35 08 Loopback test 1 random payload 2 to 254
09 Remote config 1 PIN + sub command + config data 3 to 254

Da hat sich der Fehler wieder eingeschlichen. Wenn der Header 2 Byte lang ist kann die Payload nur 253 Byte groß sein. Sonst läuft die Variable Länge die 1 Byte groß ist über...

Das verstehe ich nicht. Beispiel payload hat (theoretisch) 254 Byte Länge im "Loopback" test (was völlig nutzlos wäre, aber egal).

Dann wäre der Telegramminhalt irgendwas mit (hex)
08 FE xx xx ... xx xx

damarco hat geschrieben: ↑Sa 23. Mär 2024, 16:35 Besser wäre es gewesen damals die Länge gleich 2 Byte Platz zu geben so wäre die ganze MTU nutzbar. Aber ich denke man hat sich gedacht wegen dem wenigen Speicher im AVR braucht man so große Telegramme nie....

MTU? Motoren und Turbinen Union?

#76

detlef hat geschrieben: ↑Sa 23. Mär 2024, 19:26 Wenn du einem Fernschreiber 2000 Zeichen schickst, dann braucht der 5 Minuten, um die auszudrucken. Da ist dann nichts mehr synchron - das ist dann der piTelex-Effekt.

Wieso ist das der "piTelex - Effekt"?
Braucht ein Fernschreiber am i-telex kürzer oder länger?
50Bd sind doch 50Bd, oder?

damarco · #77

Die Angabe der Länge bezieht sich auf die Länge der Payload korrekt und nicht wie ich dachte auf die Länge des Telegramms?

MTU - Maximum Transfer Unit ist beim Ethernet üblicherweise 1500 Byte groß, die Payload ist durch IP Header, TCP/IP Header aber geringer.

https://www.elektronik-kompendium.de/si ... 812211.htm

@detlef daher https://de.wikipedia.org/wiki/TCP_Receive_Window es geht gar nicht darum es besser zu machen sondern es zu verstehen weshalb es nun mal so ist.

Deswegen sagte ich auch im W5500 muss man sich nicht darum kümmern, da der IP Stack das macht. Man müsste schauen ob im verwendeten IP-Stack die Fenstergröße eine Rolle spielt.

#78

damarco hat geschrieben: ↑Sa 23. Mär 2024, 21:09 Die Angabe der Länge bezieht sich auf die Länge der Payload korrekt? Die Länge ist im Header 1 Byte groß und wenn der Header 2 Byte groß ist ( 1 Byte command_type + 1 Byte Länge ) kann die Länge der Payload nicht 254 Byte sein. Dann wäre das ganze Telegramm 256 Byte lang -> Überlauf unsigniert char.

Verstehe ich auch gerade nicht. Warum darf das ganze Paket (Telegramm) nicht 256 Byte lang sein? Welcher unsigned char läuft da über?

damarco · #79

Habe nochmal nachgedacht siehe oben. Ich dachte die Länge bezieht sich auf das gesamte Telegramm. Header(2 Byte) + Daten(254 Byte) das passt dann nicht mehr in ein unsigniert char. Aber die Länge bezieht sich auf die Länge der Daten und die können dann maximal 255 Byte groß sein.

Also alles korrekt! Bitte keine Aufregung

@obrecht detlef seine Forderung war Buffer zu vermeiden, es soll so sein das wenn er eine Taste drückt diese auch unmittelbar übertragen wird.

#80

Hallo Marco,

damarco hat geschrieben: ↑Sa 23. Mär 2024, 21:09 Die Angabe der Länge bezieht sich auf die Länge der Payload korrekt und nicht wie ich dachte auf die Länge des Telegramms?

Ich fände es unlogisch, in der Aussgage "bitte 1 Byte drucken" (und das ist in 95% der Situationen der Fall) die Zahl 1 in Form einer 3 zu codieren.

damarco hat geschrieben: ↑Sa 23. Mär 2024, 21:09 @detlef daher https://de.wikipedia.org/wiki/TCP_Receive_Window es geht gar nicht darum es besser zu machen sondern es zu verstehen weshalb es nun mal so ist.

Ketzer-Modus: Man muss nicht verstehen, weshalb estwas so ist wie es ist, man muss akzeptieren DASS es so ist, sofern man das Ziel einer Kompatibilität hat.