[Mongrel] Shared listening sockets

Wayne E. Seguin wayneeseguin at gmail.com
Tue Oct 23 23:03:03 EDT 2007

On 10/23/07, Robert Mela <rob at robmela.com> wrote:
> Several years back I accidentally discovered that multiple processes can
> listen on the same TCP/IP socket.  The trick of course is that all the
> processes are in the same process group, and the socket is opened by a
> shared parent.   The OS somehow was managing queuing up the various
> calls to accept() on that socket.   Since the watchdog parent / multiple
> child servers is a common, this was a workable solution on the versions
> of Linux we were using.
> IIRC, the OS gracefully queued several processes' calls to accept(),
> requiring no additional synchronization.   But, even if that weren't the
> case, there is still the option of puting an acceptor in a parent and
> dispatching the client socket to available child servers.
> Anyhow --
> The application I wrote has a watchdog process in C that opens up a
> server socket before forking child server processes.  The children get
> passed the descriptor number for that server socket as an argument on
> their command lines.
> All child server processes then enter an accept loop.   They all call
> accept() on that same, shared descriptor .   Each child, btw, opened up
> its own "private" admin socket on a port that was an offset of the main,
> shared service port ( and optionally on a different interface as well ).
> Within a pool then processes are somewhat self-balancing -- a process
> only calls accept() when it's got threads available and ready to handle
> a reqeust.   Clients, or a client load balancer, don't have to keep
> track of traffic or request counts between individual server processes.
> They also don't have to try back-end app servers individually before
> finding a "thread" that's free --  if any process in a pool is
> available, it's already sitting in accept() on that shared socket (
> likely with others queued up behind it in their accept() calls).
> If Mongrel's suitable as an Internet-facing front-end, then there might
> be, for many applications, no need for a load balancing proxy.   Simply
> fire up a pool of mongrels at port 80, and they'll sort it all out among
> themselves.   Even for applications requiring multiple machines a scheme
> like this would simplify load balancer proxy configurations (100
> mongrels in a pool?  No problem -- all one port!)
> I'm sure the folks who wrote Mongrel thought of this and either tried it
> or rejected it beforehand for good reason.   And I had the luxury of
> coding for just one platform.   Perhaps others impose hurdles that make
> this impractical.  But even there, isn't there the Apache model of a
> parent acceptor() passing client sockets to ready children?
> Thoughts?

I believe that the main issue here is on the win32 platform, Luis?

We do have something similar in the works for a future release, however I am
unsure as to how your suggestion ties in at the moment. It appears to be
well worth investigation for what we have planned.

Thank you kindly for this,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071023/3ad50a03/attachment.html 

More information about the Mongrel-users mailing list