Hätte gerne paar harte Daten bezüglich Datentransfer in Netzwerken.
-
netzwerknoobie schrieb:
Sagen wir, ich schiebe 1 Megabyte von hier auf nen Rechner in die USA. Wie viel davon schätzt ihr gehen unterwegs verloren?
Das wird von zu vielen Faktoren abhängen, um hier sinnvolle Mutmaßungen darüber anstellen zu können. Aber miss es doch aus: Hol Dir für zwei Stunden eine VM bei Amazon EC2 in einem der US-EAST-Rechenzentren und probier damit herum.
Interessant ist diesbezüglich auch: Benutzt Du WLAN? Da geht teilweise erstaunlich viel verloren.
-
zwutz schrieb:
Christoph schrieb:
UDP garantiert, dass ein einzelnes Paket entweder ganz oder gar nicht ankommt. Es kann nicht passieren, dass einzelne Bytes innerhalb eines Pakets in der falschen Reihenfolge ankommen.
er meinte wohl die Reihenfolge der Pakete, die ist bei UDP tatsächlich nicht garantiert
ebensowenig bei TCP, aber ich weiß, was du meinst
zwutz schrieb:
daher verwendet man UDP auch nur da, wo sowas egal ist. Bei VoIP oder Streaming allgemein ist der geringere Overhead wichtiger als das alle Pakete durchkommen
vertauschte pakete sind bei voip nicht wirklich egal. sie werden wieder sortiert, solange es geht. darum kümmert sich dann die anwendung.
der overhead ist im übrigen egal. bei voip hast du ohnehin rund 40% overhead. der grund ist ein anderer: ein erneut gesendetes sprachpaket ist in der regel so gut, wie keines.zwutz schrieb:
Die Fehlerrate wird jetzt nicht allzu hoch sein, selbst bei UDP. Zumindest bei der kabelgebundenen Übertragung.
dem netz ist es erstmal egal, ob es TCP oder UDP transportiert. da geht genauso viel, oder wenig, verloren.
-
Und auch:
Wenn ein Paket verloren geht werden alle nachfolgenden Pakete bei TCP zurückgehalten, bis das verlorene ankommt, auch evtl durch neuschicken. Dadurch kann ein einzelnes verlorenes Paket für Verzögerungen sorgen.
-
netzwerknoobie schrieb:
Es wird ja immer gesagt, das UDP unsicherer ist (was das ankommen der Datenpakete angeht) als TCP
Nebenbei: Man sagt auch unzuverlässig(er).
-
> ebensowenig bei TCP,
Oh doch, TCP garantiert dir die korrekte Reihenfolge der Packete.
> sie werden wieder sortiert, solange es geht.
Passiert eigentlich nicht. Wenn man das tun wollte, könnte man gleich den TCP-Stack des OS nutzen, der ist mit Sicherheit schneller als ein künstlich zusammengefrickeltes Pseudo-TCP.
-
Aber mit UDP hätte man mehr kontrolle drüber. Man könnte z.B. implementieren, dass noch 20-30 ms auf das Paket gewartet wird. Bei TCP hat man nicht die Kontrolle. Wenn da ein Paket erst eine Sekunde zu spät kommt werden alle Pakete nach dem fehlenden ja erstmal zurückgehalten. TCP hat viele Features, aber da nimmt man dann auch alle Features, da kann man keine einzelnen abschalten. Dafür hat man dann UDP bei dem man das eine oder andere TCP Feature selbst implementieren kann.
Ich weiß allerdings nicht wie das in VoIP Software gehandhabt wird, ich beziehe das hier nur aus meinem Wissen über TCP und UDP.
-
Jodocus schrieb:
> sie werden wieder sortiert, solange es geht.
Passiert eigentlich nicht. Wenn man das tun wollte, könnte man gleich den TCP-Stack des OS nutzen, der ist mit Sicherheit schneller als ein künstlich zusammengefrickeltes Pseudo-TCP.
Ich schätze schon dass das passiert.
Der Empfänger spielt ja vermutlich nicht sofort alles was er empfängt, sondern versucht einen bestimmten Lag einzuhalten.
Anders gesagt: beim Beginn der Übertragung und nach jeder Unterbrechung, wird der Empfänger ein paar zig oder hunterd Millisekunden Audiodaten puffern, bevor er zu spielen anfängt.
Danach spielt er, und da die Clocks des Senders und des Empfängers nicht wahnsinnig schnell driften werden, bleibt der Lag einigermassen konstant.Kommt nun ein Paket das der Empfänger erst in 50ms braucht dann steckt er das in seinen Empfangspuffer bzw. dekodiert es und steckt es in den Audio-Ausgabe-Puffer.
Kommt danach eins dass er schon in 20ms braucht, dann sortiert er sich das entsprechend in den Empfangspuffer/Audio-Ausgabe-Puffer rein, und spielt es natürlich VOR dem Paket das er zuvor empfangen hat.Und wenn wirklich ein Paket gar nicht bzw. zu spät kommt, dann macht er wieder eine Unterbrechung, und fängt neu an zu puffern.
Ich hab zwar wenig bis gar keine Erfahrung mit Live Audio-Übertragung, aber so würde ich das zumindest angehen.
Mit TCP ginge das nicht, daher ist es für sowas besser wenn man UDP verwendet.
-
Zusammengefaßt:
UDP:
-Wenn Pakete ankommen sind sie unbeschädigt.
-Pakete können nicht ankommen.
-Pakete können in falscher Reihenfolge ankommen.
-Pakete können mehrfach ankommen.TCP
-Pakete kommen garantiert (irgendwann) an.
(Solange sie überhaupt ankommen können)
-Pakete kommen in der richtigen Reihenfolge an.
-Pakete kommen genau einmal an.
-
Naja... bei TCP muss man im Prinzip gar nicht mehr von Paketen reden. TCP kann man einfach als Byte-Stream ansehen.
-
UDP hat zwar eine Checksum, aber garantiert unbeschädigt sind die Pakete nicht, oder?
MfG SideWinder
-
SideWinder schrieb:
UDP hat zwar eine Checksum, aber garantiert unbeschädigt sind die Pakete nicht, oder?
MfG SideWinder
Also eine starke Garantie ist es nicht ;o
-
IP verwendet überhaupt nur ne 16 Bit "+" Checksumme, sowohl bei TCP als auch bei UDP (bei UDP optional).
D.h. wenn es um die Wurst geht sollte man immer noch zusätzliche eigene Prüfsummen verwenden.
-
hustbaer schrieb:
IP verwendet überhaupt nur ne 16 Bit "+" Checksumme, sowohl bei TCP als auch bei UDP (bei UDP optional).
D.h. wenn es um die Wurst geht sollte man immer noch zusätzliche eigene Prüfsummen verwenden.
Sollte die Checksum von IP nicht für TCP/UDP egal sein? Inwiefern spielt die eine Rolle? Du meinst falls das Paket an eine falsche Adresse gesendet wurde?
MfG SideWinder
-
TCP ist eine Schicht höher, soll keine Verfikation von den Daten auf IP-Ebene stattfinden? Im IP Header können Bit auch umkippen.
Aber ja, die Checksume dort sind für Header + Options.
-
Ich hab das falsch formuliert.
Ich meinte die beiden IP Protokolle TCP und UDP verwenden beide nur 16 Bit Prüfsummen.Die IP Header-Prüfsumme meinte ich nicht, die ist was die Daten angeht wirklich egal.
Auf jeden Fall: sämtliche Prüfsummen der Protokollschichten IP, TCP und UDP sind extrem schwach.
-
Bitfehler sind auch eher Sache der Sicherungsschicht. TCP/UPD kümmern sich eher Paketweise um alles. Die Prüfsumme in der Transportschicht ist glaub ich eher nur noch so eine Art letzte Sicherung.
-
Das ist im OSI Modell sicher so gedacht, ja.
Da man sich die "Sicherungsschicht" allerdings nicht aussuchen kann, ist man IMO gut beraten, wenn man trotzdem eigenen (starke) Prüfsummen in der Anwendungsschicht verwendet.
-
Mit der Argumentation müsste ich alle Aufgaben der unteren Schichten nochmal selbst in der höheren Schicht umsetzen...das ist sicherlich nicht Sinn eines Schichtenmodells. Ich muss mich auf die darunterliegende Schicht verlassen können.
MfG SideWinder
-
Das kommt darauf an was du machst, was die Anwendung für Anforderungen hat.
Wenn ein "wird im Normalfall funktionieren" ausreicht, dann verlass dich auf das was die diversen darunterliegenden Schichten machen.Wenn du dagegen eine bestimmte Schranke für die Fehlerwahrscheinlichkeit garantieren musst (willst), dann brauchst du End-To-End Checks/Prüfsummen, und die kann prinzipbedingt kein Schichtenmodell bieten.
-
Wenn ich solche Garantien in einem Netzwerk abgegeben muss, dann sollte ich kein Netzwerk haben, denn so etwas ist schlichtweg nicht zu garantieren.
Wenn ich eine solche Garantie nur für 99,9999% der Zeit abgeben muss sollte ich ebenfalls noch ziemliche Kontrolle über das Netzwerk haben und somit Herr über alle Schichten sein.
Sobald ich keine Kontrolle mehr über darunterliegende Schichten habe bringt mir eine Checksumme weiter oben auch nur noch wenig weil dann das Risiko eines TCP-Pakets in falscher Reihenfolge da ist wenn die Zahl geswappt wurde, etc. Da können ja dann beim TCP/IP-Stack in 4 Schichten Probleme auftreten die du weiter oben überhaupt nicht mitbekommst. Einzig und allein deine Anwendungsdaten könntest du noch etwas besser überprüfen, mag nett sein, denke aber nicht, dass das insgesamt noch nötig ist.
Hast du irgendwelche Quellen/Papers wo das tatsächlich empfohlen wird?
MfG SideWinder
