Gayniale idee

[ethrandil]

Hi ihr genialsten Progger des Web :)
Ich hatte gerade ne Idee: Wie wäre es mal mit nem 'shared streaming' ?? Also man kann (wie mit shoutcast) einen mp3Stream aufmachen, und alle listener vertreiben den selber weiter, sodass die Bandbreite eigentlich immer ausreichen müsste!! (Ausnahmen wie router ausgenommen ;) )
Wenn auf einem Vollen 'Node' Connected wird, dann leitet der weiter an den nächst besten clientNode!

Ich weiß nicht, wie schwer das zu programmieren ist, aber das würde mich tierisch interessieren ;) Würd auch gerne mal an sowas mitmachen, bin abba zu schlecht in c++. Mit Java kann man das ja eh vergessen ... :).

Oder gibt es das sogar schon??

Mfg Ethrandil

[Kant]

Ist sogar schon "prinzipiell" im Netzwerk-Protokoll enthalten.
Stichwort : Multicasting
Basiert im Prinzip auf dem von dir genannten Prinzip, das Streams auf Routern/Nodes bei Bedarf gesplittet/generiert werden.

Aber ich wüßte jetzt nicht, das das schon in größerem Stil genutzt wird.

[bulla]

öhm, edonkey?

[ethrandil]

nein, nicht edonkey, es geht um livestreams :)
Aber prinzipiell schon edonkey!!
Das selbe Prinzip. Ich hab mich mal über Multicasting schlau gemacht... das ist nicht was ich meine, denn das läuft einerseits über Hardware, und zum zweitens ist nicht jeder Client subnode.

[Demirug]

ethrandil, die Idee ist nicht schlecht. Im Prinzip könnte man damit ein Liveradio mit unendlich vielen Teilnehmer bauen solange jeder genügend Up und Downstream für mindestens einen Kanal hat.

Es gibt nur zwei Probleme:

1. Latenz: Je länger die Kette wird desto länger dauert es bis auch der letzte das Programm empfängt.

2. Resync: Wenn nun mitten in einer Kette ein Teilnehmer rausfliegt (ungewollt) muss sich das nezt resyncronisieren. Das könnte dann bei einige zu einem längeren ausfall im Empfang führen.

Ansonsten ist das sicherlich eine interesante Aufgabe.

[ethrandil]

ja, das problem mit den latenzzeiten ist mir auch aufgefallen, da kommt es dann an den Punkt, wo der Streamer entscheiden muss: Hohe Latenz oder hohe Kosten!
Zum thema Reorganisierung: Es würde reichen, wenn sich nur die SubNodes des ausgefallenen nodes reorganisieren, deren subnodes bekommen das garnicht mit! (höchstens einen kleinen Aussetzer).

[Demirug]

Originally posted by ethrandil
ja, das problem mit den latenzzeiten ist mir auch aufgefallen, da kommt es dann an den Punkt, wo der Streamer entscheiden muss: Hohe Latenz oder hohe Kosten!
Zum thema Reorganisierung: Es würde reichen, wenn sich nur die SubNodes des ausgefallenen nodes reorganisieren, deren subnodes bekommen das garnicht mit! (höchstens einen kleinen Aussetzer).

Wobei die Latenz kaum auffällt solange man keine Uhrzeiten ansagt ;)

Ja einen Resync muss nur der Rechner durchführen welcher die Verbindung verloren hat.

Im Prinzip muss man das ganze wie folgt aufbauen.

1. Es gibt die Quelle. Dieser Server liefert den Grunddatenstrom und kennt und führt die wesentlichen Syncarbeiten für das netz durch.

2. Jeder Client fragt beim Basisserver nach einem freien Port an und meldet selbst wie viele Ports er zur Verfügung stellen kann.

3. Clients melden wenn Ports belegt oder frei werden an den Zentralserver.

4. Verliert ein Client seine Quelle fragt er den Zentralserver nach einer neuen.

5. Je mehr Ports ein Client zur Verfügung stellt desto dichter (weniger Hops) sollte er am Zentrallserver sein.

6. Der Server hat das Recht Clients andere Ports zuzuweisen und Clients die nicht genügend Bandbreite zur Verfügung stellen zu kicken.

Alles in allem eine lössbare Aufgabe.

[ethrandil]

