Streaming übers Netz mit TCP oder UDP ?



  • du kannst auf UDP Basis auch eine Art Light-TCP implementieren, also so, dass Packete zB. in richtiger Reihenfolge bearbeitet werden etc.

    in
    UNIX Network Programming | ISBN: 0131411551
    findest du eine Beispiel Implementierung



  • Ich bin zwar kein Experte auf dem Gebiet, aber ich würde sagen, genau für sowas ist UDP ja gedacht. Du mußt die Pakete nicht bestätigen. Wenn eins hängenbleibt, wird es auch nicht neu angefordert, schließlich soll das ja in Echtzeit passieren, also lieber Frame-Drops anstatt Nicht-Echtzeit-Wiedergabe. Ich würd' noch nicht mal einen Richtige-Reihenfolge-Algo implementieren, ich würd' einfach Pakete, die eine niedrigere Sequenznummer haben als schon da gewesene, ignorieren.



  • ich würde das so machen:

    einen Zähler in jedes Packet, der für jedes Packet um eins erhöht wird. Der Empfänger nimmt nun die Packete und speichert den Zähler des letzten akzeptierten Packets. Wenn nun ein Packet kommt, wo der Zähler kleiner ist als der letztgespeicherte Zähler, wird das einfach verworfen. So vermeidet man den Effekt, dass ein altes Packet ankommt und es kostet so gut wie nichts.



  • (bei Streams, für die der Counter nicht aussreicht (zB. endlos streams) muss man den Vergleich natürlich anpassen. So das man wenn der Packetzähler zu voll ist wieder bei 0 anfangen kann zu zählen, ohne dass alle Packete verworden werden ⚠)



  • so ungefähr habe ich mir das auch gedacht...
    Auf so einen zähler bin allerdings bis jetzt nicht gekommen.

    Wie gross ist den ungefähr der Geschwindigkeitsvorteil (verhältnis nutzdaten/header) gegenüber TCP? Und bei der Verzögerung bis ein Packet in der Anwendungsschicht angekommen ist.. hat jemand vergleichswerte zwischen tcp und udp?

    Till



  • Till schrieb:

    Wie gross ist den ungefähr der Geschwindigkeitsvorteil (verhältnis nutzdaten/header) gegenüber TCP? Und bei der Verzögerung bis ein Packet in der Anwendungsschicht angekommen ist.. hat jemand vergleichswerte zwischen tcp und udp?

    Darauf gibt es keine pauschalen Antworten - miss einfach mal konkret für die Fälle die Dich interessieren, soetwas kann _sehr_ stark variieren.



  • Hi,

    hmm, mal rechnen, nehmen wir 4 Bytes für die Paket-ID/Counter.

    Das macht ca. 4 Milliarden Pakete. Annahme: Ein Paket sei 512 Bytes groß. (Maximum, das garantiert nicht gesplitted wird)

    = 2.199.023.255.552 Bytes

    Mehr als 2 Terabyte zu streamen, ist doch, ok, oder? Danach muss man halt die Verbindung neu aufbauen 🙄

    Achja, bei voller DSL-Downloadkapazität kann man damit ca. 0,66 Jahre ohne Unterbrechung streamen 😃

    ChrisM



  • @Till
    gerade bei Netzen, wo leicht mal Packete flöten gehen (Internet), wirst du den Unterschied UDP/TCP merken, da ja erst nach einem bestimmten Timeout das Packet neu beantragt wird und die ggf. schon eingetroffenen Packete warten müssen.

    @ChrisM
    naja, ich finde es nen bisschen beschränkt, auf so etwas nicht rücksicht zu nehmen und die kosten sind ja nicht hoch.

    Und das mit den 2TB kann leicht überschritten werden, wenn zB. irgend wo jemand mit High-Res farben streamen will. Der wird dann natürlich auch nen GBit-Netz haben und keine 0.66 Jahre brauchen 🙂 :p



  • IMHO gibt es so einen Server im Linuxbereich schon. Kannst dir ja da ansehen wie die es gemacht haben.



  • Komprimierte Audiostreams übers Netzwerk streamen.. suchst du vielleicht so etwas wie Icecast oder Shoutcast?


Anmelden zum Antworten