Frage zu Protokollverwendung in meinem Projekt

hustbaer

Ob du TFileStream (für TCP!) verwenden kannst hängt davon ab was TFileStream alles macht. Wenn das nur 1:1 die Daten des Files rausklopft dann geht das ziemlich sicher. Wenn das intern irgendein selbstgestricktes Protokoll verwendet (was IMO eher unwahrscheinlich ist) wird es wohl eher mühsam.

Was UDP angeht: wie kommst du darauf dass UDP jetzt besonders "bandbreiten-sparend" wäre? Klar, es fallen ein paar Header-Daten weg und ACKs werden auch keine gesendet, aber das sollte sich alles unterhalb von vielleicht 10% Unterschied abspielen - also IMO nicht der Rede wert.

Wo es natürlich einen Unterschied macht ist wenn Pakete verloren gehen, dann wird bei UDP (zumindest Empfänger-Seitig) weniger Bandbreite gebraucht -- solange man kein eigenes Protokoll verwendet um Retransmissions möglich zu machen. Nur kommen dann auch weniger Daten an. Vor allem reicht ein einziges Paket (bzw. "Datagramm") welches nicht ankommt damit man ein ganzes Bild/Frame/... nicht dekodieren kann.

Weiters... Webcams. Ähm. Willst du die Bilder als Motion-JPEG übertragen? Oder sonstwie als einzelne Bilder? Wenn du nämlich einen Video-Stream übertragen willst, dann ist das garnicht so einfach es so zu machen dass nach einem fehlenden Paket weitergemacht werden kann. Das müssen zumindest der Video-Codec und das verwendete Container-Format unterstützen.

Und sobald Sprache und Musik ins Spiel kommt wirds richtig lustig - zumindest wenn die live aufgezeichnet werden. Aber das nur nebenbei

nfg schrieb:

da man bei udp keinen stream hat kannst du TFileStream nicht verwenden

was immer auch TFileStream ist, aber man kann über UDP ganz einfach 'streamen', indem man selber pakete schnürt.
@husti: das mit der bandbreite ist zwar im prinzip richtig, aber tcp versucht mit vielen schlauen algorithmen (nagle, slow-start, delayed acks, etc.) den durchsatz zu erhöhen. sowas kann sich in gernzfällen aber als echter bremsklotz erweisen. ausserdem kann man bei UDP die prüfsummen weglassen, was z.b. bei clients mit wenig rechenpower ein vorteil ist. also wenn's richtig schnell sein soll und hin und wieder mal ein paketchen fehlen darf, würde ich UDP den vorzug geben.

hustbaer

@fricky: Theoretisch mag das stimmen was du schreibst (bezüglich UDP). Der OP hat aber ganz offensichtlich keine Ahnung von irgendwas, daher will ich auch nicht UDP empfehlen, weils keinen Sinn macht, da er damit nicht zu einem Ergebnis kommen wird.

Tachyon

Ein andere Möglichkeit wäre boost.asio.
KLar, Du kannst auf der einen Seite API A nehmen, und auf der anderen Seite API B. Ich denke aber, dass es einfacher wäre, wenn Du auf beiden Seiten die gleiche API benutzen würdest.

XBert

HI

hustbaer schrieb:

Der OP hat aber ganz offensichtlich keine Ahnung von irgendwas...

das will ich jetzt aber überlesen haben (CISCO CCNA).

Tachyon schrieb:

Ein andere Möglichkeit wäre boost.asio.
KLar, Du kannst auf der einen Seite API A nehmen, und auf der anderen Seite API B. Ich denke aber, dass es einfacher wäre, wenn Du auf beiden Seiten die gleiche API benutzen würdest.

Danke, das hilft wirklich, hab nämlich nicht gerade viel ahnung von den APIs, abgesehen von ein paar einfachen dingen.

Das mit TFileStream war nur als Analogie gedacht.

Gedach war, immer abwechselnd das bild der einen und der anderen Cam zu senden(als jpeg), das heißt es ist nicht so wichtig ob da jetzt mal ein Frame weg ist oder nicht

MFG
XBert

hustbaer

XBert schrieb:

HI

hustbaer schrieb:

Der OP hat aber ganz offensichtlich keine Ahnung von irgendwas...

das will ich jetzt aber überlesen haben (CISCO CCNA).

Ich hatte das bezogen auf das Thema des Threads gemeint.
"von irgendwas" nehme ich zurück

Also ich habe hier eine Überwachungsanlage mit mehreren Cam- Servern, die ich per Dump belauschen kann. TCP kommt dabei nur alle paar Sekunden zum Einsatz, das gestreamte Videomaterial wird per UDP geschickt - warum wohl?

TCP hat so viel Sicherungsschnickschnack mit aufwendigen Timing- Regeln drin, daß 10% mehr Traffic eher ein frommer Wunsch ist.

