Hi, Noel (et al.),
Noel Chiappa wrote:
> From: Joe Touch <touch(_at_)ISI(_dot_)EDU>
> TCPMUX doesn't 'handoff'. It expects that .. the service desired is
> served off of its port once opened after the initial exchange
> (in-band).
> .. The downside is that it then forces a two-step demultiplexing of
> incoming packets; there may be utility in a variant that allows the
> dest port to be unbound and later filled-in, or changed during the
> connection, so that services can be more efficiently demultiplexed.
I'm missing something here. A TCP connection is identified by the (srcaddr,
sport, dstaddr, dport) tuple. TCB's are looked up by this tuple. Connections
to TCPMUX will all have the same dstaddr/dport, but will presumably have
different srcaddr's, and (presumably) random sport's, and can be
distinguished that way.
Why can't the TCPMUX listener just bind the correct application to the TCB
(after figuring out what the appropriate application is), and then forget
about the connection, leaving it entirely to the application to deal with?
There are three ways to proceed:
1) set the port number after the handshake (as I described)
i.e., dynamic port negotiation
2) continue to use the initial port number for packet demuxing
i.e., portname demuxing
3) let the port number be fixed, but use the string for the
service binding
#3 solves the problem of service binding without involving the DNS,
allowing endpoints to determine the meaning of a port (which is where
that meaning is defined anyway)
That's fine, and as others have noted, simpler to implement. The option
would be used only in the SYN, and after that it would be unnecessary
(and ignored if used).
#2 is more complicated, and increases the port space. That's probably
unnecessary at this time.
#1 is more complicated; it's useful where a number of hosts emulate a
single host (e.g., behind a NAT) since it can avoid collisions in
selecting the otherwise arbitrary destination port, but again it's
unnecessary at this time.
So far it looks like only #3 (service binding) will be covered unless
there's a real need for either dynamic port negotiation or portname
demuxing.
Joe
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf