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