Sockets & child processes handling incoming calls

Sockets & child processes handling incoming calls

Post by Joost Roeland » Thu, 27 Feb 1997 04:00:00



Well, I've seen articles about pipes and about children and the like
in the newsgroup, so i presume this article might fit here aswell...

I have a problem writing a daemon.
I have a master process running, accepting 'calls' on a specific port,
and i like to fork the master process for each incoming call to handle
the 'request'.

The problem is: all goes well, until the daemon gets really used.
It then dies because of my accepting socket is no longer 'open' all
of sudden...  (Connection closed by peer)

help ! :-)

-----

So far for the brief description.
Here's the longer version :)

My main process opens a socket, and than waits for a connection
to arrive. This socket has got filedescriptor 'master'.
(it always turns out to be 3)

The result of an 'accept' is a filedescriptor called 'client'.
What i then do (after the accept ie), is: I let the program fork.

And that's where it gets tricky i suppose...
immediately after the fork, the parent closes 'client',
and the child closes 'master'.

The main process returns to it's 'accept' call, while the child
process handles the request....

Now, if I get a lot of requests (or maybe just when i get a request,
at a time where the previous request hadn't finished yet)
The 'master' socket suddenly closes.
(errno 104 on Linux, strerror: Connection reset by peer)

So...
* Should I let the master process wait for the child to die, before
  it can close the 'client' socket ?
* Should the child process not interfere (ie not even close) the
  'master' socket ?
*  ....  ?? :-)

Any help would ofcourse be greatly appreciated :)
And if you're so kind to reply to this article,
please reply to me by email (too) :-)

Have a nice day...
--

          /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/~~ \

          \___________________________________\_/  |
           /    Pull here for the full .sig       /
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                 Whenever you type win...
                      you loose...

 
 
 

Sockets & child processes handling incoming calls

Post by Andrew Giert » Sun, 02 Mar 1997 04:00:00


 Joost> Well, I've seen articles about pipes and about children and
 Joost> the like in the newsgroup, so i presume this article might fit
 Joost> here aswell...

 Joost> I have a problem writing a daemon.  I have a master process
 Joost> running, accepting 'calls' on a specific port, and i like to
 Joost> fork the master process for each incoming call to handle the
 Joost> 'request'.

 Joost> The problem is: all goes well, until the daemon gets really
 Joost> used.  It then dies because of my accepting socket is no
 Joost> longer 'open' all of sudden...  (Connection closed by peer)
 [...]
 Joost> My main process opens a socket, and than waits for a connection
 Joost> to arrive. This socket has got filedescriptor 'master'.
 Joost> (it always turns out to be 3)

That's not surprising, since 0,1 and 2 are already in use, and when file
descriptors are allocated, it is always the lowest unused descriptor that's
used.

 Joost> The result of an 'accept' is a filedescriptor called 'client'.
 Joost> What i then do (after the accept ie), is: I let the program fork.

Seems reasonable.

 Joost> And that's where it gets tricky i suppose...
 Joost> immediately after the fork, the parent closes 'client',
 Joost> and the child closes 'master'.

Yup, that is exactly the right thing to do.

 Joost> The main process returns to it's 'accept' call, while the child
 Joost> process handles the request....

 Joost> Now, if I get a lot of requests (or maybe just when i get a request,
 Joost> at a time where the previous request hadn't finished yet)
 Joost> The 'master' socket suddenly closes.
 Joost> (errno 104 on Linux, strerror: Connection reset by peer)

Ah. Is this error being returned in response to an accept() call?

There is a situation where accept() behaves slightly unpredictably, which
is when a new connection request arrives, but the connection suffers a
reset before the accept() call completes. Some implementations (BSD) just
have the accept() call ignore the attempt and carry on waiting; STREAMS
implementations tend to return EPROTO; apparently the correct error code
should be ECONNABORTED.

Given that Linux's network code is still somewhat immature, this could
either be a simple case of the wrong error code being used for this
situation, or it could be a bug of some sort.

My advice would be to try ignoring the error.

 Joost> So...
 Joost> * Should I let the master process wait for the child to die, before
 Joost>   it can close the 'client' socket ?

Definitely not. The whole point of forking a child is to let the parent
process get back to the accept() call as soon as possible, *without*
having to wait for the child.

 Joost> * Should the child process not interfere (ie not even close) the
 Joost>   'master' socket ?

The child process *should* close the master socket.

--
Andrew.

 
 
 

1. smail failed to reap child process: No child processes

Offen I receive messages with error:

From MAILER-DAEMON Wed Dec 20 17:55:59 1995
To: postmaster
Subject: mail failed, sending to postmaster

|------------------------- Message log follows: -------------------------|

|------------------------- Failed addresses follow: ---------------------|

|------------------------- Message text follows: ------------------------|
Received: by fishwar.koenig.su; Wed, 20 Dec 95 17:55 GMT+0200
[...]

But mail successfully delivered to destination address.

What's wrong?

Alexander Feldman

2. Postgres frontend problem

3. Getting a child and child's child process-id

4. X configuration for AST Bravo LP 4/66d

5. how to kill a child process that runs other children processes

6. SuSE 5.2 Lite

7. Getting a child and child's child process-id

8. Monitoring all active tty terminals

9. handle child process

10. shared memory handles inheritance from Java to child process

11. How to set up signal handling in UNIX to kill a daemon process and children

12. How do i suspend & stop & resume a process inside child()?

13. Catching termination of child process and system() call