"Till Wollenberg" wrote:
Ich frage mich allerdings, ob man zwangsläufig per fork() eine Child-Instanz erzeugen muß? Der Daemon muß nur mit einem "Client" zur gleichen Zeit arbeiten können.
Die fork()-erei ist in diesem Fall dazu gut, daß sich der Dämon aus eigener Kraft in den Hintergrund verabschiedet. Das ist für solche Zwecke üblich, aber natürlich ist es auch möglich, stattdessen immer durch ein "&" hinter dem Kommando dafür zu sorgen, daß es im Hintergrund läuft. Für einen Dämon gehört es aber eigentlich zum guten Ton, das selbst zu tun (plus die ganzen anderen schon erwähnten Kleinigkeiten, die nötig sind, um einen Prozess zu einem richtigen Dämon zu machen). Für das Bedienen mehrerer Clients sind meistens ohnehin Threads sinnvoller als mehrere Prozesse, da der Aufwand geringer ist.
Was passiert allerdings, wenn doch ein zweiter Client versucht, per UDS eine Verbindung herzustellen? Ist die Pseudo-Datei dann wie bei einem Schreibzugriff gesperrt?
Nein. Der Server bindet sich an den Socket, ruft listen() auf und wartet dann mit accept() auf ankommende Verbindungen. Jedesmal erhält er einen neuen Filedescriptor, und mit dem bearbeitet er die einzelne Verbindung. Gleichzeitig kann er aber mit dem Original-Filedescriptor immer noch mit accept() auf weitere ankommenende Verbindungen warten. (Ich bin mal von einem verbindungsorientierten Protokoll ausgegangen. Für Datagram-Sockets entfällt das Problem ohnehin, da es keine feste Verbindung mit einem bestimmten Client gibt.) Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org - eilert@linuxfreak.com http://www.informatik.uni-bremen.de/~eilert/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo! Eilert Brinkmann schrieb:
"Till Wollenberg" wrote:
Ich frage mich allerdings, ob man zwangsläufig per fork() eine Child-Instanz erzeugen muß? Der Daemon muß nur mit einem "Client" zur gleichen Zeit arbeiten können.
["& ist unsauber"]
Ich werde wahrscheinlich doch auf & zurückgreifen, um meinen "Daemon" in den Hintergrund zu befördern. Dieser Daemon ist nur ein Teil eines Projekts, und es würde sehr viel Zeit erfordern, mich in alle Feinheiten der Daemon-Programmierung einzuarbeiten. Leider habe ich als Schüler auch keine 80 DM für ein passendes Buch.
Was passiert allerdings, wenn doch ein zweiter Client versucht, per UDS eine Verbindung herzustellen? Ist die Pseudo-Datei dann wie bei einem Schreibzugriff gesperrt?
Nein. Der Server bindet sich an den Socket, ruft listen() auf und wartet dann mit accept() auf ankommende Verbindungen. Jedesmal erhält er einen neuen Filedescriptor, und mit dem bearbeitet er die einzelne Verbindung. Gleichzeitig kann er aber mit dem Original-Filedescriptor immer noch mit accept() auf weitere ankommenende Verbindungen warten. (Ich bin mal von einem verbindungsorientierten Protokoll ausgegangen. Für Datagram-Sockets entfällt das Problem ohnehin, da es keine feste Verbindung mit einem bestimmten Client gibt.)
Um mehrere Verbindungen zu bedienen, müßte ich also wieder mit mehreren Prozessen oder Multi-Threading arbeiten. :( Wenn mein Daemon (eine Art Mini-Datenbank) jedoch immer nur sehr kurze Verbindungen hat (Anfrage -> Antwort -> Schluß), könnte man dann von Daragrammen sprechen? Zum Schluß nochmal zu den Sockets: man findet dazu fast nichts mit den gängigen Suchmaschinen. Nach langer Suche bin ich jedoch auf die folgenden zwei URLs gestoßen, bei denen sich Beispielprogramme finden: http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html http://www.cs.toronto.edu/~maclean/csc209/Fall99/ Falls in ferner Zukunft jemand diesen Thread liest, nützt es ihm vielleicht. ;-) Gruß, Till. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Till Wollenberg wrote:
Hallo!
Eilert Brinkmann schrieb:
"Till Wollenberg" wrote:
Ich frage mich allerdings, ob man zwangsläufig per fork() eine Child-Instanz erzeugen muß? Der Daemon muß nur mit einem "Client" zur gleichen Zeit arbeiten können.
Um mehrere Verbindungen zu bedienen, müßte ich also wieder mit mehreren Prozessen oder Multi-Threading arbeiten. :(
Nicht unbedingt -- Es geht auch anders. [Sonst gäbe es unter Linux kaum Daemons, da nur die wenigsten multi-threaded sind, bez. sich forken. Vor nicht allzu langer Zeit (unter libc4 und libc5) gab es unter Linux noch keine Threads :)] Es genügt, die einem select(2) übergebenen fdsets richtig aufzusetzen, zu verwalten, den Rückgabestatus von select(2) auszuwerten und dann entsprechend verzweigen (siehe man 2 select, erweitere mal das dort angegebene Beispiel.).
Wenn mein Daemon (eine Art Mini-Datenbank) jedoch immer nur sehr kurze Verbindungen hat (Anfrage -> Antwort -> Schluß), könnte man dann von Daragrammen sprechen?
Nein. Mit Datagrammen im umgangssprachlichen Sinne ist eigentlich immer das UDP-Protokoll gemeint.
Zum Schluß nochmal zu den Sockets: man findet dazu fast nichts mit den gängigen Suchmaschinen. Nach langer Suche bin ich jedoch auf die folgenden zwei URLs gestoßen, bei denen sich Beispielprogramme finden:
http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html http://www.cs.toronto.edu/~maclean/csc209/Fall99/
Dann wirf mal einen Blick auf O'Reilly's Web/ftp-Site (www.ora.com bzw. ftp.ora.com) und suche nach John Bloomer's Buch "Power Programming with RPC". Auch wenn dieses Buch nicht das neueste ist und etwas weiter geht als Du es brauchst, gibt es eine recht ausführliche Einführung in die Socket-Programmierung und Demos im Quellcode. Ansonsten solltes Du es in Erwägung ziehen, mal den Quellcode einiger Daemons zu analysieren (Suche nach select im Quellcode von einfachen Daemons -- Nicht gerade im apache :) ). Ralf --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Till Wollenberg wrote on Tue, Oct 24, 2000 at 15:16 +0200:
["& ist unsauber"]
Ich werde wahrscheinlich doch auf & zurückgreifen, um meinen "Daemon" in den Hintergrund zu befördern. Dieser Daemon ist nur ein Teil eines Projekts, und es würde sehr viel Zeit erfordern, mich in alle Feinheiten der Daemon-Programmierung einzuarbeiten.
Welche Feinheiten eigentlich? fork(2) und setsid(2) :) ? Aber wenn Du "&" benutzt, benutze lieber gleich man 8 setsid Macht Daemon von Shell aus, sollte genau das sein, was Du brauchst.
Leider habe ich als Schüler auch keine 80 DM für ein passendes Buch.
Brauchst Du ja auch nicht. Brauchst Dir ja nur irgenteinen Daemon im Quelltext anschauen. Durch OpenSource lernt man ne Menge!
Um mehrere Verbindungen zu bedienen, müßte ich also wieder mit mehreren Prozessen oder Multi-Threading arbeiten. :(
Nein, Du kannst es auch asyncron machen, in dem Du read eben nur aufrufst, wenn select gezeigt hat, daß da Daten da sind. Ein sehr schönes, aber großes Beispiel hierfür ist Squid. Aber ein kleines fork() ist viel viel einfacher als asyncrones I/O, also lieber das fork einbauen.
Wenn mein Daemon (eine Art Mini-Datenbank) jedoch immer nur sehr kurze Verbindungen hat (Anfrage -> Antwort -> Schluß), könnte man dann von Daragrammen sprechen?
Wenn da UDP verwendet wird --> Datagramme (UDP: User Datagram Protocol) und nicht TCP, dann ja. Sobald es eine Verbindung gibt, ist's keine UDP "Verbindung", denn UDP ist verbindungslos...
Zum Schluß nochmal zu den Sockets: man findet dazu fast nichts mit den gängigen Suchmaschinen. Nach langer Suche bin ich jedoch auf die folgenden zwei URLs gestoßen, bei denen sich Beispielprogramme finden:
Suche nach unix socket faq
Falls in ferner Zukunft jemand diesen Thread liest, nützt es ihm vielleicht. ;-)
Bestimmt :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (4)
-
corsepiu＠faw.uni-ulm.de -
eilert＠Informatik.Uni-Bremen.DE -
steffen＠dett.de -
wollenberg＠arcormail.de