Hi, Its actually quite simple. The is an IPC-Pipe between the parent process and any child. When you call listen() on a socket in the child, rather than binding to the port (which would cause an EADDRINUSE) the child send a message requesting a handle to the parent. The parent checks if it already has a listening socket for the port you want. If yes it will take that handle and send it via the IPC- Pipe to the child. If not then it will listen to the port, remember the Handle and then send it to the child. This way the only process that ever actually listens to a port is the parent and that simply shares its handle with the children.
If you want to look at the code that makes it work you need to look at net.js and child_process.js in Jvaacript as well as the Pipe wrapping stuff in cpp. If the pipe stuff and the ability to pass a handle to a listening socket to listen() were actually documented, and therefore stable, it would actually be easy to write your own clustering solution. Since there are currently a few problems with clustering as is (such as not shutting down correctly), and I really wanted to use it anyhow, I actually wrote my own little API to use. When the clustering stuff actually matures, I intend to simply rewrite it to be a light wrapper around the then stable API. The reason I have not gotten involved with helping on it is simply that I don't have sufficient time and there are already serious efforts by people much more deeply into the subject going on to make the clustering API much better. From what I have seen, it will be absolutely awesome when it's stable. Regards, Phil P.S.: if you need more detailed info, or want a sample of how the magic actually works, just drop me a line. I can send you the stuff I have done or go into a bit more detail if you need it. On Feb 12, 10:36 pm, Mark Volkmann <r.mark.volkm...@gmail.com> wrote: > I'm trying to learn how the cluster module allows multiple TCP-based > servers to share a port. As far as I can tell, this isn't handled in > lib/cluster.js or lib/child_process.js. Perhaps it is handled in > src/node.js and is related to the environment variable access with > process.env.NODE_CHANNEL_FD. Am I on the right track? It's still a mystery > to me what is going on here. > > How are requests distributed among the workers? In my testing it seems that > the worker that handled the previous request will always handle the next > request as long as it finished processing the previous request. > > -- > R. Mark Volkmann > Object Computing, Inc. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
