Hätte gerne paar harte Daten bezüglich Datentransfer in Netzwerken.



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


  • Mod

    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

    http://www.freesoft.org/CIE/RFC/1122/79.htm



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


  • Mod

    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.


  • Mod

    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.


  • Mod

    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



  • Paketdienst schrieb:

    Und auch:

    Wenn ein Paket verloren geht werden alle nachfolgenden Pakete bei TCP zurückgehalten, bis das verlorene ankommt, auch evtl durch neuschicken.

    das ist nicht so. nachfolgende pakete sind i.d.r. bereits versandt, bevor die bestaetigung zurueck kommt.

    Jodocus schrieb:

    > ebensowenig bei TCP,

    Oh doch, TCP garantiert dir die korrekte Reihenfolge der Packete. 😉

    aus meinem quote war ersichtlich, dass ich das ankommen meine. du hast es dahingehend entstellt.

    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 kenne die standardeinstellung eins mediagateway in der preisklasse mehrerer jahresgehaelter: bis 5 ms
    das ist im uebrigen komplexer als ein bisschen puffern, was klar wird, wenn man sich verdeutlicht, dass es sich um sprache handelt. soviel zu eigentlich - aber hey, warum hier nicht einach ein bisschen was schreiben?
    warum tcp fuer sprache NIE benutzt wird, haben wir bereits geklaert.



  • mezzo mix schrieb:

    Paketdienst schrieb:

    Und auch:

    Wenn ein Paket verloren geht werden alle nachfolgenden Pakete bei TCP zurückgehalten, bis das verlorene ankommt, auch evtl durch neuschicken.

    das ist nicht so. nachfolgende pakete sind i.d.r. bereits versandt, bevor die bestaetigung zurueck kommt.

    Ich meinte auch bei der anderen Seite. Die Daten kommen in richtiger Reihenfolge bei dem Programm an. Daher blockieren Daten die noch nicht angekommen sind auch erst noch die evtl schon angekommenen nachfolgenden Daten.



  • ahhhso, d'accord 🙂



  • SideWinder schrieb:

    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.

    Sorry, aber diese Art der Argumentation halte ich für ziemlichen Unsinn.
    Dann müssten wir auch der Rettung verbieten mit Blaulicht zu fahren. Denn wenns dringend ist muss es sowieso der Hubschrauber sein, und sonst ist es ja nicht so dringend. Oder wie. 😕

    Man kann mit End-To-End Checks übers Internet wunderbar Fehlerschranken garantieren. Zumindest so lange man keine Echtzeit Anforderung hat, also nur garantieren muss dass die Daten irgendwann mal richtig ankommen werden. Ich glaube dass das für viele Anwendungen reicht, und besser ist, als die Daten einfach so ungesichert zu schicken.

    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.

    Unsinn. Dreher in der Paketreihenfolge etc. kann man relativ leicht mitbekommen, indem man eine Rolling-Checksum verwendet. Die kann man z.B. am Ende jedes Anwendungspakets mitschicken. Dadurch findet man Fehler, egal wie sie in den darunterliegenden Schichten passiert sind.

    Hast du irgendwelche Quellen/Papers wo das tatsächlich empfohlen wird?

    Ne, Paper kann ich dir dazu keins nennen, ist einfach meine Meinung.


Anmelden zum Antworten