Frage zu Protokollverwendung in meinem Projekt

[Gast]

pointercrash() schrieb:

~fricky schrieb:

pc() schrieb:

zur Sicherheit über jeden Block `ne CRC mitschicken...

das kannste dir auch sparen, selbst wenn keine udp-prüfsummen mitgeschickt werden. das darunterliegende netzwerkinterface sorgt dafür, dass empfangene pakete keine bitfehler haben. kaputte pakete werden weggeworfen. ethernet und ppp z.b. basteln selber einen CRC rein. 802.11 macht sogar selbständig retransmissions.

Unbezweifelbar, aber in der Praxis kommen jedoch trotzdem Fehlübertragungen zustande. Ganz übel in Erinnerung habe ich z.B. CAN- Bus. Bei einem Test wurden 100 m CAN- Strecke parallel mit einem Ratterschützkabel auf eine Rolle gewickelt.

Was für ein CAN war es denn? Wahrscheinlich High-Speed, 500kbaud, so wie immer wenn von "CAN" ohne genauere Angaben geredet wird

[~fricky]

^^@pc(): dass in einer rauhen umgebung wenig durchkommt hab' ja nicht angezweifelt. wenn die übertragungswege extrem mies und übelst gestört sind, der verkehr ganz zum erliegen kommt, beweist doch nur, wie gut CRCs funktionieren. aber kann es sein, dass du CRC mit fehlerkorrigierendem code verwechselst? das ist es ganz sicher nicht.

pointercrash() schrieb:

TCP/IP ist ein Mixup- Protokoll... Nachteilig ist, daß die Implementation komplex, entsprechend "fett" ist, sich immer wieder Verletzbarkeiten auftun und auf "slim clients" einfach keinen Platz hat.

naja, das stimmt auch nicht ganz. das ist wieder so eins der grossen irrtümer der netzwerktechnik (so wie: 'häng doch einen CRC an deine UDP pakete') TCP wird oft von seiner komplexität her überschätzt. man kann TCP so weit reduzieren, dass es als 'ping-pong-protokoll' in fast jeden schlappen 8-bitter passt (wohlwollend geschätzt ca. 2k code und etwa 20 bytes RAM), so dass auch eine 'full-featured' gegenstation voll und ganz mit dem zufrieden ist, was die minimalimplementation ihr vorsetzt.

pointercrash() schrieb:

Oder gehst Du auch nackig aus dem Haus, fricky?

ach, du willst, dass ich im hochsommer dicke winterklamotten anziehe? nee, wozu?

[pc()]

Tim schrieb:

Was für ein CAN war es denn? Wahrscheinlich High-Speed, 500kbaud, so wie immer wenn von "CAN" ohne genauere Angaben geredet wird

CAN 1.0, ich bin mir sicher, unter 500 kBaud geblieben zu sein. Müßte ich echt alte Särge öffnen, um das zu fixen.
Hatte was für eine Auto- Fab gemacht (so ca '94) und gehofft, im Zuge der CAN- Schwemme das nochmal an einen Chemieladen verkaufen zu können und mir dann diese Tests eingehandelt. Letztendlich war RS422 die Wahl des Kunden

Gestorben ist die Sache an einer kompletten Absurdität, es würden nochmal ein paar Clients benötigt, aber ich müßte einen Y2K- Compliance vom Institut BlahBlubb vorlegen, kostet nur 14 Mille (damals noch Deutschmark).

Nach dem Gegenvorschlag 14 Mille plus Clients hab' ich nie wieder was von denen gehört. :p

[pc()]

~fricky schrieb:

^^@pc(): dass in einer rauhen umgebung wenig durchkommt hab' ja nicht angezweifelt. wenn die übertragungswege extrem mies und übelst gestört sind, der verkehr ganz zum erliegen kommt, beweist doch nur, wie gut CRCs funktionieren. aber kann es sein, dass du CRC mit fehlerkorrigierendem code verwechselst? das ist es ganz sicher nicht.

Nein, tue ich nicht. Ich verweise nur darauf, daß den Autobauern damals die CRC genügt hat, daß aber bei der Industrieautomation echte Protokolle draufgesetzt wurden (CANopen, DeviceNet usw.). So gut eine Sicherung auf Hardwareebene auch funktioniert, es schadet nicht, sich über falsche Frames Gedanken zu machen.

Letztendlich ist es aber wurscht, was Sinn macht. Wenn ein Dr. (med. vet.) einem Dr. Dr. Dr. (med. rer.nat. pharm.) was verkauft, wird als Information an den Entscheider (BWL- Ing.) nur durchgereicht, daß CAN am neu eingeführten Ratterschütztest gescheitert ist. Daß die alte Technik (RS422, Klartextmeldungen mit 2400 Bd ohne jegliche Sicherung) noch viel schlechter war, interessierte niemanden, da die Technik hausintern vor hundert Jahren zertifiziert wurde.

~fricky schrieb:

das ist wieder so eins der grossen irrtümer der netzwerktechnik (so wie: 'häng doch einen CRC an deine UDP pakete') TCP wird oft von seiner komplexität her überschätzt. man kann TCP so weit reduzieren, dass es als 'ping-pong-protokoll' in fast jeden schlappen 8-bitter passt (wohlwollend geschätzt ca. 2k code und etwa 20 bytes RAM), so dass auch eine 'full-featured' gegenstation voll und ganz mit dem zufrieden ist, was die minimalimplementation ihr vorsetzt.

Ich seh' das einfach pragmatisch, wenn ich OpenTCP einbände, wäre der kleine Controller schon voll, da mache ich mir keine Gedanken um's Wegsägen evtl. unbenötigter Funktionalität. Ich wußte, daß der UDP- Socket von E-Lab funktioniert, reinpaßt und der Applikation genug Platz zum Arbeiten läßt. Wenn Du schlanke Implementationen zu TCP/IP kennst, setz' 'nen Link.

~fricky schrieb:

ach, du willst, dass ich im hochsommer dicke winterklamotten anziehe? nee, wozu?

Richtig ist, daß es schwierig war, Drops zu provozieren. Es war aber auch nicht schlecht, dafür zu sorgen, daß das Gerätchen wieder in den Stream findet, wenn es wirklich dazu kommt.