[RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Gerrit Renker]

There is an API and an address resolution problem involved in specifying a
separate/distinct socket type `SOCK_DCCP'.

The problem is that the default getaddrinfo(3) does not support the `alien'
SOCK_DCCP socket type (it returns `ai_socktype not supported'), thus requiring
various cheats/work-arounds in order to bring up a DCCP socket on a dual-stack
host.

In order to get an address at all,
 * a hint with an ai_socktype=SOCK_DGRAM or SOCK_STREAM needs to be supplied;
 * using ai_socktype=0 causes IPv4 addresses to be returned first, so that a
   server on a dual-stack host needs to be coaxed into v6 mode to accept
   incoming v6 connections.

The suggestion therefore is to not use a separate SOCK_DCCP socket type,
and to put DCCP up under SOCK_DGRAM (being in fact datagram-based), i.e.

	socket(sd, SOCK_DCCP, 0);	

is replaced by	
	
	socket(sd, SOCK_DGRAM, IPPROTO_DCCP);


Having also seen the work-arounds in programs that other people wrote,
I believe that the above change will make it in the long term easier for
people to write DCCP-enabled applications.

It also relieves the libc writers from having to support another socket type.

A quick look at SCTP shows that they also did not introduce new socket types,
relying on the existing SOCK_STREAM/SOCK_SEQPACKET ones.

It might be still early enough to resolve this, before it is widely used
and can then only be supported via work-arounds.

I can't see a disadvantage here and the only work required is to update that
datagram-based not automatically means connection-less.

Is there support for this change or are there reasons to keep SOCK_DCCP?

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[David Miller]

From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Tue, 13 May 2008 08:28:53 +0100

> Is there support for this change or are there reasons to keep SOCK_DCCP?

You'll have to accept it forever since there have been several
kernel releases already with DCCP support added and there are
applications out there.

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Gerrit Renker]

| 
| > Is there support for this change or are there reasons to keep SOCK_DCCP?
| 
| You'll have to accept it forever since there have been several
| kernel releases already with DCCP support added and there are
| applications out there.
| 
And maybe it is not necessary or worth to change it. 

But there is a problem, the cause is not necessarily the above:

 * using an ai_socktype=0 used to work for DCCP; on dual-stack hosts,
   IPv6 addresses were returned first, so that both IPv6 and IPv4
   clients (v6-mapped-v4) could connect to the server,

 * within the last three months there was a change in the lookup
   behaviour so that now IPv4 addresses are returned first on dual
   stack hosts when AF_UNSPEC is specified with ai_socktype=0,

 * changing preference values in /etc/gai.conf did not help,

 * the only fix was the following (pretend to be UDP):

	if (inSettings->mProtocol == IPPROTO_DCCP)
		hints.ai_socktype = SOCK_DGRAM;

Maybe there is a better fix for this.

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[David Stevens]

Are they mutually exclusive?

Why not add SOCK_DGRAM/IPPROTO_DCCP support while leaving
the existing stuff alone, and then requiring programs that want to use
getaddrinfo to use it that way?

                                                +-DLS

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Arnaldo Carvalho de Melo]

Em Tue, May 13, 2008 at 08:50:59AM -0700, David Stevens escreveu:
> Are they mutually exclusive?
> 
> Why not add SOCK_DGRAM/IPPROTO_DCCP support while leaving

Because DCCP is not SOCK_DGRAM at all? :)

> the existing stuff alone, and then requiring programs that want to use
> getaddrinfo to use it that way?

I wonder what is the problem with doing what I did when adding support
for DCCP in ttcp, or for AF_LLC in ssh, ncftp, vsftpd, etc, i.e.
getaddrinfo/getnameinfo wrappers that look if SOCK_DCCP or AF_LLC are
being asked for and doing the right thing.

IIRC at the time I asked Ulrich Drepper about adding support for PF_LLC
sockets in glibc and he said that it would be OK as long as it didn't
included PF_LLC sockets in the default search, doing it only when PF_LLC
was explicitely passed. I just never got around to actually cook up the
patches and send it to Uli.

What would be the problem of SOCK_DCCP being handled in glibc in such a
fashion?

- Arnaldo

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[David Stevens]

Arnaldo Carvalho de Melo <acme@redhat.com> wrote on 05/13/2008 09:23:25 
AM:

> Em Tue, May 13, 2008 at 08:50:59AM -0700, David Stevens escreveu:
> > Are they mutually exclusive?
> > 
> > Why not add SOCK_DGRAM/IPPROTO_DCCP support while leaving
> 
> Because DCCP is not SOCK_DGRAM at all? :)

        Well, SOCK_STREAM/IPPROTO_DCCP then. :-) But it isn't really that
either, as Remi said.
        If you do a connect() on a UDP socket, it doesn't cease to
be a SOCK_DGRAM socket, so I don't really care about that distinction,
but if others do, that's ok with me. There are ACKs here, too, so maybe.
        My point was really that, though not as pretty, the world won't
end if there are two ways to get to the same kind of socket, and
especially if adding a new one makes getaddrinfo() easier to deal with.
If the best way isn't the existing way, we could add it, and keep the
old way for backward compatibility only.
        A "0" protocol had better continue to be TCP and UDP, and
specifying IPPROTO_DCCP makes it clear what the user wants, regardless
of the type. So "just working" (even with any of SOCK_DGRAM, SOCK_STREAM,
and SOCK_DCCP) seems perfectly reasonable to me. My $.02.
        A wrapper sound ok to me too.

                                                                +-DLS

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Rémi Denis-Courmont]

Le Tuesday 13 May 2008 19:59:35 David Stevens, vous avez écrit :
>         Well, SOCK_STREAM/IPPROTO_DCCP then. :-) But it isn't really that
> either, as Remi said.
>         If you do a connect() on a UDP socket, it doesn't cease to
> be a SOCK_DGRAM socket, so I don't really care about that distinction,
> but if others do, that's ok with me. There are ACKs here, too, so maybe.

But connect() is a _non-blocking_ operation which merely sets the _default_ 
destination (you can still sendto() someone else).

Using socket types blindly may also break applications using 
getsockopt(SO_TYPE), if they exists (I think I wrote one once...) to 
determine how to use a socket.

SOCK_DCCP was perhaps a bad idea, but SOCK_DGRAM seems worse. In the end, it's 
more a matter of patching libc getaddrinfo than changing the kernel API 
anyway. Did AIX not have a similar socket type as DCCP under a more generic 
name by the way?

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Arnaldo Carvalho de Melo]

Em Tue, May 13, 2008 at 08:06:34PM +0300, Rémi Denis-Courmont escreveu:
> Le Tuesday 13 May 2008 19:59:35 David Stevens, vous avez écrit :
> >         Well, SOCK_STREAM/IPPROTO_DCCP then. :-) But it isn't really that
> > either, as Remi said.
> >         If you do a connect() on a UDP socket, it doesn't cease to
> > be a SOCK_DGRAM socket, so I don't really care about that distinction,
> > but if others do, that's ok with me. There are ACKs here, too, so maybe.
> 
> But connect() is a _non-blocking_ operation which merely sets the _default_ 
> destination (you can still sendto() someone else).
> 
> Using socket types blindly may also break applications using 
> getsockopt(SO_TYPE), if they exists (I think I wrote one once...) to 
> determine how to use a socket.
> 
> SOCK_DCCP was perhaps a bad idea, but SOCK_DGRAM seems worse. In the end, it's 
> more a matter of patching libc getaddrinfo than changing the kernel API 
> anyway. Did AIX not have a similar socket type as DCCP under a more generic 
> name by the way?

/me feels Deja Vu :-)

Lemme dig the URL for the discussion where SOCK_DCCP was discussed and
AIX was summoned, etc :-)

- Arnaldo

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Arnaldo Carvalho de Melo]

Em Tue, May 13, 2008 at 02:34:54PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, May 13, 2008 at 08:06:34PM +0300, Rémi Denis-Courmont escreveu:
> > Le Tuesday 13 May 2008 19:59:35 David Stevens, vous avez écrit :
> > >         Well, SOCK_STREAM/IPPROTO_DCCP then. :-) But it isn't really that
> > > either, as Remi said.
> > >         If you do a connect() on a UDP socket, it doesn't cease to
> > > be a SOCK_DGRAM socket, so I don't really care about that distinction,
> > > but if others do, that's ok with me. There are ACKs here, too, so maybe.
> > 
> > But connect() is a _non-blocking_ operation which merely sets the _default_ 
> > destination (you can still sendto() someone else).
> > 
> > Using socket types blindly may also break applications using 
> > getsockopt(SO_TYPE), if they exists (I think I wrote one once...) to 
> > determine how to use a socket.
> > 
> > SOCK_DCCP was perhaps a bad idea, but SOCK_DGRAM seems worse. In the end, it's 
> > more a matter of patching libc getaddrinfo than changing the kernel API 
> > anyway. Did AIX not have a similar socket type as DCCP under a more generic 
> > name by the way?
> 
> /me feels Deja Vu :-)
> 
> Lemme dig the URL for the discussion where SOCK_DCCP was discussed and
> AIX was summoned, etc :-)

http://www.ietf.org/mail-archive/web/dccp/current/msg01540.html

While discussing with Nishida-san, the NetBSD DCCP guy.

- Arnaldo

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Arnaldo Carvalho de Melo]

Em Tue, May 13, 2008 at 09:59:35AM -0700, David Stevens escreveu:
> Arnaldo Carvalho de Melo <acme@redhat.com> wrote on 05/13/2008 09:23:25 
> AM:
> 
> > Em Tue, May 13, 2008 at 08:50:59AM -0700, David Stevens escreveu:
> > > Are they mutually exclusive?
> > > 
> > > Why not add SOCK_DGRAM/IPPROTO_DCCP support while leaving
> > 
> > Because DCCP is not SOCK_DGRAM at all? :)
> 
>         Well, SOCK_STREAM/IPPROTO_DCCP then. :-) But it isn't really that
> either, as Remi said.
>         If you do a connect() on a UDP socket, it doesn't cease to
> be a SOCK_DGRAM socket, so I don't really care about that distinction,
> but if others do, that's ok with me. There are ACKs here, too, so maybe.

A "connection" on a UDP socket is not performed as a reliable handshake,
its just simple "hey kernel, everytime I do a write please send to this
default destination, would you do it for me?", whereas a connection on a
DCCP socket is much like the same as a TCP connection. In Linux they
share most of the connection establishment, minisocks, timewait sockets
infrastructure even.

So for connection purposes, DCCP is SOCK_STREAM, but when data is to be
transmitted it really is a SOCK_DGRAM, i.e. it is neither :)

>         My point was really that, though not as pretty, the world won't
> end if there are two ways to get to the same kind of socket, and
> especially if adding a new one makes getaddrinfo() easier to deal with.
> If the best way isn't the existing way, we could add it, and keep the
> old way for backward compatibility only.
>         A "0" protocol had better continue to be TCP and UDP, and
> specifying IPPROTO_DCCP makes it clear what the user wants, regardless

As it makes specifying a SOCK_DCCP on a patched glibc :) If someone
comes with a better name than SOCK_DCCP and keep the value already
allocated, the better, SOCK_DCCP looks too much specific to one
protocol, but it is just that there is only one specification for a
reliable connection + unreliable data transfer protocol (that I know
of).

> of the type. So "just working" (even with any of SOCK_DGRAM, SOCK_STREAM,
> and SOCK_DCCP) seems perfectly reasonable to me. My $.02.
>         A wrapper sound ok to me too.

I think that the wrapper for older libcs + patching libc to know about
this new kind of socket is the way to go.

- Arnaldo

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Gerrit Renker]

| > the existing stuff alone, and then requiring programs that want to use
| > getaddrinfo to use it that way?
| 
| I wonder what is the problem with doing what I did when adding support
| for DCCP in ttcp, or for AF_LLC in ssh, ncftp, vsftpd, etc, i.e.
| getaddrinfo/getnameinfo wrappers that look if SOCK_DCCP or AF_LLC are
| being asked for and doing the right thing.
| 
Using work-arounds is brittle and frustrating when the API behaviour
suddenly changes. My experience of using such a wrapper was:

 * it passed UDP(-Lite), TCP through without changing the socket type;
 * when passed DCCP, it set the socket type to 0, to avoid `ai_socktype
   not supported' getaddrinfo error;
 * this used to work fine until about January, when something in the
   lookup machinery for dual-stack hosts changed:
   - before, AF_UNSPEC + ai_socktype=0 put IPv6 first into the result list,
   - now the the result order is reversed (IPv4 sockets are returned first)
 * so maybe "pretending to be UDP" (ai_socktype=SOCK_DGRAM) is a better
   workaround (at least it worked until this afternoon :)


| What would be the problem of SOCK_DCCP being handled in glibc in such a
| fashion?
That is probably the best and most robust solution one can think of.

Even the suggestion of changing to SOCK_DGRAM+IPPROTO_DCCP is just another
work-around and, as David and Remi confirmed, a bad one at that.

Gerrit

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Rémi Denis-Courmont]

