From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: dccp@vger.kernel.org
Subject: Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM
Date: Tue, 13 May 2008 17:50:55 +0000 [thread overview]
Message-ID: <20080513175055.GI15306@ghostprotocols.net> (raw)
In-Reply-To: <20080513072853.GB4514@gerrit.erg.abdn.ac.uk>
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
WARNING: multiple messages have this Message-ID (diff)
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: "Rémi Denis-Courmont" <rdenis@simphalempin.com>
Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>,
David Stevens <dlstevens@us.ibm.com>,
David Miller <davem@davemloft.net>,
dccp@vger.kernel.org, netdev@vger.kernel.org,
Ulrich Drepper <drepper@redhat.com>
Subject: Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM
Date: Tue, 13 May 2008 14:50:55 -0300 [thread overview]
Message-ID: <20080513175055.GI15306@ghostprotocols.net> (raw)
In-Reply-To: <200805132037.39580.rdenis@simphalempin.com>
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
next prev parent reply other threads:[~2008-05-13 17:50 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-13 7:28 [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM Gerrit Renker
2008-05-13 7:28 ` Gerrit Renker
2008-05-13 7:39 ` David Miller
2008-05-13 7:39 ` David Miller
2008-05-13 9:37 ` Gerrit Renker
2008-05-13 9:37 ` Gerrit Renker
2008-05-13 13:46 ` Gerrit Renker
2008-05-13 13:46 ` Gerrit Renker
2008-05-13 15:50 ` David Stevens
2008-05-13 15:50 ` David Stevens
2008-05-13 16:23 ` Arnaldo Carvalho de Melo
2008-05-13 16:23 ` Arnaldo Carvalho de Melo
2008-05-13 16:59 ` David Stevens
2008-05-13 16:59 ` David Stevens
2008-05-13 17:03 ` Gerrit Renker
2008-05-13 17:03 ` Gerrit Renker
2008-05-13 17:06 ` Rémi Denis-Courmont
2008-05-13 17:06 ` Rémi Denis-Courmont
2008-05-13 17:33 ` Arnaldo Carvalho de Melo
2008-05-13 17:33 ` Arnaldo Carvalho de Melo
2008-05-13 17:34 ` Arnaldo Carvalho de Melo
2008-05-13 17:34 ` Arnaldo Carvalho de Melo
2008-05-13 17:37 ` Rémi Denis-Courmont
2008-05-13 17:37 ` Rémi Denis-Courmont
2008-05-13 17:50 ` Arnaldo Carvalho de Melo [this message]
2008-05-13 17:50 ` Arnaldo Carvalho de Melo
2008-05-13 17:53 ` Arnaldo Carvalho de Melo
2008-05-13 17:53 ` Arnaldo Carvalho de Melo
2008-05-13 19:14 ` Ulrich Drepper
2008-05-13 19:14 ` Ulrich Drepper
2008-05-13 22:34 ` David Miller
2008-05-13 22:34 ` David Miller
2008-05-14 8:09 ` Gerrit Renker
2008-05-14 8:09 ` Gerrit Renker
2008-05-14 14:06 ` Ulrich Drepper
2008-05-14 14:06 ` Ulrich Drepper
2008-05-14 14:45 ` Gerrit Renker
2008-05-14 14:45 ` Gerrit Renker
2008-05-14 16:06 ` Ulrich Drepper
2008-05-14 16:06 ` Ulrich Drepper
2008-05-14 17:22 ` Gerrit Renker
2008-05-14 17:22 ` Gerrit Renker
2008-05-14 17:39 ` Sridhar Samudrala
2008-05-14 17:39 ` Sridhar Samudrala
2008-05-14 17:43 ` Ulrich Drepper
2008-05-14 17:43 ` Ulrich Drepper
2008-05-14 17:47 ` Rémi Denis-Courmont
2008-05-14 17:47 ` Rémi Denis-Courmont
2008-05-14 17:49 ` Rémi Denis-Courmont
2008-05-14 17:49 ` Rémi Denis-Courmont
2008-05-14 17:57 ` Ulrich Drepper
2008-05-14 17:57 ` Ulrich Drepper
2008-05-14 18:00 ` Gerrit Renker
2008-05-14 18:00 ` Gerrit Renker
2008-05-14 18:06 ` Ulrich Drepper
2008-05-14 18:06 ` Ulrich Drepper
2008-05-14 18:07 ` Ulrich Drepper
2008-05-14 18:07 ` Ulrich Drepper
-- strict thread matches above, loose matches on Subject: below --
2008-05-13 12:53 [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SO Remi Denis-Courmont
2008-05-13 12:53 ` [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM Remi Denis-Courmont
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080513175055.GI15306@ghostprotocols.net \
--to=acme@redhat.com \
--cc=dccp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.