Kleiner Chatserver: Threads oder Multiplex?

[Tamara]

Hi

Ich soll einen kleinen Chatserver schreiben, maximale Teilnehmerzahl 150 Leute. Ist das noch sinnvoll mit Threads zu lösen (da kenne ich mich aus) oder muß da schon Multiplex her (da kenne ich mich noch nicht aus :wink: ).

Danke für alle Antworten
Tamara

 

[Grizzly]

[...]oder muß da schon Multiplex her[...]

Kann mich mal einer Aufklären, was Multiplex ist? :bahnhof:

 

[Illuvatar]

[...]oder muß da schon Multiplex her[...]

Kann mich mal einer Aufklären, was Multiplex ist? :bahnhof:

Weiß ich auch nicht, aber ich denke, es ist mit Threads gut machbar.

 

[Dante]

Multiplex kenne ich so auch nicht, aber ich denke mal ermeint das er eine Nachricht an mehrere Clients schicken will?

Problem ist ja das man für eingehenden Verkehr vom Client eh einen Socket braucht, damit wäre es warscheinlich sinniger das dann auch gleich über den Socket zu machen... Da 150 gleichzeitige Verbindungen Threads eh vorraussetzen ist die Antwort eigentlich klar

 

[Tamara]

Multiplex kenne ich so auch nicht, aber ich denke mal ermeint das er eine Nachricht an mehrere Clients schicken will?

Genau.

Und beide Lösungen laufen über Sockets. Bei Multiplex sind die Verbindungen aber nicht-blockierend und werden allesamt aus einem Thread bedient, in dem ein Selektor zwischen den einzelnen Kanälen hin- und herschaltet.
Daß 150 Verbindungen über Threads laufen können, weiß ich auch. Meine Frage geht dahin, ob das auch effizient ist?

 

[Grizzly]

[...]Bei Multiplex sind die Verbindungen aber nicht-blockierend und werden allesamt aus einem Thread bedient, in dem ein Selektor zwischen den einzelnen Kanälen hin- und herschaltet.[...]

Habe ich jetzt zwar nicht verstanden, aber wahrscheinlich meinst Du damit einen Broadcast über UDP. Wenn alle Chat-Clients immer online sind und sich noch im selben Netz befinden, ist das sicher das einfachste. Ansonsten sind mehrere Threads mit mehreren Verbindungen besser.

 

[Dante]

nein, warscheinlich läuft das so, das ein thread ne referenz auf alle x verbindungen hat und die dann nacheinander bedient.

Ist sicher keine so dumme Idee, wenn sich denn der Verwaltungsaufwand (also welcher socket bekommt die nachricht und welcher nicht) lohnt.

 

[Freddy]

Überall, wo ich etwas über java.nio (eben dieses Gemultiplexe) lese, wird empfohlen, dies anstelle von Threads zu benutzen, da pro Thread mindestens 700KB RAM belegt werden. Ebenfalls entfällt der Aufwand der Synchronisierung. Allerdings hat man das Problem, dass die Requests hintereinander, und nicht (praktisch) parallel bearbeitet werden, was zur Folge hat, dass der Server bei längeren Rechenarbeiten (z.B. eine Schleife mit vielen Iterationen) oder auch Datenbankzugriffen komplett hängt. Diese Aktionen müsste dann wiederum doch in Threads (+ Synchronisierung) auslagern und sich ein eigenes Scheduling-API schreiben, das den Weg der Daten Client -> ServerThread -> ExternerThread und umgekehrt (Stichwort Producer/Consumer) steuert.
NIO einzusetzen ist also etwas komplex, und wenn genug RAM zur Verfügung steht bzw. die Anwendung sowieso keine hohen Lasten aushalten muss, kann man ruhig auf Threads zurückgreifen und sich Arbeit sparen. 150 Chatter sind nicht viel, sagen wir, ein Chatter postet durchschnittlich alle 7 Sekunden etwas, das wären dann 21 Anfragen pro Sekunde, 21 * 900KB (Thread + Objekte) sind 19 MB Speicher, ich denke, damit sollte man gut hinkommen.

 

[Grizzly]

[...]150 Chatter sind nicht viel, sagen wir, ein Chatter postet durchschnittlich alle 7 Sekunden etwas, das wären dann 21 Anfragen pro Sekunde, 21 * 900KB (Thread + Objekte) sind 19 MB Speicher, ich denke, damit sollte man gut hinkommen.

