Re: [dccp] Re: dccp_service in sockaddr_dccp{}

[Arnaldo Carvalho de Melo <acme at conectiva.com.br>]

Em Tue, Sep 13, 2005 at 02:47:01AM +0900, Yoshifumi Nishida escreveu:
> 
> From: Arnaldo Carvalho de Melo <acme at conectiva.com.br>
> Subject: Re: [dccp] Re: dccp_service in sockaddr_dccp{}
> Date: Fri, 9 Sep 2005 14:31:33 -0300
> Message-ID: <20050909173132.GV19109 at mandriva.com>
> 
>  > Em Fri, Sep 09, 2005 at 08:34:17AM -0700, Eddie Kohler escreveu:
>  > > Hi,
>  >  
>  > > Although we can't be sure yet, we do imagine that almost every DCCP
>  > > connection will specify a service code.  If the server specifies a
>  > > service code, and the client does not, then the client's connection
>  > > attempt will be rejected.
>  > 
>  > This is as well my understanding of the draft authors intention (pun) for
>  > the service code in the REQUEST packet, hence the field in sockaddr_dccp,
>  > think of it as something like scope_id (RFC 2553) in sockaddr_in6 if you
>  > will, different reasons, but one could use the same arguments of those
>  > against having service in sockaddr_{in_}_dccp to say that scope_id should
>  > really have been implemented as a setsockopt and not be present in
>  > sockaddr_in6 :-)
>  
> Hmm, A good point. :-)  But, I still prefer using a setsockopt..

Damn, lemme try something else 8)
 
> I think that I understand the draft authors's intention that service code
> can be used as an extention to port number. 

OK

> My little concern (which may not be correct) is that one of the key deployment 
> issues of DCCP is smooth transition from UDP. If we can modify UDP applications 
> (especially client side) with minimum costs (ex: just replace SOCK_DGRAM 
> to SOCK_DCCP or SOCK_CONN_DGRAM), the benefit might be not small. 
> Besides that, we don't have to increase the number of sockaddr struct as 
> some folks pointed out, so the implementation would be simpler. 

Well, I've been thinking about this and perhaps the best option is to
support both, i.e. if an application passes just a sockaddr_in struct the
kernel DCCP stack understands it as "hey, lets use service 0, the app
doesn't cares, probably its a straight conversion from some legacy app", to
pass the service one would pass sockaddr_in_dccp with the service it
desires (connect) or accepts (bind), with the setsockopt being as well
accepted as a way to specify the services for both connect and bind.

Argh, Eddie, I guess perhaps we should specify this behaviour in some
draft, as an implementation issue/suggestion/whatever.

Ah, and straight conversion from UDP? I toyed with the idea of doing the
connect on the first packet being sent so that UDP apps could be converted
doing what you described above, but being a connection oriented protocol
the straight conversion is s/SOCK_STREAM/SOCK_DCCP/g, no?

- Arnaldo