[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [dccp] Re: wildcard service code?
Hi Eddie,
See inline ...
Tom P.
> -----Original Message-----
> From: Eddie Kohler [mailto:kohler at CS.UCLA.EDU]
> Sent: Tuesday, November 29, 2005 1:26 AM
> To: Phelan, Tom
> Cc: Yoshifumi Nishida; dccp at ietf.org
> Subject: 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.
I didn't mean SHOULD, just should :-). I agree with your point.
>
> > 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".)
I think this is covered in the spec too. Some of the previous discussion didn't seem
too clear on this point, though.
>
> > 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.
When I first read this comment I thought, "What's the difference?". Then I saw the
point -- one socket with multiple SCs. That seems mostly like an optimization to me.
If an app opens multiple listening sockets with different SCs, you get the same effect.
Definitely worth pointing out, though.
>
> > 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.
I think it is clear in the spec. I just thought it was a ramification missed
in the current discussion.
>
> > 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'.
Maybe we do want to say "equals". Although I'm not sure that if the spec
said that originally we would've avoided the current discussion about
wildcards. At least some of this discussion seems to be because people
either read the spec long ago and forgot details, or didn't read it closely
enough in the first place, and jumped to conclusions ("boy, a wildcard SC would
be neat, I think the spec said something about it ...").
Note that the above isn't meant as a criticism -- I'm certainly in the "read the
spec long ago and forgot details" camp. This discussion is helping me regain
some details :-).
>
> > 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.
> >>
> >>
> >
> >
>
>