Interprocess Kommunikation - sinnvoller Weg?

Belgarad

Ich plane einen Server der via IP mehrere Verbindungen zu verschiedenen Clients haelt.
Das besondere ist dass der eigentliche Serverprocess (Parent), mit den Clients (child ueber fork() erstellt) nachrichten bidirectional austauschen muss.
d.h der parent pflegt daten die er von den childs bekommt bzw. an bestimmte childs weitergeben muss.

daher dachte ich zur prozesskommunikatin an unix_sockets, shared mem oder pipes.
problem bei shm: der speicherbedarf fuer die daten entsteht dynamisch - shm muss aber statisch angefordert werden.
unix_sockets: bei 100 childs muesste ich 100 sockets oeffnen.
pipes: scheinen die kommunikationimmer nur in eine richtung zu erlauben. daher muss ich fuer bidirektionale verbindung pro child 2 pipes aufmachen: fuer 100 childs = 200 pipes.

daher dachte ich auf das fork() (und damit auf getrennte prozesses) zu verzichten, und stattdessen auf threads zu setzten (wg. gemeinsamen datenbereich).

was meint ihr?

wischmop2

Im Prinzip sind all Deine Wege gültig und je nach Anwendungszweck auch sinnvoll. Shared Memory gilt prinzipiell immer als sehr performat im Gegensatz zum "MessagePassing"-Ansatz (das sind z.B. Pipes oder Sockets). Andererseits hast Du beim SharedMemory wahrscheinlich einen grösseren Synchronisationsaufwand, also Dein Programm wird schneller unübersichtlich. Ich würde daher MessagePassing verwenden. Zu Unix-Sockets kann ich nichts sagen, da ich nicht weiss, was das ist (aber vielleicht kannst Du mich aufklären). Unter Sockets stelle ich mir immer einen grösseren Overhead vor. Die Aussage mit jeweils 2 Filediskriptoren pro Ende (Server/Client) um eine bidirektionale Verbindung über Pipes zu realisieren ist im Prinzip richtig. Obwohl ich darin kein Problem sehe, kannst Du auch aus zwei FD's einen machen. Es gibt eine Funktion, die daraus quasi einen Socket macht, aber mir fällt sie jetzt nicht ein (evtl in der Art wie int fd2socket(int in, int out), oder ähnlich). Dann bräuchtest Du Deinem Client nur noch einen Wert zu übergeben, aber das ist (denke ich mal) eher nebensächlich.

Belgarad

@wishmmop
unixsockets laufem auf demselben system ueber einen dateidescr. und oeffnen meist in temp einen connectpoint.
sockettyp: AF_UNIX

tcpip sockets verbinden uebers netzwerk.
sockettyp: AF_INET

mir gings primaer um die anzahl der pipes/sockets etc. die ich oeffnen muss, wenn der parent z.b. >100 childs startet.
dann laufe ich bei maximal 255 filedescriptoren auf einem standard linux kernel schnell ans limit.

DrGreenthumb

Nicht das ich da die große Erfahrung hätte, aber generell würde ich fork() nur nehmen, wenn die Prozesse voneinander unabhängig laufen oder sich auf Kommunikation mittels Signale beschränken.

Wenn schon so eine Synchronisierung nötig, dann lieber gleich Threads.

friss das was ich dir gebe, halbe portionen gibt's nicht.

tschuldigung, sollte eigentlich zum Thema Sockets + ACE sein.

mellOwmOe

gibt es denn performance probleme bei UNIXSockets > 200 ?

wischmop2

Hmmm, wie wahrscheinlich hälts Du denn den Fall, dass mehr als 100 Clients bei Deinem System laufen müssen? Im Endeffekt lässt sich für alles ein Fall konstruieren, bei dem es nicht mehr läuft, da irgend ein Limit überschritten wurde (z.B. mehr als 65536 PID's). Ansich klingt für mich die Zahl 100 schon sehr hoch, aber das muss ja nichts heissen. Man sollte natürlich immer auf die Rückgabewerte der verwendeten Funktionen achten, um z.B. darauf zu reagieren, falls ein Limit überschritten wurde. Zur Not muss der 127'te Client sofort wieder gekillt werden und eine Meldung ausgegeben werden, dass ein limit erreicht wurde. Wenn 100 Clients reichen, würde ich Pipes bzw. UNIX-Sockets nehemn.

Belgarad

wischmop2 schrieb:

Hmmm, wie wahrscheinlich hälts Du denn den Fall, dass mehr als 100 Clients bei Deinem System laufen müssen?

Finde ich nicht ungewoehnlich. denk mal an programme a la edonkey xmule, etc.
was wird da an verbindungen gehalten...

Ich hab meine CLient Serveranwendung mit Threads und darin enthaltenen Messageques gelösst !

War eigentlich sehr einfach und komfortabel !

Belgarad

dakjono schrieb:

Ich hab meine CLient Serveranwendung mit Threads und darin enthaltenen Messageques gelösst !

War eigentlich sehr einfach und komfortabel !

Freut mich .
War deine anwendung mit meiner vorgabe vergleichbar?