Server Programmierung [Performance]

[Alfred]

nachdem mein alter nick leider deaktiviert wurde (Alfred)
mit meinem übergangs/neuen nick

Problem : (c/c++ )
ich schreibe an einem video+chat server(auftrag), clients werden also stetig mit video
daten versorgt sowie chatter und übrige verwaltungsadaten die in regelmäßigen
abständen hin und her gesendet werden. soweit so gut.
nun das problem, wenn ich die clients ca 10.000 oder mehr mit select() verwalte befürchte
ich ein cpu anstieg in unendliche höhen.. um dem auszuweichen könnte ich jeden client
in einen thread packen oder deamon wie unter linux/unix üblich.. das knetet mir doch
aber den ram zu? was also soll ich machen? ich dachte daran das ganze irgendwie zu mischen.. aber wenn mischen wie soll das gehen?
ich habe zwar bereitz mit sockets gearbeitet allerdings ist eine solche masse zu verwalten
neuland für mich. es macht irre spass das teil zu bauen aber irgendwie steh ich grad
wie der ochs vorm berg und hab keinen schimmer was ich machen soll.. hat jemand etwas mehr
erfahrung in der socket geschichte und kann mir einen tipp geben? tutorials jedenfalls
stellen jedenfalls einfach nur die 2 möglichkeiten vor.. (select(),fork()) oder mach ich
mir zuviel gedanken und es ist gar nicht so schlimm mit der cpu time und dem zukneten des rams?

mfg MisterIce ~ Alfred

[foobarflu]

http://www.kegel.com/c10k.html gibt nen Überblick bzgl Alternativen zu select.

10k Chat-User auf einem Rechner ist ohne weiteres möglich, 10k Video-User nicht. Die für diese Userzahlen übliche Lösung ist es, Akamai ins Boot zu holen, das sind Größenordnungen, wie sie beispielsweise bei den letzten European Music Awards auftraten.

Ansonsten kannst Du halt versuchen, ein Distributionsnetzwerk aufzubauen, das für deine Zwecke das, was akamai macht, erledigen soll:
ein masterserver streamt an mehrere Video-Proxys, diese verteilen das Video an die Clients. Zum einen versucht man so, die Last auf die Proxys aufzuteilen, zum anderen versucht man, den Proxy nahe am User zu positionieren.

Würdest Du nicht sagen, dass Du nen Auftrag programmierst hätt ich Dir glatt noch Firmen empfehlen können, die auf sowas spezialisiert sind :-)

[Alfred]

ok distrubitionsnetzwerk aufbauen wäre in dem fall overdoetzed ich denke
ich werde dann ab einer gewissen userzahl einen umstieg auf den
gennanten provider vorschlagen. ist doch ein provider ,oder? bin mir
nicht ganz sicher. ich habe mir deren webseite mal angesehn (überflogen)
und bin zu dem schluss gekommen das die ein netzwerk mit routern anbieten
ähnlich der multicast router geschichte.. ist das in etwa zutreffend? also
ich kann meine software ganz normal schreiben und ab einer gewissen größenordnung
auf einen server der genannten firma wechseln? anpassungen werden
wohl nötig werden das ist mir bewusst aber im groben ist das doch nix
anderes wie ein spezialisierter webhoster oder ?

(man verzeihe mir meine unwissenheit in dieser richtung)
wieviel videouser kann ich denn mit einem normalen rootserver versorgen?
gibt es dazu irgendwelche erfahrungswerte? ich denke biss zu einer
gewissen masse lässt sich da mit der performance sicher etwas tricksen...

mfg Misterice ~ Alfred

[butterkeks]

Wenn Authentizität nicht so wichtig ist, könntest du auch die "normalen" clients als "multicast-router" verwenden, indem ein empfangender Rechner, der geographisch nahe zu anderen gelegen ist, die Aufgabe des "Proxys" übernimmt.

Natürlich sind die Daten, die von diesem Proxy kommen, nicht mehr eindeutig authentisch (wenn der Server die clients permanent mit hashes der Originaldaten versorgt, könnte man gefälschte/fehlerhafte Bilder allerdings zumindest aufspüren, wenn auch nicht "reparieren") und die geographisch nächsten Rechner zu bestimmen ist auch nicht unproblematisch (rein automatisch kann man wohl höchstens anhand von Land und Provider gruppieren, denke ich).

Natürlich ist es vom Prinzip her das selbe, wie das vorhin beschriebene, aber in einem gewissen Rahmen (wenn sich die Gesprächspartner vorher absprechen und es für jeden "Sammelpunkt" genügend Leute gibt, die ihren upstream bereitstellen wollen, halt) könnte man damit vlt. verhindern, einen speziellen Provider benutzen zu müssen.

[foobarflu]

das die ein netzwerk mit routern anbieten ähnlich der multicast router geschichte.. ist das in etwa zutreffend?

Ja.


ich kann meine software ganz normal schreiben und ab einer gewissen größenordnung auf einen server der genannten firma wechseln?

Plan sie von Anfang an mit ein. Ohne RTSP als Protokoll werden sie Dir z.B. nicht helfen können.


wieviel videouser kann ich denn mit einem normalen rootserver versorgen?

Teil für einen ersten die maximal verfügbare Netzwerkbandbreite (und hierbei sollte man die Anbindung des Rechenzentrums beachten und nicht die versprochenen 100mbit/s) durch die durchschnittliche Rate, mit der deine Clients empfangen (~6kb/s bei ISDN-Usern, 30kb/s bei DSL).

[Alfred]

naja ok es geht primär um die verfügbare bandbreite da wird das protokoll
wohl eher zweitranig sein da das RTSP auf udp basiert..

nichtsdestotrotz ich schaus mir mal genauer an. vielen dank für die
konstruktiven hinweise. :) ich werde sobald ich bissl rumgetestet habe
mal nen feedback geben. :) thx jungs/mädls


mfg Misterice ~ Alfred