Hi Eddie, So I've gone back and reread what the spec says on service codes, and you're correct that what I suggested is in conflict. I didn't mean to be in conflict; I'm only trying for clarity. I'll try again and please comment. I see two possible scenarios that result from what the spec says, depending on what the implementer decides to do about "Passive sockets MAY, at the implementation's discretion, be associated with more than one Service Code; this might let multiple applications, or multiple versions of the same application, listen on the same port, differentiated by Service Code". If the implementer decides to not do this (only one service code per port): o Each actively listening destination port is associated with one and only one service code. o The same service code can be associated with multiple ports. o Applications that want to support multiple versions of their protocol on one port must not use different service codes for those versions (the HTTP/1.0--HTTP/1.1 example below). They must differentiate the versions at the application level. o At the listening system, the service code functions as an "are you sure?" mechanism. You've connected to a port, now prove you really know what you're doing by giving me a second indication that this is what you intend. If the implementer decides to support this (multiple service codes associated with a port): o Each actively listening destination port is associated with one or more service codes. o The service code sets associated with different ports can overlap in any manner. o The service code functions as an additional demux mechanism -- OK, you've connected to a port that supports multiple services, which one do you want? It's like the tcpmux service on port 1 for tcp. o The spec then gives the implementer two more choices to make -- whether a single application is allowed to use multiple service codes, and whether multiple applications are allowed to share the port using different service codes. o If the implementer supports multiple service codes per application, then version differentiation through service codes is possible. o If the implementer supports multiple applications sharing the same port, then I'm not sure what destination port means anymore -- one port could support all of the services the system wants to offer (or not depending on the next item). o Implementers will need to apply some limit to the number of service codes that can share a port -- the spec is silent on what this should be. Some implementers will choose a large number, others a small one. Is this correct? Tom P. > -----Original Message----- > From: Eddie Kohler [mailto:kohler@xxxxxxxxxxx] > Sent: Wednesday, June 06, 2007 3:11 PM > To: Phelan, Tom > Cc: gorry@xxxxxxxxxxxxxx; DCCP mailing list > Subject: Re: Comments on draft-fairhurst-dccp-serv-codes-03.txt > > Tom, > > > The addition of service codes by DCCP allows us to break this > > demultiplexing/identifying duality. We can now say that the *exclusive* > > use of port numbers is for demultiplexing, and the *exclusive* use of > > service codes is for identifying applications. This implies a few > > rules: > > We COULD say this, but why would we? It also goes against the language > in the DCCP RFC, which explicitly allows a listening socket to be > associated with multiple Service Codes. (Think HTTP/1.0 and HTTP/1.1.) > > Similarly, the DCCP stack MUST understand Service Codes, as it is > required to send an error if service codes don't match. > > Gorry's draft should not be redefining the RFC in my opinion. On the > other hand I still don't quite understand the goal of Gorry's draft. > > Eddie > > > > > o Demultiplexing is based on the source and destination IP address and > > source and destination port numbers only, just as it is for the other > > connection-oriented transports. Only one application/socket can > > "listen" on a port number for incoming connection requests. > > > > o It is not necessary for the DCCP stack to know the service code > > associated with an application that is listening on a port number, since > > the DCCP stack is really only concerned with demultiplexing, not > > application identity. A DCCP stack SHOULD (MUST?) allow an application > > to check the service code in an incoming DCCP-Request and decide whether > > or not to proceed with the connection. A DCCP stack MUST NOT require an > > application to perform this check. A DCCP stack MAY (SHOULD?) allow an > > application to pre-specify the service code[s] that it will accept and > > process incoming DCCP-Requests based on that information. > > > > o A DCCP stack MUST allow an application to specify the service code to > > be used in DCCP_Request packets. > > > > o Applications MAY use well-known port numbers to facilitate > > client/server rendezvous. > > > > o Applications SHOULD register and use a service code specific to the > > application. > > > > o Devices, for example, firewalls, wishing to identify an application > > associated with a connection MUST use only the service code. Devices > > MUST NOT use port numbers to identify the type of application using a > > connection. > > > > Comments appreciated :-). > > > > Tom P. > >
