Google and Python

[Nick Craig-Wood]

Hendrik van Rooyen <mail at microcorp.co.za> wrote:
>  "Paul Rubin" <http://lid> wrote:
> 
> > "Hendrik van Rooyen" <m..orp.co.za> writes:
> > > What is the advantage of passing the open file rather than just the
> > > fully qualified file name and having the other process open the
> > > file itself?
> >
> > The idea is that the application is a web server.  The socket listener
> > accepts connections and hands them off to other processes.  That is,
> > the file descriptors are handles on network connections that were
> > opened by the remote client, not disk files that can be opened
> > locally.
> 
>  Ok got it - so instead of starting a thread, as is current practice, you fork
>  a process (possibly on another machine) and "hand over" the client.

It is trivial to pass a socket to a new thread or a forked child - you
don't need this mechanism for that.  It doesn't work on different
machines though - it has to be on the same machine.

It is for passing a socket to an already running process.  For example
you could implement fast cgi like this.

Fast cgi is a process which runs continuously which avoids startup
times and can track more state more easily.

Instead of the client talking to the web server and the web server
taking to the fast cgi process which is what normally happens, the web
server could first writes some headers on the socket then pass the
socket on to the fast cgi process directly, cutting out a whole lot of
copying of the data.

>  Can't you do this by passing the client's IP addy and the negotiated socket
>  on the clients machine?

No, because the state of the open TCP connection is kept in the kernel
not in the user process.

>  Or is this where the heavy lifting comes in? - "spoofing" the original local IP
>  addy on the new server? - seems you would have to route to a local machine
>  based not on IP addy only, but on (IP,socket) tuples.  - This might work if
>  you have only one entry point to the local LAN, but would be harder to do
>  if there are two points of entry, and packets could hit from
>  outside on either..

It is all done in the kernel.  The kernel has the state of the TCP
connection - it is just accessed from a different process.

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick