Re: How to implement a daemon like 'xinetd'?

Real message restored

phil-news-nos...@xxxxxxxx wrote:
On Thu, 26 Jun 2008 20:18:35 +0200 Johannes Bauer <dfnsonfsduifb@xxxxxx> wrote:
| phil-news-nospam@xxxxxxxx schrieb:
|
|> The subprocess listens (it inherited that
|> listen process from the master but I do not know if another listen() call by
|> the subprocess is needed) for other connections. If connections are to be
|> handled all in one process (multiplexed or multithreaded), it will do so.
|
| I don't know why you think it needs to be so complicated. For TCP the
| sequence is socket(), bind(), listen(), accept(). socket() creates the
| unconnected socket, bind() binds it to an interface and port, listen()
| sets up listening and sets the number of connections which are buffered
| while unhandled. Only accept() is blocking and then returns the
| connection in question.

What you are describing does not complete the job for all cases. In cases
where a single process handles all the connections, you need to add the
extra step of transferring the new sockets to that process. Simply
forking a process for every connection does not make those cases work.
Usually, such daemons run standalone, not via inetd. But xinetd supposedly
supports this. I'm curious what details it might be doing to accomplish
this in a reliable way.

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
.

Relevant Pages