barmar@think.com (Barry Margolin) (01/25/91)
In article <1991Jan23.091506.9399@quick.com> srg@quick.com (Spencer Garrett) writes: >In article <1991Jan21.184716.18820@Think.COM>, barmar@think.com (Barry Margolin) writes: >-> Either I misunderstand completely, or the above response is just plain >-> wrong. If a server were to respond with a different port number, how would >-> the client's system tell which server sent the response? The original >-> poster was correct. >My mistake. The behavior I described is a part of the TFTP protocol, >not TCP or even UDP in general. It is cleanly implementable, though. >All you need do is accept any foreign port number (and record the >one you accept) if the socket in question is in SYN_SENT state >and the incoming packet contains a proper SYN. That being the case, >the socket moves into the ESTABLISHED state and all is well. This won't work in general. First of all, the client system might use the same local port for connections to different servers on the remote machine; when there are multiple connections in SYN-SENT with the same local port, the foreign port is used to distinguish them. Also, if a local port is reused for a later connection to a different server on the same host, and a delayed SYN response from the first server were received, it would look like the response to the new SYN. However, I expect that if TCP were allowed to pull the above stunt then we could simply require that the 3-tuple <local-address, local-port, foreign-address> be kept unique for at least 2MSL (many TCP implementations simply step through the local ports for every active open, so this would happen naturally). Something like this could be added to TCP using the option mechanism. The original SYN could include an option indicating willingness to accept an alternate port from the server. The SYN response could include an option specifying the port to be used for further segments. We could call the option "NCP-ICP", since I think this was the Initial Connection Protocol of the original Arpanet Host-to-Host protocol (frequently called "NCP"). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar