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

Hrvoje Niksic wrote:
7stud <bbxx789_05ss@xxxxxxxxx> writes:

When you surf the Web, say to http://www.google.com, your Web browser
is a client. The program you contact at Google is a server. When a
server is run, it sets up business at a certain port, say 80 in the
Web case. It then waits for clients to contact it. When a client does
so, the server will usually assign a new port, say 56399, specifically
for communication with that client, and then resume watching port 80
for new requests.

Actually the client is the one that allocates a new port. All
connections to a server remain on the same port, the one it listens
on:

(Hey, I know you! ;) )

Right.

7stud, what you seem to be missing, and what I'm not sure if anyone has
clarified for you (I have only skimmed the thread), is that in TCP,
connections are uniquely identified by a /pair/ of sockets (where
"socket" here means an address/port tuple, not a file descriptor). It is
fine for many, many connections, using the same local port and IP
address, so long as the other end has either a different IP address _or_
a different port. There is no issue with lots of processes sharing the
same socket for various separate connections, because the /pair/ of
sockets is what identifies them. See the "Multiplexing" portion of
section 1.5 of the TCP spec (http://www.ietf.org/rfc/rfc0793.txt).

Reading some of what you've written elsewhere on this thread, you seem
to be confusing this address/port stuff with what accept() returns. This
is hardly surprising, as unfortunately, both things are called
"sockets": the former is called a socket in the various RFCs, the latter
is called a socket in documentation for the Berkeley sockets and similar
APIs. What accept() returns is a new file descriptor, but the local
address-and-port associated with this new thing is still the very same
ones that were used for listen(). All the incoming packets are still
directed at port 80 (say) of the local server by the remote client.

It's probably worth mentioning at this point, that while what I said
about many different processes all using the same local address/port
combination is true, in implementations of the standard Berkeley sockets
API the only way you'd _arrive_ at that situation is that all of those
different connections that have the same local address/port combination
is that they all came from the same listen() call (ignoring mild
exceptions that involve one server finishing up connections while
another accepts new ones). Because while one process has a socket
descriptor bound to a particular address/port, no other process is
allowed to bind to that combination. However, for listening sockets,
that one process is allowed to accept many connections on the same
address/port. It can handle all those connections itself, or it can fork
new processes, or it can pass these connected sockets down to
already-forked processes. But all of them continue to be bound to the
same local address-and-port.

Note that, if the server's port were to change arbitrarily for every
successful call to accept(), it would make it much more difficult to
filter and/or analyze TCP traffic. If you're running, say, tcpdump, the
knowledge that all the packets on a connection that was originally
directed at port 80 of google.com, will continue to go to port 80 at
google.com (even though there are many, many, many other connections out
there on the web from other machines that are all also directed at port
80 of google.com), is crucial to knowing which packets to watch for
while you're looking at the traffic.

--
HTH,
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
.

Relevant Pages

  • sockets, closing and TIME_WAIT
    ... During heavy load the server can't follow anymore because the sockets ... my server should be able to handle 10 clients connecting ... This gets a free position in the array of connections, ...
    (comp.unix.programmer)
  • Nimda.E/unknown memory resident, internet-aware processes
    ... a client's NT 4.0 server was infected with what appeared to be ... network traffic and saw several suspect connections. ... one other connection to port 2787. ... along with about 500 other compromised systems on just that one IRC server. ...
    (Incidents)
  • Re: blocking sockets?
    ... The server handles requests and spawns a child process for every connection. ... If a client sends the text "foo" to the server, the server itself should try to make a connection with another service on port 4321. ... The parent process should still be listening on port 1234 if you have actually spawned a child process to read and write data from the remote client,. ... Non-blocking sockets. ...
    (perl.beginners)
  • Re: iptables newbie question
    ... so it's not a dedicated server. ... > merely want to limit connections on that port ONLY to the e-mail server ... do you want to be able to establish connections out to ... The same sort of thing happens for any request you make - dns, ntp, web, ...
    (comp.os.linux.security)
  • Re: Sun Volume Manager or Solaris Disk Suite
    ... keyboard or mouse connections. ... I have to buy a RJ45 cable that will connect to a DB9 adapter on one ... port). ... How would putty know that I am trying to connect to a server via a com ...
    (comp.sys.sun.admin)