network programming: how does s.accept() work?

Steve Holden steve at
Tue Feb 26 06:08:31 CET 2008

7stud wrote:
> On Feb 25, 10:56 am, Thomas Bellman <bell... at> wrote:
>> 7stud <bbxx789_0... at> wrote:
>>> The question I'm really trying to answer is: if a client connects to a
>>> host at a specific port, but the server changes the port when it
>>> creates a new socket with accept(), how does data sent by the client
>>> arrive at the correct port?  Won't the client be sending data to the
>>> original port e.g. port 5052 in the client code above?
>> The answer is that the server *doesn't* change its port.  As you
>> could see in the output of your server, the socket that accept()
>> returned also had local port 5052.  Each *client* will however
>> get a unique local port at *its* end.
>> A TCP connection is identified by a four-tuple:
>>     ( localaddr, localport, remoteaddr, remoteport )
>> Note that what is local and what is remote is relative to which
>> process you are looking from.  If the four-tuple for a specific
>> TCP connection is (, 5052,, 50816 ) in your
>> server, it will be (, 50816,, 5052 ) in the
>> client for the very same TCP connection.
>> Since your client hasn't bound its socket to a specific port, the
>> kernel will chose a local port for you when you do a connect().
>> The chosen port will be more or less random, but it will make
>> sure that the four-tuple identifying the TCP connection will be
>> unique.
> You seem to be describing what I see:
> ----server output-----
> original socket: ('', 5053)
> new socket, self: ('', 5053)
> new socket, peer: ('', 49302)
> original socket: ('', 5053)
> new socket, self: ('', 5053)
> new socket, peer: ('', 49303)
> ---client1 output-----
> ('', 0)
> ('', 49302)
> ---client2 output-----
> ('', 0)
> ('', 49303)
> But your claim that the server doesn't change its port flies in the
> face of every description I've read about TCP connections and
> accept().  The articles and books I've read all claim that the server
> port 5053 is a 'listening' port only.  Thereafter, when a client sends
> a request for a connection to the listening port, the accept() call on
> the server creates a new socket for communication between the client
> and server, and then the server goes back to listening on the original
> socket.  Here are two sources for that claim:
There can be many TCP connections to a server all using the same 
endpoint. Take a look at the traffic coming out of any busy web server: 
everything that comes out of the same server comes from port 80. That 
doesn't stop it listening for more connections on port 80.

The server disambiguates the packets when it demultiplexes the 
connection packet streams by using the remote endpoint to differentiate 
between packets that are part of different connections. TCP guarantees 
that no two ephemeral port connections from the same client will use the 
same port.

Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC    

More information about the Python-list mailing list