Le Tuesday 13 May 2008 20:03:25 Gerrit Renker, vous avez écrit :
> Using work-arounds is brittle and frustrating when the API behaviour
> suddenly changes. My experience of using such a wrapper was:
>
>  * it passed UDP(-Lite), TCP through without changing the socket type;
>  * when passed DCCP, it set the socket type to 0, to avoid `ai_socktype
>    not supported' getaddrinfo error;

>  * this used to work fine until about January, when something in the
>    lookup machinery for dual-stack hosts changed:
>    - before, AF_UNSPEC + ai_socktype=0 put IPv6 first into the result list,
>    - now the the result order is reversed (IPv4 sockets are returned first)

You're probably using a recent libc that applies RFC3484 _properly_. If you 
still want IPv6 first, no matter what addresses the host has, I think the 
AI_PASSIVE flag should do the trick. Then again, working around RFC3484 
policy is _not_ a good idea.

As far as I am concerned, for DCCP, I (meaning VLC) currently use SOCK_STREAM, 
and overrides the socktype and protocol fields in the socket() call 
manually - so I don't get a TCP socjet.

In any case, getaddrinfo() should be patched to
1/ accept ai_socktype == SOCK_DCCP and ai_protocol == IPPROTO_DCCP,
2/ accept ai_socktype == SOCK_DCCP and ai_protocol == 0,
   and set ai_protocol to IPPROTO_DCCP in the results,
3/ (perhaps?) accept ai_protocol == IPPROTO_DCCP and ai_socktype == 0,
   and set ai_socktype to SOCK_DCCP in the results.

Similarly:
1/ accept ai_socktype == SOCK_DGRAM and ai_protocol == IPPROTO_UDPLITE,
2/ (intentionally omitted - keep normal UDP non-Lite behavior)
3/ (perhaps?) accept ai_protocol == IPPROTO_UDPLITE and ai_socktype == 0,
   and set ai_socktype to SOCK_DGRAM in the results.

Voilà. Best to check this with Ulrich Drepper, no?

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Arnaldo Carvalho de Melo]

Em Tue, May 13, 2008 at 08:37:38PM +0300, Rémi Denis-Courmont escreveu:
> Le Tuesday 13 May 2008 20:03:25 Gerrit Renker, vous avez écrit :
> > Using work-arounds is brittle and frustrating when the API behaviour
> > suddenly changes. My experience of using such a wrapper was:
> >
> >  * it passed UDP(-Lite), TCP through without changing the socket type;
> >  * when passed DCCP, it set the socket type to 0, to avoid `ai_socktype
> >    not supported' getaddrinfo error;
> 
> >  * this used to work fine until about January, when something in the
> >    lookup machinery for dual-stack hosts changed:
> >    - before, AF_UNSPEC + ai_socktype=0 put IPv6 first into the result list,
> >    - now the the result order is reversed (IPv4 sockets are returned first)
> 
> You're probably using a recent libc that applies RFC3484 _properly_. If you 
> still want IPv6 first, no matter what addresses the host has, I think the 
> AI_PASSIVE flag should do the trick. Then again, working around RFC3484 
> policy is _not_ a good idea.
> 
> As far as I am concerned, for DCCP, I (meaning VLC) currently use SOCK_STREAM, 
> and overrides the socktype and protocol fields in the socket() call 
> manually - so I don't get a TCP socjet.
> 
> In any case, getaddrinfo() should be patched to
> 1/ accept ai_socktype == SOCK_DCCP and ai_protocol == IPPROTO_DCCP,
> 2/ accept ai_socktype == SOCK_DCCP and ai_protocol == 0,
>    and set ai_protocol to IPPROTO_DCCP in the results,
> 3/ (perhaps?) accept ai_protocol == IPPROTO_DCCP and ai_socktype == 0,
>    and set ai_socktype to SOCK_DCCP in the results.
> 
> Similarly:
> 1/ accept ai_socktype == SOCK_DGRAM and ai_protocol == IPPROTO_UDPLITE,
> 2/ (intentionally omitted - keep normal UDP non-Lite behavior)
> 3/ (perhaps?) accept ai_protocol == IPPROTO_UDPLITE and ai_socktype == 0,
>    and set ai_socktype to SOCK_DGRAM in the results.
> 
> Voilà. Best to check this with Ulrich Drepper, no?

