[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dccp] Re: wildcard service code?

Hi Tom,

On Nov 28, 2005, at 11:52 AM, Phelan, Tom 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.

I disagree with the SHOULD. The previous Linux policy, which prevented connection attempts until a Service Code was set, was fine, and in some ways quite preferable. If there is going to be a default 0 is the best default.

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

Yes, this should be implied by the spec. (You meant "Sockets listening with ONLY SC 0".)

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

Yes, but this is an advanced feature. More important is the ability for a single listener to specify multiple Service Codes for a listening socket.

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.

I hope that this point is implied by the existing specification! If it is not clear, then I could clarify it.

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").

The spec is meant to forbid wildcard Service Codes. "If the DCCP- Request's Service Code doesn't match any of the server's Service Codes for the given port, the server MUST reject the request by sending a DCCP-Reset packet with Reset Code 8, "Bad Service Code"." (Section 8.1.2) I suppose one could weasel and say that "match" is not defined. We meant equality; and I suppose we could say 'equals'.

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

Yes, that is the intent, although the spec says SHOULD. More on SHOULD vs. MUST in another mail.

Eddie



Tom P.

-----Original Message-----
From: dccp-bounces at ietf.org [mailto:dccp-bounces at ietf.org]On Behalf Of
Yoshifumi Nishida
Sent: Sunday, November 27, 2005 11:15 PM
To: kohler at CS.UCLA.EDU
Cc: dccp at ietf.org
Subject: Re: [dccp] Re: wildcard service code?



Hi,

From: Eddie Kohler <kohler at CS.UCLA.EDU>
Subject: [dccp] Re: wildcard service code?
Date: Tue, 22 Nov 2005 12:03:47 -0800
Message-ID: <A3E9B00C-18D8-4295-B1CF-13997781E39F at CS.UCLA.EDU>

As we discussed previously, my preferred implementation
would have
been to stick the Service Code in the sockaddr. Then
there wouldn't
be an extra step to frustrate users. You vetoed that, I
forget why, 
but I wasn't convinced by your arguments.

The lack of a Service Code wildcard is intentional. As we
discussed,
we will not add a wildcard service code, since this would
open a huge 
hole in the service code mechanism.  It would be better to remove
Service Codes entirely, which we will not do.

We would prefer that every application writer apply for,
and use, an
application-specific Service Code as soon as possible; so
the current
default, which encourages that behavior, is fine.
Although I would 
discourage this, the document does not prevent the Linux
implementation from starting up with Service Code 0; we say that
Service Code 0 MUST NOT be *allocated*, not that it must

not be used.

OK, Thanks for clarifying this. I prefer that the spec does not define
default value of Service Code and leave it for
implementations. So your
statement is enough for me.
As for wildecard, I think we can implement similar functions
when we really
need it since the spec allows passive sockets to be
associated with multiple
service codes.

Thanks,
--
Yoshifumi Nishida
nishida at csl.sony.co.jp
Sony Computer Science Laboratories, Inc.