Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!sun-barr!newstop!grapevine!koreth@panarthea.ebay.sun.com
From: koreth@panarthea.ebay.sun.com (Steven Grimm)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Building a reliable datagram protocol on top of UDP
Message-ID: <34979@grapevine.uucp>
Date: 21 Dec 89 06:13:11 GMT
References: <1486@wacsvax.OZ>
Sender: news@grapevine.uucp
Reply-To: koreth@panarthea.ebay.sun.com (Steven Grimm)
Organization: Sun Microsystems Federal, Milpitas, CA
Lines: 29

In article <1486@wacsvax.OZ> jamesp@wacsvax.uwa.oz.OZ (James Pinakis) writes:
>Would I be better off sticking with tcp-ip and
>accepting a limit to the number of client processes?

Here's a little trick you can use to increase that limit to a fairly
outrageous value.  This does increase your server's complexity,
possibly by a great deal depending on exactly what you're doing.  (This
is BSD UNIX-oriented.)

Figure out how many open file descriptors your process can have.  The
getdtablesize() call should do it.  Serve as usual until you hit the
limit.  Then fork.  If you like, make a pipe or socket connection
between the parent and child process (this may be necessary for your
application.) Then close the listen()ing file descriptor in the parent
process; in the child, close all the connected descriptors.  The child
will now accept new connections.

If everyone disconnects from a parent process, it should die as it's no
longer needed.  If everyone disconnects from a process in the middle of
a chain, that process needs to stick around as UNIX provides no way to
stick two pipes/sockets together.

Hope that helps.  It may be more trouble than it's worth for your
application, but it's a worthwhile method for some things.

---
"                                                  !" - Marcel Marceau
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
koreth@ebay.sun.com	...!sun!ebay!koreth