Designfrage: Audiochat

[tuxedo]

Hallo zusammen,

Ich muss eine "Art" Voip/Skype/Teamspeak-Lösung basteln:

Das ganze soll eine Client-Server-Anwendung sein: Der Server wartet auf Verbindungen von Clients. Der Server soll sowas wie Channels ermöglichen. In Teamspeak kann ein Client immer nur in einen Channel joinen. Hier soll ein Client aber in mehrere Channels gleichzeitig können (zumindest reinhören, ist noch nicht sicher ob er auch in allen gleichzeitig sprechen können muss/soll).

Die Sprachverbindung soll mit diversen Codecs komprimiert werden. Ist aber ne andere Geschichte...
Ich überlege jetzt schon die ganze Zeit was wohl besser ist:

1te Variante)

Alle Clients bauen eine Verbindeung mit dem Server auf und senden diesem ireh Sprachstreams (bei 100 verbundenen Clients gehen beim Server 100 Sprachstreams ein). Der Server dekodiert die estmal (sind ja mit diversen Codecs komprimiert). Dann werden die Streams, je nach Channelzuteilung zusammengemischt (clients können gleichzeitig sprechen um z.B. den Gesprächspartner ggf. zu unterbrechen), wieder komprimiert und an die jeweils teilnehmenden Clients wieder ausgeliefert.

Ich seh darin nur folgendes Problem:
Der Server hat die ganze Arbeit: Er muss _alle_ Streams die er bekommen dekodieren, entsprechend mischen und wieder ausliefern. D.h. der meiste Traffik und die meiste Arbeit fällt beim Server an.
(Im komprimierten Zustand mischen geht nur dann wenn das pro Codec implementiert wird. Ist wohl extrem aufwendig und auch Codec-Abhängig. Ich denke in den allermeisten Fällen/Codecs wird man nicht drum rum kommen den Stream zu dekodieren bevor man ihn als PCM-Stream mischt und wieder komprimiert.)

2te Variante)

Der Server führt nur Buch darüber wer mit wem in welchem Channel spricht. Die Clients senden sich untereinander die Streams. D.h. jeder Client weiß die Adresse der anderen Clients im Channel und sendet an diese seinen Sprachstream:
Sind Beispielsweise 10 Leute in einem Channel und einer davon spricht, so muss dieser eine seinen Sprachstream an 9 Leute verteilen. Damit fällt die 9-fache Bandbreite des Sprachstreams an. Gehen wir von 5kbyte aus (und das ist wohl schon optimistisch gedacht), dann haben wir 9*5kbyte=45kbyte Upstream beim Sprecher. DSL3000 wäre damit schon überfordert.

Das ganze hätte jedoch den Vorteil dass der Server extrem viele Teilnehmer verkraftet da er selbst ja nur als Benutzerverzeichnis fungiert. Die Arbeit liegt dann verteilt auf den Clients.

Ergänzung/Notiz)

Wer Teamspeak schon mal benutzt hat weiß sicher wovon ich rede: Wenn in einem Channel 3 und mehr Leute gleichzeitig sprechen versteht man gar nix mehr. Man könnte sich also durchaus Bandbreite sparen wenn nur dann Traffgik anfällt wenn jemand spricht. Jedoch kommt dann ein neues Problem auf: Der Stream wird, wenn das eingestellt Level am Mikrofon nicht entsprechend überschritten wird, unterbrochen. D.h. die Gegenseite die den Stream empfängt kann da auch nichts mehr dekodieren. D.h. die dekodierung müsste ebenfalls unterbrochen werden. Hier hab ich aber noch nix getestet und mir noch nix überlegt. Wenn jemand hierzu ne Idee her: Als her damit

----

Leider weiß ich noch nichts über die Netzwerkanforderungen und ob die Sache im lokalen Netzwerk oder übers Internet laufen soll und welche Bandbreite zur Verfügung steht, bzw. welche mind. zur vergugung stehen sollte.

Ich weiß nur dass Teamspeak serverseitig die Streams mischt (1te Variante).

Wie Skype das macht weiß ich nicht genau. Ich weiß nur dass hier eine P2P Technik benutzt wird und so die Netzwerklast verteilt wird. Für ein 1-to-1 Gespräch fallen hier etwa 6kbyte/sek an. Wie das bei Konferenzen mit mehreren Teilnehmern ist weiß ich nicht (kann ich auch nicht testen, hab noch zu wenig Leute in Skype die gleichzeitig online sind).

Nun, was will ich jetzt von euch? Hmm. Gute Frage. Ich wollte hier nur mal ne Gesprächsrunde anzetteln wie man sowas am besten angeht. Vielleicht hat der eine oder andere ja noch einen brillianten Einfall oder Tipp, etc...

Hoffe dass sich hier der eine oder andere aufhält der hier gerne mitdiskutiert.

Gruß
Alex

 

[doctus]