Cest bon! Agreed. Ulrich?

- Arnaldo

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rémi Denis-Courmont wrote:
> In any case, getaddrinfo() should be patched to
> [...]

What should be the behavior is socktype and protocol are zero?  Should
these two types be returned by default?  What others?  So far we return
TCP, UDP, and raw socket information.  I'd rather keep the list short
but since we already have raw sockets in there (because they are in
POSIX) I won't reject anything that's more useful than raw sockets.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIKeh/2ijCOnn/RHQRAhTeAJ9jrv+RS6rkrGJvan9ADq4S86d2XQCggST4
/MYPzB+2s2/m1VYsmUPAeLg=
=FSYf
-----END PGP SIGNATURE-----

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Gerrit Renker]

| 
| Rémi Denis-Courmont wrote:
| > In any case, getaddrinfo() should be patched to
| > [...]
| 
| What should be the behavior is socktype and protocol are zero?  Should
| these two types be returned by default?  What others?  So far we return
| TCP, UDP, and raw socket information.  I'd rather keep the list short
| but since we already have raw sockets in there (because they are in
| POSIX) I won't reject anything that's more useful than raw sockets.
| 
| - --
RFC 3493 says that 0 for socktype/protocol means that caller will accept
any socket type / protocol, so presumably this does include DCCP and UDP-Lite.

It would be just _great_ if getaddrinfo() could support Remi's cases for DCCP
(RFC 4340) and UDP-Lite (RFC 3828). So far it is only possible to get an
address by "cheating", i.e. pretending to getaddrinfo to be TCP or UDP. This
does not really work well and still causes lots of problems/broken applications.

Gerrit

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerrit Renker wrote:
> RFC 3493 says that 0 for socktype/protocol means that caller will accept
> any socket type / protocol, so presumably this does include DCCP and UDP-Lite.

I know what the RFC says.  But there are a gazillion of protocols out
there and I won't create a record for all of them in case socktype and
protocol are zero.  That's just overkill in 99.9% of all cases.

I assumption is that UDPlite is just too specialized to be useful to a
wide array of people.  Yes, it case be supported if explicitly requested
but should be returned if 0/0 is passed in.

What I'm asking is whether this is a fair assumption and what the story
of DCCP is.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIKvHb2ijCOnn/RHQRAlz5AKCvOSOm7PR7ljfyZ9krq0TtzZUTbgCdFLLj
F1fvWvR+VvXUSE5x+VtgsqQ=
=3Lft
-----END PGP SIGNATURE-----

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Gerrit Renker]

Quoting Ulrich Drepper:
| -----BEGIN PGP SIGNED MESSAGE-----
| Hash: SHA1
| 
| Gerrit Renker wrote:
| > RFC 3493 says that 0 for socktype/protocol means that caller will accept
| > any socket type / protocol, so presumably this does include DCCP and UDP-Lite.
| 
| I know what the RFC says.  But there are a gazillion of protocols out
| there and I won't create a record for all of them in case socktype and
| protocol are zero.  That's just overkill in 99.9% of all cases.
| 
| I assumption is that UDPlite is just too specialized to be useful to a
| wide array of people.  Yes, it case be supported if explicitly requested
| but should be returned if 0/0 is passed in.
| 
Sorry I misunderstood your email. Yes the above case is clear: if
someone supplies 0/0, s/he will probably not want any specialised
protocols in the return list.

