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

[Steve Holden]

7stud wrote:
> On Feb 25, 10:00 pm, Roy Smith <r... at panix.com> wrote:
>> In article
>> <e4138617-bb4b-4f59-ab78-a49104854... at 60g2000hsy.googlegroups.com>,
>>
>>  7stud <bbxx789_0... at yahoo.com> wrote:
>>> 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.
>> You're confusing "port" and "socket".
>>
>> A port is an external thing.  It exists in the minds and hearts of packets
>> on the network, and in the RFCs which define the TCP protocol (UDP too, but
>> let's keep this simple).
>>
>> A socket is an internal thing.  It is a programming abstraction.  Sockets
>> can exist that aren't bound to ports, and several different sockets can be
>> bound to the same port.  Just like there can be multiple file descriptors
>> which are connected to a given file on disk.
>>
>> The TCP protocol defines a state machine which determines what packets
>> should be sent in response when certain kinds of packets get received.  The
>> protocol doesn't say how this state machine should be implemented (or even
>> demands that it be implemented at all).  It only requires that a TCP host
>> behave in a way which the state machine defines.
>>
>> In reality, whatever operating system you're running on almost certainly
>> implements in the kernel a state machine as described by TCP.  That state
>> machine has two sides.  On the outside is the network interface, which
>> receives and transmits packets.  On the inside is the socket interface to
>> user-mode applications.  The socket is just the API by which a user program
>> interacts with the kernel to get it to do the desired things on the network
>> interface(s).
>>
>> Now, what the articles and books say is that there is a listening SOCKET.  
>> And when you accept a connection on that socket (i.e. a TCP three-way
>> handshake is consummated on the network), the way the socket API deals with
>> that is to generate a NEW socket (via the accept system call).  There
>> really isn't any physical object that either socket represents.  They're
>> both just programming abstractions.
>>
>> Does that help?
> 
> If two sockets are bound to the same host and port on the server, how
> does data sent by the client get routed?  Can both sockets recv() the
> data?
> 
"Routing" traditionally means passing hop-by-hop from one IP address to 
another, but I'll assume that you are actually concerned about delivery 
of packets from two separate clients - lets call them (addr1, p1) and 
(addrs, p2) - to two server processes both using the same endpoint 
address which we will call (addrS, pS). In all cases the first memebr of 
the tuple is an IP address and the second is a port number.

Note that the condition I mentioned earlier (with the caveat added by 
Roy) ensures that while addr1 and addr2 might be the same, or p1 and p2 
might be the same, they can *never* be the same together: if the TCP 
layer at addr1 allocates port p1 to one client process, when another 
client process asks for an ephemeral port TCP guarantees that it wonn't 
be given p1, because that is already logged as in use by another process.

So, in Python terms that represents a guarantee that

     (addr1, p1) != (addr2, p2)

and consequently (addr1, p1, addrS, pS) != (addr2, p2, addrS, pS)

Now, when a packet arrives at the server system addressed to the server 
endpoint, the TCP layer (whcih maintains a record of *both* endpoints 
for each connection) simply looks at the incoming address and port 
number to determine which process, of the potentially many using (addrS, 
pS), it needs to be delivered to.

If this isn't enough then you should really take this problem to a 
TCP/IP group. It's pretty basic, and until you understand it you will 
never make sense of TCP/IP client/server communications.

   http://holdenweb.com/linuxworld/NetProg.pdf

might help, but I don't guarantee it.

regards
  Steve

-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/