Re: [BEHAVE] (no subject)

Simon Perreault <simon.perreault@viagenie.ca> Thu, 27 June 2013 13:45 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE6321F9DEB for <behave@ietfa.amsl.com>; Thu, 27 Jun 2013 06:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.835
X-Spam-Level:
X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR+icmlwy4G8 for <behave@ietfa.amsl.com>; Thu, 27 Jun 2013 06:45:41 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E14AB21F9DE8 for <behave@ietf.org>; Thu, 27 Jun 2013 06:45:40 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 318B94150E; Thu, 27 Jun 2013 09:45:40 -0400 (EDT)
Message-ID: <51CC4204.1040109@viagenie.ca>
Date: Thu, 27 Jun 2013 15:45:40 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: ivan@cacaoweb.org
References: <CB1B483277FEC94E9B58357040EE5D02325A6E93@xmb-rcd-x15.cisco.com> <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <f8741fad1af1cee094de9c59408b7425@cacaoweb.org> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <fc3c7389e9fc7afc9201f0516de436a7@cacaoweb.org> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org>
In-Reply-To: <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: behave@ietf.org
Subject: Re: [BEHAVE] (no subject)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 13:45:41 -0000

Le 2013-06-27 15:27, ivan c a écrit :
>>> Your pseudo-code will never bind the sockets on the same local
> endpoint.
>>> It is forbidden POSIX behavior.
>>
>> I'm ready to accept that, with a proper citation.
>
> Without the option SO_REUSEADDR, this is forbidden POSIX behavior

Please provide a citation.

>>> The option SO_REUSEADDR won't help either, this option is used to bind
>>> over an *already closed* socket in TIME_WAIT state, that's all.
>>
>> I humbly believe that you are mistaken. It works, try it.
>
> It surely *works* on platforms that support this use of SO_REUSEADDR, we
> discussed it numerous times already, including on the phone.

So what is the problem exactly?

My point is that UDP and TCP are not different from the point of view of 
the NAT w.r.t. port preservation, since applications routinely call 
connect() on UDP sockets and it is entirely possible that two UDP 
sockets share the same local endpoint. POSIX standards have nothing to 
do with it. The functionality is available on many (all?) platforms, and 
applications use it.

> I also made the point in numerous posts already that SO_REUSEADDR is used
> to bypass the TIME_WAIT state on closed sockets, and even this is not
> specified by POSIX. See
> http://www.ietf.org/mail-archive/web/behave/current/msg10876.html
> In another post, I explained that if you use SO_REUSEADDR on all your TCP
> sockets you expose them to the old duplicate problem, and the worst is that
> this crosses applications boundaries. See
> http://www.ietf.org/mail-archive/web/behave/current/msg10906.html

We're talking about UDP here. There is no TIME_WAIT.

Simon