This didn't appear in Remi's list. I have completed the list and put the
cases in the table below; `defaults' is interpreted in the way above.

 +--------------+---------------+---------------+---------------+
 | ai_socktype	| ai_protocol	| Return type	| Return Proto  |
 +--------------+---------------+---------------+---------------+
 | SOCK_DCCP	| IPPROTO_DCCP	| SOCK_DCCP	| IPPROTO_DCCP 	|
 | SOCK_DCCP	| 0		| SOCK_DCCP	| IPPROTO_DCCP 	|
 | 0		| IPPROTO_DCCP	| SOCK_DCCP	| IPPROTO_DCCP	|
 | 0		| 0		| (defaults)	| (defaults)	|
 +--------------+---------------+---------------+---------------+


If at all possible, for UDP-Lite it is similar. Since UDP-Lite is
actually just a form of UDP, this seems much less urgent than DCCP -
one might argue that UDP-Lite falls under SOCK_DGRAM/UDP.

 +-------------+-----------------+-------------+-----------------+
 | ai_socktype | ai_protocol	 | Return type |  Return Proto   |
 +-------------+-----------------+-------------+-----------------+
 | SOCK_DGRAM  | IPPROTO_UDPLITE | SOCK_DGRAM  | IPPROTO_UDPLITE |
 | SOCK_DGRAM  | 0		 | SOCK_DGRAM  | IPPROTO_UDP	 |
 | 0	       | IPPROTO_UDPLITE | SOCK_DGRAM  | IPPROTO_UDPLITE |   
 | 0	       | 0		 | (defaults)  | (defaults)      |
 +-------------+-----------------+-------------+-----------------+

... but it would still be good to have. 

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerrit Renker wrote:
> ... but it would still be good to have. 
> [...]

Thanks, but I think I got this already from previous mails.

The question is: is either DCCP or UDPlite important enough to be
returned in the default list when socktype and protocol are zero?

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIKw342ijCOnn/RHQRAmnrAKCO0sevJbyZXNoFG12jSg1NjPC+5wCfUlyH
cLqvVRQ1gmTkkwl5JnqA9go=
=QRU/
-----END PGP SIGNATURE-----

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Gerrit Renker]

| The question is: is either DCCP or UDPlite important enough to be
| returned in the default list when socktype and protocol are zero?
They are probably both not important enough to be returned in the
default list.

But either is important be considered when a user unambiguously specifies
ai_socktype and/or ai_protocol; to avoid bad/brittle workarounds.

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerrit Renker wrote:
> But either is important be considered when a user unambiguously specifies
> ai_socktype and/or ai_protocol; to avoid bad/brittle workarounds.

OK, I added the support.  Will be in glibc 2.9.

But what about $subject?  What is the story with SOCK_DCCP?  I added it
now but if it's going away I'd rather remove it.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIKyTN2ijCOnn/RHQRAhyWAJoDEgLDYcL/VUQyz5ykje2r4FWVFwCbBdvq
U1W/yHRv5cAuuWr4927IGUw=
=rjjM
-----END PGP SIGNATURE-----

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Gerrit Renker]

| > But either is important be considered when a user unambiguously specifies
| > ai_socktype and/or ai_protocol; to avoid bad/brittle workarounds.
| 
| OK, I added the support.  Will be in glibc 2.9.
| 
This is really good news :)

| But what about $subject?  What is the story with SOCK_DCCP?  I added it
| now but if it's going away I'd rather remove it.
| 
No, I don't think it will be deprecated, it has been part of several kernel
releases in this form already and there was no support in the thread for
changing SOCK_DCCP.

AS I am guilty of $subject, the story is that the initial suggestion to
avoid the trouble with getaddrinfo() by changing the socket type to
SOCK_DGRAM, since then presumably an address would be returned. 

This proved an even poorer workaround than any of the existing ones, in
particular since it collides with the (Posix) definition of SOCK_DGRAM,
and has been part of kernel releases.

Eventually Arnaldo made the most sensible suggestion of why not solving
the trouble at the root and update glibc, which is how a message with
this subject reached your inbox. This had wider support and I can't
think of a better way to solve the problem. 

Hence many thanks indeed, as the absence of proper DCCP/UDP-Lite support
in getaddrinfo() has so far caused quite some grief/frustration.

Gerrit

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Sridhar Samudrala]

On Wed, 2008-05-14 at 09:06 -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Gerrit Renker wrote:
> > ... but it would still be good to have. 
> > [...]
> 
> Thanks, but I think I got this already from previous mails.

SCTP is another protocol that needs to be supported in getaddrinfo().
The minimum support that is good to have is to handle the following
values of ai_socktype and ai_protocol.
  SOCK_STREAM, IPPROTO_SCTP
  SOCK_SEQPACKET, IPPROTO_SCTP

Thanks
Sridhar
> 
> The question is: is either DCCP or UDPlite important enough to be
> returned in the default list when socktype and protocol are zero?
> 
> - --
> ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> 
> iD8DBQFIKw342ijCOnn/RHQRAmnrAKCO0sevJbyZXNoFG12jSg1NjPC+5wCfUlyH
> cLqvVRQ1gmTkkwl5JnqA9go=
> =QRU/
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Rémi Denis-Courmont]

Le Wednesday 14 May 2008 20:39:40 Sridhar Samudrala, vous avez écrit :
> On Wed, 2008-05-14 at 09:06 -0700, Ulrich Drepper wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Gerrit Renker wrote:
> > > ... but it would still be good to have.
> > > [...]
> >
> > Thanks, but I think I got this already from previous mails.
>
> SCTP is another protocol that needs to be supported in getaddrinfo().
> The minimum support that is good to have is to handle the following
> values of ai_socktype and ai_protocol.
>   SOCK_STREAM, IPPROTO_SCTP
>   SOCK_SEQPACKET, IPPROTO_SCTP

Yeah but I don't think ai_socktype == SOCK_STREAM and ai_protocol == 0 should 
return IPPROTO_SCTP. Me fears this will break to many TCP applications in the 
field.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rémi Denis-Courmont wrote:
> Yeah but I don't think ai_socktype == SOCK_STREAM and ai_protocol == 0 should 
> return IPPROTO_SCTP. Me fears this will break to many TCP applications in the 
> field.

That's not happening.  For SOCK_STREAM TCP is returned.

On the other hand, in the moment, for SOCK_SEQPACKET I return SCTP.  If
this is not the preferred solution let me know now.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIKypP2ijCOnn/RHQRAvxYAJ9EqfwRsQq+SuRmkbtdmVs8aDiyGACeMoqx
KqOzlMnpDpzMz+ccEB6oxBA=
=DHB9
-----END PGP SIGNATURE-----

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sridhar Samudrala wrote:
>>   SOCK_STREAM, IPPROTO_SCTP
>>   SOCK_SEQPACKET, IPPROTO_SCTP

This is also in.  Give it a try once the first glibc for F10 rawhide is
built.  Should happen before Monday next week.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIKygE2ijCOnn/RHQRAmm8AKCroe3jOmDpovf7M7oUhfInIZv6FQCgvuLB
M3XI59EFGTdYxCwNGvDRTSA=
=x83D
-----END PGP SIGNATURE-----

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Rémi Denis-Courmont]

Le Tuesday 13 May 2008 22:14:07 Ulrich Drepper, vous avez écrit :
> Rémi Denis-Courmont wrote:
> > In any case, getaddrinfo() should be patched to
> > [...]
>
> What should be the behavior is socktype and protocol are zero?  Should
> these two types be returned by default?  What others?  So far we return
> TCP, UDP, and raw socket information.  I'd rather keep the list short
> but since we already have raw sockets in there (because they are in
> POSIX) I won't reject anything that's more useful than raw sockets.

Well... I've always wondered what the use of both zeroes was supposed to be.

In AI_PASSIVE mode, it makes no sense, since there is no way you can handle 
passive SOCK_STREAM sockets (bind+listen+accept) and "passive" SOCK_DGRAM 
sockets in any common way (bind+recvfrom+sendto).

Even in active mode (connect+send), I cannot figure out how to share 
SOCK_STREAM code with SOCK_DGRAM code, given the incompatible end-of-file and 
datagram boundaries semantics (or lack thereof).

Hence, it seems that both zeroes is only of use to enumerate the supported 
protocol (yeah right...). If that's so adding DCCP and even UDP-Lite would be 
OK, even though they are corner-case protocols. Do you intend to 
implement "dccp" when parsing /etc/services, though?

Frankly, I have no definite answer, and I'm not any kind of standard body to 
make one in the first place :P

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rémi Denis-Courmont wrote:
> Do you intend to 
> implement "dccp" when parsing /etc/services, though?

No special support is needed.  This is just a string.  Add */dccp
entries and see it just work.


Just to conclude this: I will add none of DCCP, UDPlite, SCTP to the
default list.  For now.  Maybe SCTP take off at some point and is worth
it.  But not now.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIKyoY2ijCOnn/RHQRAsVmAKCPtd+MIVisShBE6exgIh6AJoGWmQCgkaHt
WYuOfl63Q0oS1TdWYmhP95A=
=2/DS
-----END PGP SIGNATURE-----

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[David Miller]

From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Tue, 13 May 2008 13:23:25 -0300

> What would be the problem of SOCK_DCCP being handled in glibc in such a
> fashion?

I don't understand why this isn't exactly what is being done.

We have to update glibc to handle SOCK_DCCP correctly, just
get over it :-)

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Remi Denis-Courmont]

On Tue, 13 May 2008 08:28:53 +0100, Gerrit Renker <gerrit@erg.abdn.ac.uk>
wrote:
> There is an API and an address resolution problem involved in specifying
a
> separate/distinct socket type `SOCK_DCCP'.
(...)
> Having also seen the work-arounds in programs that other people wrote,
> I believe that the above change will make it in the long term easier for
> people to write DCCP-enabled applications.