nicht schlecht :)
Vorallem punkt 5 ist interessant!
Zu 6 würde ich sagen: Er kann ihn doch einfach ans Ende der Hierarchie Stellen! Dann hat man mit ihm keine Probleme mehr, und Modemuser werden nicht ausgeschlossen.
Das 'Recht' ihn zu kicken sollte man dem Server natürlich trotzdem geben ;)
eine andere Frage ist, ob der Server überhaupt das Komplette Netz kennen muss! Das kann natürlich bei größeren Streams ne menge Overhead erzeugen.
Die Clients könnten, wenn sie einen Client mit höherer Bandbreite als sie bekommen, diesen solange nach Oben verweisen, bis er einen vernünftigen Platz erhält! So bekommt der Master Server davon nichts mit. So könnten allesdings unterschiedlich starke 'Stränge' im ClientBaum geben, nähmlich dann, wenn die Guten Server an den Guten Tree kommen ... Allerdings ist der irgendwann voll (Oder man baut ne streung ein).

Ich würde also sagen die Clients Organisieren sich selber, ziehmlich unabhängig vom Mainserver. Dieser ist nur
1) Feste IP -> Ansprechpartner für connectende
2) Kleine Datenmengen wie Userzahl werden empfangen
3) Er bleibt aber immernoch Master! Also sollte es nicht möglich sein einen Client zu overtaken und somit ein großes Subnetz zu klauen ;) -> Stichprobenartiger Vergleich, der vom Master initiiert wird, sodass er nicht zugespamt wird von Syncwütigen Clients!

Eth

PS ich les es nicht nochmal durch, das ist mir zu konfus ;)

[Demirug]

Der Overhead würde sich in Grenzen halten. Im wesentliche kosten diese Listen nur Speicher. Und die optimierung des netztes geht von einer zentralen Stelle aus besser.

Wobei natürlich eine Selbstorganisation der Clients nach einem Bubbelsort prinzip sicherlich auch keine schlechte Idee ist.

Ja die armen Modembesitzer könnte man an des Ende des Baums setzen. Wenn der Baum aber nicht weit genug verzweigt bleiben sie aber drausen.

[Desti]

Uralt :P :P :P

http://www.heise.de/newsticker/data/jk-15.07.02-000/

[ethrandil]

auf jeden Fall interessant, aber eine Hierarchie wie wir wie vorhatten ist doch beim Gnutella-protokoll nicht vorhanden, oder?

[Abe Ghiran]

Nein, Gnutella ist in der Hinsicht ziemlich chaotisch. Als Node hält man eine maximale Anzahl von Verbindungen zu anderen Nodes offen. Will man jetzt einen Query senden, schickt man den einfach an alle offenen Verbindungen. Die Nodes schicken den dann wieder an ihre Verbindungen weiter, usw.

Damit eine Nachricht nicht unendlich durch das Netz wandert, hat sie eine time to live (kurz ttl), die die Anzahl der maximalen "Hops" (weiterleitungen) angibt. Jeder verringert die ttl vor dem weiterleiten, kriegt ein Node eine Nachricht mit ttl=0, leitet er sie nicht mehr weiter.
Man erreicht damit auch nur die Leute in einem gewissen "Radius" um einen herum.

Für den Dateitransfer werden dann extra Verbindungen aufgebaut, da kommt dann http als Protokoll zum Einsatz.

Egal was du da jetzt machst, ich würde dir schon erst mal zu java raten. Denn da stecken die Netzerk Sachen (sockets, streams) in einer schönen Klassenbibliothek und auch Threads (wirst du beim Netzwerkproggen brauchen) sind leicht zu handhaben.

Jan

[ethrandil]

Ja, aber mit Java sind MP3s recht Problematisch.
Im endeffekt dachte ich da eher an server und Winamp-plugin, und das ist mit Java (sogutwie) unmöglich...

[Abe Ghiran]

Da hast du natürlich recht. Damit käme java höchstens noch für den server in Frage, der müsste ja nur die Dateien von der Festplatte lesen und die dann per udp verteilen.
Wenn ich deine Idee so richtig verstanden habe, müsste das ja dann insgesamt so aussehen:

Server: liest von der Festplatte die mp3's und verteilt die an einige Clients per udp. D.h. er bräuchte ne einfache Playlist verwaltung und eine verwaltung der offenen verbindungen. Dazu kämen dann noch die udp verbindungen zu den registrierten clients und vielleicht ein tcp port, über den clients zum server verbindungen aufnehmen.

