Re: network programming: how does s.accept() work?
- From: Steve Holden <steve@xxxxxxxxxxxxx>
- Date: Tue, 26 Feb 2008 00:08:31 -0500
7stud wrote:
On Feb 25, 10:56 am, Thomas Bellman <bell...@xxxxxxxxxxxxxx> wrote: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.7stud <bbxx789_0...@xxxxxxxxx> wrote:The question I'm really trying to answer is: if a client connects to aThe answer is that the server *doesn't* change its port. As you
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?
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 ( 127.0.0.1, 5052, 127.0.0.1, 50816 ) in your
server, it will be ( 127.0.0.1, 50816, 127.0.0.1, 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: ('0.0.0.0', 5053)
new socket, self: ('127.0.0.1', 5053)
new socket, peer: ('127.0.0.1', 49302)
original socket: ('0.0.0.0', 5053)
new socket, self: ('127.0.0.1', 5053)
new socket, peer: ('127.0.0.1', 49303)
---client1 output-----
('0.0.0.0', 0)
('127.0.0.1', 49302)
---client2 output-----
('0.0.0.0', 0)
('127.0.0.1', 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:
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.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
.
- Follow-Ups:
- Re: network programming: how does s.accept() work?
- From: 7stud
- Re: network programming: how does s.accept() work?
- From: Roy Smith
- Re: network programming: how does s.accept() work?
- References:
- network programming: how does s.accept() work?
- From: 7stud
- Re: network programming: how does s.accept() work?
- From: bockman
- Re: network programming: how does s.accept() work?
- From: 7stud
- Re: network programming: how does s.accept() work?
- From: Thomas Bellman
- Re: network programming: how does s.accept() work?
- From: 7stud
- network programming: how does s.accept() work?
- Prev by Date: freeze.py - resolving dependencies
- Next by Date: Re: network programming: how does s.accept() work?
- Previous by thread: Re: network programming: how does s.accept() work?
- Next by thread: Re: network programming: how does s.accept() work?
- Index(es):
Relevant Pages
|
|