All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rémi Denis-Courmont" <rdenis@simphalempin.com>
To: dccp@vger.kernel.org
Subject: Re: [RFC] [DCCP]: Deprecate SOCK_DCCP in favour of SOCK_DGRAM
Date: Tue, 13 May 2008 17:37:38 +0000	[thread overview]
Message-ID: <200805132037.39580.rdenis@simphalempin.com> (raw)
In-Reply-To: <20080513072853.GB4514@gerrit.erg.abdn.ac.uk>

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/

WARNING: multiple messages have this Message-ID (diff)
From: "Rémi Denis-Courmont" <rdenis@simphalempin.com>
To: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	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 20:37:38 +0300	[thread overview]
Message-ID: <200805132037.39580.rdenis@simphalempin.com> (raw)
In-Reply-To: <20080513170325.GB11499@gerrit.erg.abdn.ac.uk>

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/

  parent reply	other threads:[~2008-05-13 17:37 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 [this message]
2008-05-13 17:37   ` Rémi Denis-Courmont
2008-05-13 17:50 ` Arnaldo Carvalho de Melo
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=200805132037.39580.rdenis@simphalempin.com \
    --to=rdenis@simphalempin.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.