Client: hat einen udp port zum empfangen, je nach bandbreite mehrere ausgehende udp verbindungen, um den stream weiterzuleiten, und einen tcp port, um registrierungen von anderen clients entgegenzunehmen / weiterzuleiten. Das ganze verpackt in ein WinAmp plugin, zum abspielen.

Ansonsten im wesentlichen so wie Demirug das schon beschrieben hat, vielleicht am Anfang etwas einfacher, die ausgefeiltere Reorganisation könnte man ja dann vielleicht mal irgendwann nachrüsten.

Ich würde dir da gerne helfen, nur in c++ bin ich auch noch nicht so bewandert aber den server in java zu schreiben würde ich mir schon zu trauen. Dann müsste man sich nur vorher ein einfaches protokoll überlegen, wie client / server so kommunizieren.

Grüße, Jan

[ethrandil]

Hmm ich denke man sollte sich erstmal mit (Live-)Streaming beschäftigen. Das ganze kann ja auch moderiert sein, dH man müsste in echtzeit kodieren, auch um niedrigere Bitraten als 128 kbps zu haben! (zu hoch für livestream)
UDP halte ich für seeehr bedenklich!
Damit wäre nicht gewährleistet, dass pakete in der richtigen Reihenfolge ankommen, und das kostet dann ziehmlichen Verwaltungsaufwand... Für Client-messages gibt es sooo wenig Datenverkehr, dass das bisschen Overhead nichts ausmacht und bei den Daten ist halt die Reihenfolge wichtig um Knakser zu vermeiden und korrekte dekomprimierung zu gewährleisten.
Also tcp-ip. Den server kann man tatsächlich in Java programmieren! Vielleicht auch Teile des 'Clients' Man müsste sich nur mit der Java-Schnittstelle zu anderen Programmen auskennen, was bei mir nicht der Fall ist ...
Die Reorganisation ist nicht soo kompliziert, dass man sie sich bis zum schluss aufheben müsste und nicht so trivial, dass sie ohne Architekturänderungen 'nachgerüstet' werden könnte :) Man kann sie ja einplanen und dann später proggen.

Ansonsten: Danke für dein Hilfe-Angebot :)

[Abe Ghiran]

Hi,

von live streaming habe ich auch gar keine ahnung, da wäre ein bißchen googlen und lernen angebracht.

Udp hat meiner Meinung nach den Vorteil, das man die Pakete sehr schnell los wird (als Sender). Bei tcp/ip dauert es u.U. zwei Minuten bis man merkt, das der am anderen Ende gar nicht mehr da ist. Außerdem ist es bei einem stream ja nicht unbedingt so schlimm, wenn mal was verloren geht. Deswegen würde ich die Daten per udp verschicken und dann über tcp könnten die registrierten clients ja ab und an so eine Art "keep alive" message senden, um zu zeigen "ja ich bin noch am leben und will weiter den stream empfangen".
Die Reihenfolge könnte man doch einhalten, in dem man jedem Paket eine fortlaufende Nummer mitgibt und der client nur pakete abspielt, die eine höhere Nummer haben als die vorhergehenden.
Mit der dekomprimierung könnte es dann natürlich tatsächlich probleme geben, hmmm. Ich hab keine Ahnung wie mp3 aufgebaut ist, vielleicht steckt das ja auch fehlende Daten einfach weg? So wie bei videos, das der player dann einfach den nächsten key frame sucht und dann von an weiter abspielt.

Für die Schnittstelle java/native Sachen gibt es ja das jni. Aber ich glaube es ist auf client Seite einfacher, wenn man das dann wirklich in c/c++ programmiert, zumindest solange du das wirklich als winamp plugin machen willst.

Eine andere Möglichkeit lokal zwischen zwei Anwendungen Daten auszutauschen, wäre natürlich auch wieder das Netzwerk. D.h. man ließe lokal eine Art proxy laufen, der die Daten empfängt, puffert und weiterleitet. Der kann dann in java oder c/c++ geschrieben sein, völlig beliebig. Und winamp connected dann über localhost zu diesem Proxy, um den stream zu empfangen. Dann könnte man vielleicht soweit gehen, das dieser Proxy einen "richtigen" winamp kompatiblen stream zurückgibt, so das man für winamp speziell gar nichts mehr programmieren muß. Und winamp würde von dem Verteilungsmechanismus gar nichts merken.

Grüße, Jan

[ethrandil]

hmm letzteres ist eine echt gute Idee :)
Dann kann man wohl auch ganz auf c++ verzichten ...
mal sehen, wie das shoutcast-protokoll so aussieht ...