Ein Thread also pro Nachricht? Ist es nicht sinnvoller ein Thread pro Client zu starten, der dann die Verbindung versorgt (Daten vom Client empfangen und an das Innenleben weiterreichen, Daten aus dem Innenleben bekommen und an den Client senden; beides vielleicht mit eine Queue?) ?

 

[meez]

Ich würd schon eine Art Multiplex nehmen....
Am besten stellst du alle requests in eine Queue, und arbeitest diese Queue mit z.B.: 5 Worker Threads ab...

 

[Freddy]

Ein Thread also pro Nachricht? Ist es nicht sinnvoller ein Thread pro Client zu starten, der dann die Verbindung versorgt (Daten vom Client empfangen und an das Innenleben weiterreichen, Daten aus dem Innenleben bekommen und an den Client senden; beides vielleicht mit eine Queue?) ?

Dann wird der meiste Speicher von wartenden Threads verbraucht, also 150 Threads. Wenn man einen Threadpool nimmt, und jeden Request an einen der Threads abgibt, dann kommt man vielleicht mit 30 Threads aus (jedenfalls bei einem Webchat).

 

[Isaac]

Auf jedenfall Zeitmultiplex. Mit Threads machst du dich unglücklich und es ist auch mit Kannonen auf Spatzen geschossen.

Natürlich braucht man trotzdem ein paar Threads damit nix hängt aber um die Clients zu bediehnen reichen ein paar Threads die sich alle angemeldeten Clients teilen und die dann per Queue abarbeiten.

 

[Freddy]

Wieso macht man sich mit Threads unglücklich bzw wieso sind sie das falsche Kaliber?

 

[Isaac]

Weil mit jedem Thread der Verwaltungsaufwand steigt. Welche Threads laufen noch, welche müssen beendet werden, welche Threads haben einen Timeout durch die URL Verbindung. Sicher kann man das so lösen aber einen eigenen Thread für jede Verbindung zum Client ist wie eine eigene Klasse für jeden Button in deiner Applikation.

Wenn du die Verwaltung sauber programmierst wirst du auch nicht unglücklich da dann alles von alleine flutscht. Aber 2 oder 3 Threads die die Queue abarbeiten sind wesentlich leichter zu überschauen und zu debuggen als 150 Threads von denen vieleicht 3 oder 4 aus der Reihe tanzen, wieso auch immer.

 

[Freddy]

Nun, ich habe einen Webchat programmiert, wo jedem Client on demand ein Thread zugewiesen wird (d.h. wenn z.B. Text gesendet werden soll). Im Leerlauf läuft hingegen nur ein Thread, und ich komme mit der Verwaltung recht gut zurecht. Und ist es bei Java-GUIs nicht so, dass Buttons in einer eigenen Klasse implementiert sind ( http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Button.html )?

 

[Isaac]

Das führt nun wohin?

 

[meez]

Nun, ich habe einen Webchat programmiert, wo jedem Client on demand ein Thread zugewiesen wird (d.h. wenn z.B. Text gesendet werden soll). Im Leerlauf läuft hingegen nur ein Thread, und ich komme mit der Verwaltung recht gut zurecht.

Was machst du, wenn du gleichzeitige 100'000 Teilnehmer hast...Dann läuft da überhaupt nichts mehr...
Es ist nicht das Problem, das es techisch nicht geht, sondern es sollte immer möglichst die perfomanteste, sauberste und skalierbarste Lösung angestrebt werden....

 

[Niki]

hallo alle zusammen, ich hab zwar nur die antworten bisserl überflogen, aber wie wärs wenn du einen eigenen JMS-Server aufsetzt, und dem zum notifizieren auf alle Clients verwendest, da gibts auch sicher irgendwelche vorgeschriebenen free-JMS-Server. die Clients müssten dann nur mehr die nachrichten an den JMS senden, und der könnte das publishen (ich hoffe ich rede da keinen schwachsinn )

 

[Daydreamer]

hallo leute, ich suche 1 oder 2 leute die mit mir zusammen ein chat machen wollen.
hab schon so meine vorstellungen.. bräuchte aber jemand der sich etwas mit java auskennt.. und noch etwas mit php..
wenn jemand da ist und interesse hat der kann sich bei mir melden undter necro200@yahoo.de