Re: Port Multiplexing Details


J. Spencer Love (JSLove@MIT-MULTICS.ARPA)
Mon, 19 May 86 16:24 EDT


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.



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:07 GMT