Non-Threaded Server?

[tuxedo]

Hallo zusammen,

die klassiche vorgehensweise bei Serverprogrammen ist ja, jeden Client der sich andockt, in einen eigenen thread zu stecken.

Dies wäre dann ein Threaded-Server....

Aber es gibt auch "Non-Threaded-Server"...
Laut diversen Quellen im Netz sind die zwar "etwas" langsamer, aber man muss sich weniger bzw keine Gedanken bzgl der Synchronisation machen. Auch wäre es hier einfacher eine "Momentaufnahme" des Systems zu machen. Fehleranayse müsste so um ein vielfaches einfacher sein...

Trotz dass diese Technik etwas langsamer zu sein schein kann sie sooo schlecht nicht sein. Schließlich arbeitet unter anderen der Apache-Webserver nach diesem Model (wenn man nicht zufällig ein anderes MPM-Modul benutzt).

Jetzt hat sich mir die Frage gestellt:
Wie sieht so ein non-threaded Server denn aus ?
Clientanfragen müssen ja irgendwie in eine Reihe gestellt und nacheinander abgearbeitet werden. So stell ich mir das zumindest vor.
Aber wie macht man sowas am geschicktesten?

Ich hab google gefragt, in diversen Dev-Seiten geblättert und bin nicht fündig geworden... Überal steht nur dass es sowas gibt, aber ein Beispiel oder eine tiefergehende Erklärung hab ich nicht gefunden.

Kennt jemand ne Seite auf der sowas prinzipiell erklärt ist? Codebeispiele (auch im Pseudocode) wären auch sehr interessant.

Einen konkreten verwendungszweck für einen non-threading-server hab ich zwar noch nicht, aber vielleicht verwend ich das dann ja im nächsten Client-Server-Programm

Gruß
Alex

 

[Guest]

Multithreaded

1 Warten auf Anforderung
2 Annehmen der Anforderung
3 Fork (Weitere Kommunikation läuft im getrennten Thread/Prozess)
4 Zurück zu 1

for(;;)
{
  Socket client = serverSocket.accept();
  // weitere Verarbeitung im getrennten Thread, im ConnectionHandler
  MyThreadPool.enqueue(ConnectionHandler.createInstance(client));
  ...
}

Singlethreaded

1 Warten auf Anforderung
2 Annehmen der Anforderung
3 Kommunikation läuft im gleichen Thread
4 Zurück zu 1 oder "Der Nächste bitte"

for(;;)
{
  Socket client = serverSocket.accept();
  // weitere Verarbeitung hieher.
  // Es wird keine Verbindung akzeptiert, solange 
  // die aktuelle Verarbeitung nicht abgeschlossen ist
  ...
}

Bei einer durchschnittlichen Antwortzeit von sagen wir mal 50ms, würde der
zwanzigste bereits über eine Sekunde lang warten, bis er eine Antwort kriegt.
Durch Multithreading wird dies, im Rahmen der verfügbaren Übertragungskapazität,
umgangen und die verfügbaren Ressourcen wie CPU, RAM etc. werden besser
ausgelastet.

Das mit dem "vielleicht verwend ich das dann ja im nächsten Client-Server-Programm"
kannst du gleich vergessen. Es wird grauenhaft langsam.

 

[Guest]

Noch etwas... vielleicht ist der folgende Artikel für dich interessant
http://javamagazin.de/itr/online_artikel/psecom,id,127,nodeid,11.html

 

[Guest]

Hmm, wenn man so sieht leuchtets ein.

Aber warum arbeitet dann Apache mit so Zeugs? Okay, man könnte jetzt sagen dass da nicht so viele Anfragen eingehen. Aber das MPM Modul kann auch mit sehr großen anfragen noch gut umgehen und gute Antwortzeiten liefern ...

Von nem bekannten der mal bei Ericson in der Entwicklung gearbeitet hat weiß ich dass dort die ganz großen digitalen Telefonanlagen auch nach dem Prinzip arbeiten. Ein Grund den er mir nennen konnte war: Bei so großen Systemen ist einfach nichtmehr machbar Fehleranalysen zu machen da man bei Thread nicht so gut/keinen Moment-Snapshot machen kann.

Gruß
Alex

 

[Guest]

Dass der Apache singlethreaded arbeitet , glaube ich eher nicht. Es sei dann es ist
die reine "Anfrageannahme" gemeint (wie in den Beispielen oben; die accept-Schleife).
Wenn ich mir die Beispiele in JavaMagazin anschaue, dann fällt mir auf, dass dort die
Anfrageverarbeitung, also die eigentliche "Bussinesslogik", in den Beispielen
singlethreaded läuft (doSomeWork(); und handleClientRequest(clientSocket))

In meinem Beispiel habe ich unterstellt, dass es einen Threadpool gibt, der die
eigentliche Verarbeitung der Anfrage übernimmt bzw. die ConnectionHandler
auf die verfügbaren Threads verteilt (Stichwort: Thread scheduling). Ist die Anfrage
abgearbeitet, wird das Thread freigegeben bzw. wieder im ThradPool als 'verfügbar'
markiert und kann wieder verwendet werden.

Dieses Thema wird ziemlich ausführlich in "Java Threads, Third Edition" behandelt.

 

[tuxedo]

Zum Apache:

Dieses Multi-Processing-Modul (MPM) implementiert einen im Voraus forkenden Webserver ohne Thread-Unterstützung, der Anfragen auf ähnliche Weise behandelt wie der Apache 1.3. Es ist für Angebote geeignet, die aus Kompatibilitätsgründen mit nicht-Thread-sicheren Bibliotheken Threading vermeiden müssen. Es ist außerdem das geeignetste MPM, um jede Anfrage isoliert zu bearbeiten, so dass Probleme mit einem einzelnen Prozess keinen anderen beeinflussen.

Ich werd mir das Thema mal zu gemüte führen ...

- Alex

 

[Guest]

Zum Apache:

Dieses Multi-Processing-Modul (MPM) implementiert einen im Voraus forkenden Webserver ohne Thread-Unterstützung, der Anfragen auf ähnliche Weise behandelt wie der Apache 1.3. Es ist für Angebote geeignet, die aus Kompatibilitätsgründen mit nicht-Thread-sicheren Bibliotheken Threading vermeiden müssen. Es ist außerdem das geeignetste MPM, um jede Anfrage isoliert zu bearbeiten, so dass Probleme mit einem einzelnen Prozess keinen anderen beeinflussen.

Ich werd mir das Thema mal zu gemüte führen ...

- Alex

OK, fork muss in Java erst erfunden werden.

 

[tuxedo]

fork ? --> bitte kurz erklären

 

[tuxedo]

okay, habs:

http://de.wikipedia.org/wiki/Fork

Also liegts daran dass das so prima beim Apache geht...
d.h. auf Java-Seite gibts tatsächlich nur die thread-methode ...

thx

Alex

 

[tuxedo]

Guckt mal was ich eben zufällig gefunden hab:

http://jniosocket.sourceforge.net/

...have been successfully tested with 13000 connections on 2 Xeon machines.

- Alex