Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!decwrl!ucbvax!MIT-MULTICS.ARPA!JSLove From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Multiplexing Details Message-ID: <860519202446.210131@MIT-MULTICS.ARPA> Date: Mon, 19-May-86 16:24:00 EDT Article-I.D.: MIT-MULT.860519202446.210131 Posted: Mon May 19 16:24:00 1986 Date-Received: Tue, 20-May-86 20:17:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 81 Approved: tcp-ip@sri-nic.arpa Concerning Benson Margulies' comments on NAMED-TCP-SERVICE: You can't just close the connection if the service is not implemented, because the TCP close is a half-channel close. I really think you must abort the connection, sending an RST packet, to indicate totally unambiguously that the service is unavailable. Consider the timing windows if you use a closing strategy: the user side sends the protocol name to NAMED-TCP-SERVICE, and then passes the connection to the protocol user program. Perhaps it waits for the server's TCP to acknowledge the name bytes. The server receives the name, and the service is unavailable. It closes the connection. The user side gets the close but is already in the protocol user code. This could be surprising; it might even have some other interpretation if the service multiplexor is used for some existing service. When an abort is used instead, this more closely resembles the response of a system which doesn't implement the service. If you try to contact a TCP which has nothing listening on a port, the connection is effectively aborted. Granted, it was never established, but a RST packet is a RST packet. A cleaner alternative is to have some positive acknowledgement. For example, the server could send OK, DOWN, or UNKNOWN back, followed by a CRLF. The disadvantage of this is the extra overhead of the reply. If you are lucky, the reply data gets piggybacked on the name acknowledgement, and the reply acknowledgement gets piggybacked on the first packet of the user program. Long live UDP-2. My proposal for this used a null-terminated string on the theory that it constitutes encouragement to use the UDP-2 protocol only for one shot single-query single-response datagram exchanges. This was probably not clever of me. By having a single length byte, you can hash very nicely on length and first character. I don't believe that more than one length byte is needed, but perhaps one or two high bits could be swiped as flags if 127 or 63 is acceptable as the maximum length of a protocol name. I still think that the name field should be an even number of bytes long because a number of machines like their 16 bit fields aligned. The spec should thus include a pad byte for odd length names. There is still the problem of designating the other end of the transaction. When you send a query the service name is equivalent to the foreign port; when sending a reply, the service name is the local port. Either both ports must be named, or there will have to be some other way of distinguishing queries from replies. I really don't like using two names, but perhaps that is best. I would prefer service name, transaction ID, and a query/reply flag. The transaction ID would be assigned by the querying host, and for many protocols ignored by the server except to send it back in the reply. Uniqueness might be required in some cases, but is only needed for a given host pair and service name, just as the port number would be. The extra space taken by the name combined with the packet size limits restricts the amount of data in the datagram. For UDP, I have heard suggested maximum packet sizes of 512 bytes, although you can send real jumbograms between some implementations using fragmentation. By requiring that transaction IDs be unique over host pairs (during some TTL (time to live)), the service name could be omitted from reply packets. If this seems ugly, how about a flag in the request packet indicating whether it is permissible to omit the service name from the reply. If the flag is still set in the reply, there is no service name. If the UDP port lookup service is written, a TTL field could be included in the reply. Some user sides might ignore the TTL and look up every time they had a transaction. For simple exchanges this doubles the overhead. Hosts with a permanent database could return very long times to live; and long TTLs would be the rule when servers permitted looking up permanently assigned values like TELNET => 23. When the port numbers are assigned on a per-bootload basis, or even more often, TTL values like one minute could be used to allow for system crashes or service restarts. The UDP service might be useful for protocols other than TCP. A request packet could include the protocol ID and the name of the service. The reply could begin with the request and add the port number and TTL. Perhaps the port number could be at the end so that protocols could have port numbers more than 16 bits long. I think it is reasonable to refine all three proposals. I fear that there will be few takers for UDP-2.