Hi, Noel (et al.), Noel Chiappa wrote: > > From: Joe Touch <touch@xxxxxxx> > > > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf