Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

(I have a question about the TCP handshake and how port numbers are assigned, if this does not belong here, let me know.)

Hi, I'm studying TCP/IP from the book "Internetworking with TCP/IP" by Douglas Comer. In the TCP chapter it mentions that TCP defines an "endpoint" as a pair (IP address, port number), and a connection is defined by two endpoints.

This has a few implications, such as, a local TCP port could be in several connections at once, as long as there are no two from the same IP and the same remote port. This also means that the amount of established connections is almost limitless (2^16 for every IPv4 address. 2^48 in total).

Now, in class, I was told that when one connects to a listening port, both sides agree on a different port to use, so the communication can happen and the listener socket remains free. This was also my belief before reading the book.

Now I feel like I should obviously trust the book (It's Comer!), but is there any truth to the other explanation?

Thanks

share|improve this question

4 Answers 4

up vote 5 down vote accepted

No, there's no truth to the other statement. What you're probably mistaking this for is active FTP.

http://slacksite.com/other/ftp.html

share|improve this answer
    
Really? I was thinking it sounds more like someone trying to explain ephemeral ports... –  Ryan Ries Nov 11 '12 at 19:59
1  
When my web browser connects to this web site, my computer and the server don't agree to communicate on different ports than the original ports that the connection was established on. My computer connects from one of its ephemeral ports to port 80 on the server and those ports remain in use for the life of that connection. –  joeqwerty Nov 11 '12 at 20:04

First, the basics - a socket is the 4-tuple of (srcip, srcport, dstip, dstport). If any of these values change, it's a different socket. When a given host opens a TCP (or UDP, for that matter) socket its source IP is already known, the source port is selected randomly from the ephemeral range (greater than either 1023 or 1024 - forget which) and the destination IP and port are supplied to the stack by the calling process.

On the server side, a connection is set up and seen coming from the srcip and srcport given and bound to the dstport and dstip. This entry (again - some 4-tuple) is held in the host's connection table which will then allow incoming packets to be associated with the appropriate connection.

TCP handshaking is the process by which the TCP stacks on the respective sides negotiate the parameters for sequence numbers, window sizes and such. By the time this occurs the port numbers have already been determined.

Again - if any of the values in these tuples changes after the initial connection then, by definition, the packets are no longer associated with the original socket.

There are certain circumstances in which other port numbers may be specified by the application in use (i.e. FTP, RPC) but in all cases this calls for the establishment of a separate socket, not the renumbering of an existing one. In the FTP case this would correspond to the initial connection on port 21 (control) from host -> server and then the subsequent connection on port 20 (data) - which, depending on the mode in use, may be set up in either direction. I can't emphasize enough, though, that this constitutes two separate sockets. Referring back to the OSI stack, this would very much be a layer-5 issue.

share|improve this answer

a local TCP port could be in several connections at once

Yes - in order for clients to find a service, then it always run on a specific port at the server - 80 for HTTP, 25 for SMTP, 22 for ssh... A webserver will have lots of clients connected to it's port 80.

Now, in class, I was told that when one connects to a listening port, both sides agree on a different port to use

Either you or your teacher doesn't understand what's happenning. There are some protocols where the client and server will negotiate a different socket - the FTP data connection, some forms of rpc and (IIRC) early versions of Oracle's sql*net worked this way - but it is VERY uncommon.

Your teacher is the one who is being paid to understand the problem and answer your questions - I suggest you go back to him/her.

share|improve this answer

This is definitely off-topic for Server Fault, but you have a horrible misunderstanding that begs correction :-)

First off, you may want to ditch the Comer book they're and pick up a copy of TCP/IP Illustrated (Stevens) - it's largely personal preference, but everyone I know prefers the Stevens book.

Now to the meat of your question:

TCP defines an "endpoint" as a pair (IP address, port number), and a connection is defined by two endpoints.

This is conceptually correct. What actually happens on the protocol layer is a little different, but the concept of a TCP connection is that a client (your web browser, say) opens a local socket (10.0.0.1 port 30000) and connects to a server (10.10.10.10 port 80).
The connection is the channel between these two endpoints.

Now, in class, I was told that when one connects to a listening port, both sides agree on a different port to use, so the communication can happen and the listener socket remains free.

This is semi-correct -- It sounds like what you are trying to describe is a confused version of the behavior of the rendezvous socket listening on the server.
As you surmised, if we just have our communication over the rendezvous socket only one machine could connect to a given listener at a time (which is kinda useless), so what actually happens is when the server accept()s the connection the TCP stack on the server side hands off a new connected socket on which the actual conversation happens.
For all the gory details, see the Stevens book, for a briefer description try this StackOverflow question.


If you would like a little history lesson, this video will probably be interesting to you (the bookmarked time in this link is around where TCP starts getting discussed, but the whole video, or the 3-part series, is something any serious student of Computer Science who is learning about OS design and/or networking should watch).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.