Frage zu Protokollverwendung in meinem Projekt
-
Hi Leute,
Ich möchte ein kleines Projekt realisieren, habe aber noch ein paar grundsätzliche Fragen.
Das Projekt ist folgendes: es gibt einen Windows-Client (wird mit Borland c++-Builder 2007 gemacht) und einen Linux-Server (Consolenanwendung, Ubuntu Hardy Heron).
Der Client sendet dem Server bestimmte Befehle die vom Server ausgeführt werden, danach sendet der Server an den Client die Rückmeldung, dass der Befehl erfolgreich ausgeführt wurde. Der Client kann dann den nächsten Befehl senden.
Für diese Aufgabe habe ich mir gedacht das TCP-Protokoll zu verwenden(da es wichtig ist, dass die Daten vollständig ankommen).
Auf der Windows-Seite hätte ich die Komponente TcpClient des C++-Builders verwendet und auf der Linux-Seite einfache Socketprogrammierung.Die zweite, etwas schwierigere Anforderung ist folgende: Ich möchte vom Client aus, Sprache oder Musik an den Server übertragen. Gleichzeitig soll der Server immer die Bilder von zwei Webcams an den Client übertragen. Für diese Aufgabe wäre das UDP-Protokoll doch ganz gut geeignet, da es Bandbreite spart und es nicht so wichtig ist ob alle Frames der Webcam ankommen.
So, wer es bis hierher geschafft hat dem bin ich dankbar und hoffe auf eine Antwort auf folgende Frage:
Kann ich auf der Windows-Seite die Borland-Komponenten verwenden und auf der Linux-Seite "normale" Socket-Programmierung betreiben?
Soll heißen: z.B. kann ich die Webcam-Daten mittels TFileStream empfangen und umgekehrt die Sprache ebenfalls mittels TFileStream senden?Vielen Dank für die Mühe und danke
XBert
-
ich denke schon dass es egal ist womit du das sendest und empfängst.
udp ist ein bekanntes und wichtiges protokoll, dass überall gleich
implementiert wird. windows und linux nutzer können schließlich
beide ein video einer webseite gucken ohne dass es probleme mit dem
protokoll gibt. wenn beides udp ist, gibt es da keine schwirigkeiten
-
gillt natürlich auch für tcp
-
da man bei udp keinen stream hat kannst du TFileStream nicht verwenden
-
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.
-
@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.
-
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.
-
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
-
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.
-
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.
-
~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.
-
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.
-
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.
-
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.
-
~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?