DCCP clearly fails the POSIX definition of SOCK_DGRAM in different ways.

I think this is not a good idea.

> It also relieves the libc writers from having to support another socket
> type.

As long as SOCK_DCCP-or-whatever is not automatically selected when
ai_socktype is nul, this should be both easy to implement in libc *and*
backward compatible (applications will not try to use DCCP implicitly).

> A quick look at SCTP shows that they also did not introduce new socket
> types, relying on the existing SOCK_STREAM/SOCK_SEQPACKET ones.

But they follow the semantics for them.

> It might be still early enough to resolve this, before it is widely used
> and can then only be supported via work-arounds.
> 
> I can't see a disadvantage here and the only work required is to update
> that
> datagram-based not automatically means connection-less.
> 
> Is there support for this change or are there reasons to keep SOCK_DCCP?

Maybe the name SOCK_DCCP sucks, but I think DCCP needs a "new" socket type
anyway.

-- 
Rémi Denis-Courmont
http://www.remlab.net

Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM

[Gerrit Renker]

| 
| DCCP clearly fails the POSIX definition of SOCK_DGRAM in different ways.
| 
| I think this is not a good idea.
| 
Thanks for the clarification. Even in Posix, datagram = connection-less.
Plus the issues with older kernel releases. Question resolved, no SOCK_DGRAM.


| > It also relieves the libc writers from having to support another socket
| > type.
| 
| As long as SOCK_DCCP-or-whatever is not automatically selected when
| ai_socktype is nul, this should be both easy to implement in libc *and*
| backward compatible (applications will not try to use DCCP implicitly).
| 
There are two possibilities:
 * as additional supported protocol (there are many new transport
   protocols, perhaps there is some kind of modular support),
 * if DCCP service codes are part of the lookup, then getting library
   support can take longer (algorithm changes).

Both may take a while until available. In the meantime it would be good
to find some smart workaround for getaddrinfo, as changes in the internals
so far required to fix applications several times.