PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Server: jeder client eigener Prozess?



mithras
07.09.02, 14:09
Hallo,
ich frage mich gerade ob bei einem Server, z.B. bei einem Chat Server für jeden Client ein Prozess aufgemacht wird. Stellt euch mal folgendes vor:

1. server ist auf modus accept.
2. client1 verbindet sich mit server und schickt ihm daten.
2. server empfängt die daten und verarbeitet sie weiter

was passiert wenn in dem moment wo der server die daten, die er von client1 empfangen hat ein weiterer client connecten und daten senden will!?

Wenn der Server nach jedem accept einen neuen Prozess für die Behandlung des clients aufmachen würde gäbs keine Probs. aber so!?

Jinto
07.09.02, 15:46
Neben Prozessen gibts auch Threads. Ansonsten: genau so wirds gemacht.

mithras
07.09.02, 17:15
d.h. der server startet wirklich für jeden connecteten client einen eigenen prozess?
aber es gibt ja system mit 100 ja 1000 clients wären das dann nicht etwas viele prozesse?

anda_skoa
07.09.02, 21:06
Man kann das auch so machen, dass ein Prozess Verbindungen entgegennimmt, den Request liest und in eine Jonqueue gibt.
Dann holt sich einer oder mehrere Prozesse dort die Request ab, behandeln sie und geben die Resultate in eine resultqueue, wo sie dann vom ersten Prozess an den entsprechenden Client gesckit werden.

Man kann den ersten Prozess natürlcih auch spalten in einen der nur Verbindungen annimmt und in eine queue gibt, wo sie dann ein weiterer (oder mehrere) bearbeiten.

Prozesse können natürlich auch als Threads ausgeführt sein.

Ciao,
_

mithras
09.09.02, 01:19
angenommen ich mach das ganze so:

1. Prozess: Daten empfangen
2. Prozess: empfangene Daten verarbeiten

(Dazwischen ne pipe oder fifo)

Das ganze läuft nun so ab:
Client1 connected zu Server, wird über 1. Prozess abgefertigt. Dann wird durch den 2. Prozess die Daten verarbeitet.

Aber was ist, wenn in der Zeit wo 2. Prozesss daten verarbeitet 1. Prozess weitere daten empfängt und diese an den zweiten prozess schicken will (über pipe) der aber noch mit dem verarbeiten von den Daten beschäftigt ist, die er von dem kürzlich davor connecteten client bekommen hat?

Wäre es dann nicht günstiger, für den client, der zum 1. Prozess connectet hat einen eigenen prozess aufzumachen. D.h. 100 Clients, 100 Prozesse aufm server?

anda_skoa
09.09.02, 15:10
Klar geht das auch.
Das andere brauchst du nur, wenn die Systemresourcen knapp werden, oder auf dem System noch andere Server laufen.

Aber 100 oder 1000 pro Server ist sicher kein Problem.

Es ist aber besser du verwendest Threads, das hat weniger Overhead und die Kommunikation ist einfacher.

Ciao,
_

Jinto
09.09.02, 17:39
Zudem gilt es zu bachten, dass die entsprechende socket Verbidnung dem zweiten Prozess/Thread übergeben wird. Ansonsten wirds nämlich keine weitere Verbindung mit dem Client mehr geben.
Zu deiner Frage:
Dann muss Prozess Nummer zwei (oder auch Nummer eins) eine Warteschlange implementieren. Ansonsten hast du ja ein immer größer werdendes Problem.
Prozess 1 wird keine neuen Verbindungen mehr annehmen, da er ja auf Prozess bis zur Beendigung des Tasks warten würde.

Wie meinst du das:
>Wäre es dann nicht günstiger, für den client, der zum 1. Prozess connectet hat
>einen eigenen prozess aufzumachen. D.h. 100 Clients, 100 Prozesse aufm server?

anda_skoa
09.09.02, 20:32
Am einfachsten ist es, wenn man einen Thread hat, der die connects annimmt, also in accept() wartet.
Dann erzeugt er für jede Connect einen Workerthread, der diese Verbindung behandelt.

Einen Threadpool und Jobqueue braucht man erst, wenn man sehr viele Connects erwartet.

Ciao,
_

DerLipper[TuX]
09.09.02, 20:57
man kann auch select benutzen...dann muss man keine thread-kontrolle einbauen.