Mailing List Archive: renegotiating socket connections

I'm writing a server application in python. I understand that most
servers fork off a process for every incoming connection and then
renegotiate on a different port to free up the well-known server port. I
would rather do a multithread model than a forked process model because of
shared memory needs. I've heard that forking the process "automatically"
renegotiates the port somehow, but that doesn't make much sense to me.

More importantly, since I don't want to fork at all, how does one switch
to a different port? Is this a manual process? It seems it would be slow
to have so much round-trip communication before even establishing a
connection, and none of my network manuals say anything more than this
sort of thing "happens." Any tips?

----------------------------------
Nathan Clegg
nathan@islanddata.com

Nathan Clegg writes:
>I'm writing a server application in python. I understand that most
>servers fork off a process for every incoming connection and then
>renegotiate on a different port to free up the well-known server port. I

Where does this bit of incorrect conventional wisdom come from?
netstat on my machine is currently reporting:

amarok.80 amarok.40531 32768 0 32768 0 ESTABLISHED
amarok.80 amarok.40532 32768 0 32768 0 TIME_WAIT
amarok.80 amarok.40534 32768 0 32768 0 ESTABLISHED
amarok.80 amarok.40535 32768 0 32768 0 ESTABLISHED

Several connections to port 80, and everything's fine. Now, you might
have an architecture where a single gatekeeper process hands things
off to another process, and therefore open a new socket to this
second process, but for a simple forking server, I don't see why
this port renegotiation would be required. (Even in this case, you
could use file descriptor passing to avoid the second open, though I
don't know if you can pass file descriptors from Python code easily.)

--
A.M. Kuchling http://starship.python.net/crew/amk/
My nose shall never be touched while heaven give me strength.
-- Sterne, _Tristram Shandy_