Re: [dccp] Re: wildcard service code?

[Arnaldo Carvalho de Melo <acme at ghostprotocols.net>]

On 11/28/05, Phelan, Tom <tphelan at sonusnet.com> wrote:
> Hi All,
>
> I'm not too sure that we've converged here, so at the risk of creating another divergence, here are some rules for services codes as I understand them:
>
> 1) API's where the service code (SC) isn't set as an integral part of the connection creation (as would be likely with a sockets extension), should default the service code to 0.  The spec doesn't say this explicitly, but this seems to me to be the reasonable policy.  Apps should explicitly set the SC before a call to listen or connect.  If they don't, they use SC 0.

> 2) SC 0 is not a wildcard.  Sockets listening with SC 0 should only accept connections with SC 0.

These two are easy to implement right now

> 3) Implementations should allow multiple listeners on the same port, as long as the SC is different for each listener.

Will require a bit more work in Linux, but should be just an extension
to inet_lookup_listener, in fact I'll have to stop using it and write a
dccp_lookup_listener that uses __inet_lookup_listener to get the first
server that listens on the port and then continue till matching the
one where, ouch, have to think about this one some more...

> 4) Implementations should refuse a new connection, and not allow an outgoing DCCP-Request, if the source address, source port, destination address, and destination port quad-tuple is the same as an existing connection (even though the SC is different).  The SC isn't carried in DCCP-Data and other packets and it wouldn't be possible to disambiguate the two connections.  For the receiving side, this would appear to be a DCCP-Request in the wrong state, so it's probably covered, as long as quad-tuple lookup precedes packet-type-specific operations.  It's a little more complicated for the transmitting side.

This is how we do it right now.

> 5) There are problems with listening on a "wildcard" SC, if it's allowed.  When an app is listening on the wildcard, no other app can listen on the same port, which could introduce interoperability/integration problems ("port stealing").

We don't support listening on wildcards, so no problem.

> 6) To obtain a registered default port for your application, you MUST register an SC.

Seems fine.

- Arnaldo