UDP ist so "kompliziert", wie ein File zu öffnen und da reinzuschreiben, bzw. draus zu lesen; zur Sicherheit über jeden Block `ne CRC mitschicken, über Rückkanal Quittung lesen und fertig, halt selbstverantwortlich entscheiden, wieviel Sicherheit Deine Applikation braucht. Ich hab`mal ein Atmel- Prozessorchen mit 2k RAM für`n Kunden mit der fix&fertig UDP-Socket von E-Lab Pascal zum MP3- Streamer zurechtgebastelt, volles TCP hätte in den Controller sowieso nicht reingepaßt.
Der Prog, der die zugehörige Win- Applikation gemacht hat, hatte auch keine Einwände und da das Ding mittlerweile gebaut wird, kann ich versichern, daß Aussetzer überwiegend auf Hardware- Probleme zurückzuführen waren und nur dort UDP ein Problem darstellte, wo das Netzwerk sowieso heillos überlastet oder fehlkonfiguriert war.

Also, ich würde mir wieder was auf UDP- Basis stricken, wenn ich schlanke Clients habe und inhouse bleibe, ohne mir anzusehen, was TFileirgendwas macht
Über Internet ist das möglicherweise ein bißchen anders, aber wenn eine Strecke UDP nicht zeitstraff transportieren kann, reißt wahrscheinlich auch TCP/IP keine Bäume mehr aus, kostet aber deutlich mehr Traffic und Prozessorressourcen.

Blas`das Zeug über UDP `rüber, wirst es nicht bereuen

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.

hustbaer

Auf das "darunterliegende netzwerkinterface" würde ich mich NIE verlassen.

@XBert: nur so nebenbei... soll das übers inet oder nur übers LAN laufen?

hustbaer schrieb:

Auf das "darunterliegende netzwerkinterface" würde ich mich NIE verlassen.

Machs nicht immer so spannend mit deinen Beiträgen. Nenn mal eine Programmiertechnik, die sich nicht darauf verlässt.

pointercrash**

~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. Alle paar Minuten hat sich eine fehlerhafte Message als i.O. durchgemogelt, obwohl gemessen an den Nutzdaten ein üppiger Checksummenblock dranhängt. Das war natürlich ein krasser Test, aber im Feld sind tatsächlich schon so Sachen passiert, daß z.B. bei Einschalten der Zündung Fenster runterfahren o.Ä.

Ein Freund, der in einer Medizintechnikfirma designt, hat ähnliche Erfahrungen mit WLAN gemacht und ich glaub' ihm das. Dabei sieht das applikationsseitig wie Ethernet aus.

Also, ich möchte schon eine wenigstens minimale Sicherung oberhalb der physikalischen Schicht haben, alleine schon aus diagnostischen Zwecken. Nur, wie obig erörtert, bei UDP kann man sich selbst aussuchen, wieviel Sicherheit man beifügt, bei TCP muß man mehr oder minder die "volle Packung" implementieren und mitschleppen, was in vielen Anwendungen gar nicht nötig ist.

hustbaer

COPD schrieb:

hustbaer schrieb:

Auf das "darunterliegende netzwerkinterface" würde ich mich NIE verlassen.

Machs nicht immer so spannend mit deinen Beiträgen. Nenn mal eine Programmiertechnik, die sich nicht darauf verlässt.

Die Prüfsumme von TCP reicht i.A. gut aus (obwohl die eigentlich recht schwach ist). Bei UDP: *wenigstens* ne CRC16, besser ne CRC32 pro Paket mitschicken.

pointercrash**

hustbaer schrieb:

Die Prüfsumme von TCP reicht i.A. gut aus (obwohl die eigentlich recht schwach ist). Bei UDP: *wenigstens* ne CRC16, besser ne CRC32 pro Paket mitschicken.

Bei kleinen Frames/Packs, die man ggf. droppen kann, haben im geschilderten Fall 8-Bit XOR- Summen genügt, das läuft wirklich auch auf kleinsten Kisten "nebenzu".
Wenn Xbert auf beiden Seiten einen vollen TCP/IP- Stack hat, soll er halt den hernehmen, sich meinetwegen auch aus einer Lib bedienen, um ein TFileStream oder so einzusetzen.
Aber er will ja auf unterschiedlichen Plattformen schnell zu Potte kommen und da hat er's am einfachsten mit UDP. Je nachdem, was ihm hinnehmbar scheint, kann er selbst entscheiden, was er an "Security" draufpacken mag.

XBert

Danke schon mal für die vielen Hinweise.

Das ganze soll übers Netzwerk laufen (zuerst Ethernet und danach über W-Lan 54, was übrigens von der Bandbreite her ausreichen sollte, da das Netzwerk nur zu diesem Zweck genutzt wird)

Auf der einen Seite läuft die ganze sache auf nem Laptop mit Dual-Core T5600 (1.86+Vista,mit Gui) und auf der anderen auf nem Pico-ITX Board (1GHz+Hardy Heron, nur Konsole)

Ich werde das ganze letztendlich wahrscheindlich mit Boost.Asio machen und bei den UDP-Paketen ne kurze Prüfsumme einfügen(nur um zu wissen ob das Paket verworfen werden soll oder nicht).

Und noch ein mal für alle: ICH WERDE NICHT TFileStream VERWENDEN.

MFG XBert

P.S:

hustbaer schrieb:

Die Prüfsumme von TCP reicht i.A. gut aus (obwohl die eigentlich recht schwach ist). Bei UDP: *wenigstens* ne CRC16, besser ne CRC32 pro Paket mitschicken.

Nur mal so nebenbei: Bei TCP werden diese Prüfsummen dazu verwendet um festzustellen ob ein Paket erneut gesendet werden muss, also ist keine zusätzliche notwendig da die Pakete immer richtg ankommen

pointercrash() schrieb:

Bei einem Test wurden 100 m CAN- Strecke parallel mit einem Ratterschützkabel auf eine Rolle gewickelt. Alle paar Minuten hat sich eine fehlerhafte Message als i.O. durchgemogelt, obwohl gemessen an den Nutzdaten ein üppiger Checksummenblock dranhängt.

dann war wahrschinlich mit deiner hardware was faul. wenn ich mich recht erinnerere liegt die restfehlerwahrscheinlichkeit bei einem 16-bit CRC (den ja CAN benutzt) irgendwie bei 10^-15, d.h. so schnell sollten sich keine falschen messages durchschummeln.

hustbaer schrieb:

Bei UDP: *wenigstens* ne CRC16, besser ne CRC32 pro Paket mitschicken.

mag ja was bringen, wenn du UDP z.b. über rs232 (ohne ppp oder sowas) scheuchen willst. aber bedenke dass z.b. jeder popelige ethernet-controller 32-bit crc verwendet, was die chance, dass dein CRC-code jemals einen bitfehler zu sehen bekommt, verschwindend gering macht.

pointercrash**

~fricky schrieb:

pointercrash() schrieb:

Bei einem Test wurden 100 m CAN- Strecke parallel mit einem Ratterschützkabel auf eine Rolle gewickelt. Alle paar Minuten hat sich eine fehlerhafte Message als i.O. durchgemogelt, obwohl gemessen an den Nutzdaten ein üppiger Checksummenblock dranhängt.

dann war wahrschinlich mit deiner hardware was faul. wenn ich mich recht erinnerere liegt die restfehlerwahrscheinlichkeit bei einem 16-bit CRC (den ja CAN benutzt) irgendwie bei 10^-15, d.h. so schnell sollten sich keine falschen messages durchschummeln.

Glaub' mir, ich weiß, wie man eine CAN- Strecke ordnungsgemäß aufbaut (straight terminated bus, no T). Eher ist Dir nicht klar, wie hart der Test ist.
Bei 110 V- Schützen, wo am Ende der Unterbrecher auf den Erregerkreis gelegt ist, haben wir Spannungspeaks von bis zu 2 kV gemessen, das Teil ist eine breitbandige Störorgel bis in den zweistelligen MHz- Bereich. Wegen des Arbitrierungskonzepts von CAN ist je nach Kabelmaterial unter solchen Bedingungen der Datendurchsatz zwischen schlecht und 0 (Null). Schlimm wird es dann, wenn ein Frame als gesendet abgehakt, aber nie angekommen ist oder ein verfälschter Frame als richtig reinkommt. Beides trat reihenweise auf, wobei sogar sogar die Toleranz der Terminierungswiderstände und ein paaar Ferritringe das Ergebnis deutlich beeinflußten.

~fricky schrieb:

mag ja was bringen, wenn du UDP z.b. über rs232 (ohne ppp oder sowas) scheuchen willst. aber bedenke dass z.b. jeder popelige ethernet-controller 32-bit crc verwendet, was die chance, dass dein CRC-code jemals einen bitfehler zu sehen bekommt, verschwindend gering macht.

Gegenmessungen mit Cheapernet- Ethernet (damals "in") waren übrigens noch demoralisierender.
Wir bekamen so wenig Durchsatz, daß sich keiner mehr die Mühe gemacht hat, zu überprüfen, wieviele davon wirklich kaputt sind. Zur Ehrenrettung muß noch erwähnt sein, daß Cheapernet mit 10 MBit brutto läuft, wir CAN mit ein paar hundert kBit getestet haben.

TCP/IP ist ein Mixup- Protokoll, das sich quer durch (fast) alle OSI/ISO- Schichten bedient und die obig geschilderten Fehlermöglichkeiten weiter minimiert. Nachteilig ist, daß die Implementation komplex, entsprechend "fett" ist, sich immer wieder Verletzbarkeiten auftun und auf "slim clients" einfach keinen Platz hat.
UDP ist wesentlich anspruchsloser, aber man muß sich selber über zusätzliche Sicherungsmaßnahmen Gedanken machen. Wenn's nicht die gestörte Strecke ist, kann mich auch ein wildgewordener Ethernet- Chip mit Mist bewerfen und dagegen hilft eben bereits auch ein noch so müder Checksum/Ack- Mechanismus.

Oder gehst Du auch nackig aus dem Haus, fricky?

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

^^@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?

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

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