ich persönlich würde dir zum ersten ansatz raten. der server hat dann zwar sehr viel arbeit, entlastet aber die clienten. teamspeak wird ja hauptsächlich für MMORPG's, etc. genutz, die dem Clienten in der Regel schon jede Menge Leistung ziehen. Dem Clienten dann noch die Ganze Arbeit aufzubrummen, dürften viele nicht mehr mitmachen.

Lg doctus

 

[Gast]

ich würd nem light-weight server den vorzug geben und beide systeme mischen.

der client sendet genau einen stream an den server (was der nutzer ins mic spricht halt) und dieser leitet den stream weiter an alle clients, die ihn empfangen können (d.h. nutzer im selben channel, deren speaker nicht auf mute gestellt sind)

die streams zusammenzufügen sollte nicht sonderlich aufwendig sein, denn dekodiert werden müssen sie ja eh. diese last allerdings einem server aufzuhalsen, wird sehr schnell zu nem engpass führen. denn mit einem server sind nicht nur 10 oder 20 leute verbunden, sondern sehr wahrscheinlich sehr viele mehr. und gerade die für audio dekodierung wichtige hohe cpu leistung, ist auf anwender pcs viel eher anzutreffen, als auf dem üblichen standardserver.

 

[tuxedo]

@Gast

Das ist ja mal ne tolle Idee... Da wär ich glaub nicht so schnell drauf gekommen.

Einen Stream zu dekodieren ist i.d.R. kein so großes (CPU-)Problem. Nehmen wir an man begrenzt die maximale Anzahl Sprecher in einem Channel auf 3 (mehr macht ja keinen Sinn, vielleicht noch ein Channel-Moderator der ein vorrecht hat oder so). Dann sind pro Channel im worst-case 3 Streams zu dekodieren, zu mischen und wieder zu kodieren.
Nehmen wir weiter an der Server hat 20 Channels... Dann wären das schon 60 Dekodiervorgänge und 20 kodiervorgänge und auch 20mal mischen. Das ist für den Server, je nach weiterer Auslastung (Webserver, Mailserver, ...) eine recht hohe Belastung... (je nach Codec).

Nur den Traffik auf den Server zu verlagern ist vermutlich keine so schlechte Idee. Machen wir mal ein Zahlenbeispiel:

Ein komprimierter Stream benötigt (angenommen) 5kbyte/sek. Gehen wir von 20 Channels und jeweils 3 Sprechern aus. Das macht dann 60 Streams mit je 5kbyte/sek was insgesamt 300kbyte/sek macht. Für einen Root-Server absolut kein Problem.
Drehen wir den Spieß mal um. Legen wir die verfügbare Bandbreite für den Server mal auf 1MB/Sek fest. Das macht dann etwa 200 Streams. Gehen wir da wiederum vom Worst-Case aus sind das über 60 Channels. Denke das ist ne gute Zahl. Da lässt sich dann auch mit der max. Anzahl Sprechern pro Channel noch variieren. Und die meisten Root-Server oder Server in einem Firmennetzwerk haben 100Mbit mit etwa 8..10MB/sek ... Da ist also durchaus noch "Platz".

Für die Online-Gaming-Sache:
Das ist nicht zwingend die Zielgruppe. Zielgruppe ist bis dato mehr die Business-Gegend wo es auf Audiokonferenzen ankommt. Aber es wär natürlich auch cool das ganze dann für Spieler anbieten zu können. TS3 lässt schließlich schon ewig auf sich warten und TS2 ist ja anfällig wie ein offenes Scheunentor. Aber das ist ein anderes Thema.

Aber gehen wir mal von der Spiele-Zielgruppe aus:

Pro Channel 3 Sprecher mit 3kbyte/sek verursacht beim Client einen Downstream von 15kbyte/sek.. Das sollte bei heutigen DSL-Anschlüssen eigtl. zu keinem großen Problem führen. Ich weiß, bei 3D-Shootern kommt es auf die letzte Nachkommastelle in der Latenzzeit zum Spiele-Server an. Aber wie ermittelt man jetzt eine eventuelle Erhöhung der Latenzzeit zu einem Gameserver wenn nebenher noch 15kbyte/sek downstream laufen? *rätsel* Außer "try&error" fällt mir da nix ein. Aber ich kann mir fast nicht vorstellen dass der Unterschied von einer auf zwei Onlineverbindungen so übel ist. Für MMORPGs ist das eh unkritisch. Da kann man locker mit mehreren hundert Millisekunden Latenzzeit spielen. Okay, irgendwann ist da auch der Spielspaß im Keller. Aber obs jetzt 200 oder 250ms sind ist sogesehen wurscht.

Auch das dekodieren der Streams sollte clientseitig kein großes Thema sein. Das dekodieren eines einzigen Streams (ich habs mal mit dem Java-Speex-Codec getestet) fällt in der CPU-Last gar nicht auf. Werde es noch mit mehreren Streams simultan versuchen. Aber ich glaube bei einer Zahl <5 ist das kein wirkliches Thema.

Wer anderer Meinung ist: Würde mich über eine detailierte Begründung freuen

Gruß
Alex