X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:content-transfer-encoding
	:in-reply-to; q=dns; s=default; b=KJluJLDwmVW8R3u4LOXhx3+MUEDxgh
	/gVDikh5ilxpBaNKmdjFsvvXRb8LqoDb0FrKZ1wPSr9iLMOSse56/bAxUE9/ad72
	t/2aXjZQ5XSBvOl9xh0eac/duFqFSpyuCojIGZ5qImYg5CGAVm/V2tLnjcRa7SyL
	3ZTGN9jQvfNXo=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:content-transfer-encoding
	:in-reply-to; s=default; bh=hPFyMkKhQoQ11rWs6Cvafj6HNP0=; b=WSDy
	Ker93BmUZuKLLDl3Ht7cuzKYFBJ8ih1ZGgTvBxn5SCwQ6fiBbYcsrvKUAzM+sddl
	WaqKe9aroFzqwBbRNr9Ypkrq1gog6RN6fblbEMwmN3ZHP2iVNOrxKjwO6ck4Yx4v
	ZDusmxYStraDewzSN5nhH9UjoMjQ63liW1Joh8M=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status:	No, score=-1.8 required=5.0 tests=AWL,BAYES_00,TW_DF,TW_DP autolearn=no version=3.3.1
Date:	Fri, 12 Apr 2013 13:43:54 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: UDP/DTLS sockets communication pattern is broken in Cygwin
Message-ID:	<20130412114354.GC11358@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<031222CBCF33214AB2EB4ABA279428A30140C1ACA374 AT SJCPMAILBOX01 DOT citrite DOT net> <20130411212115 DOT GA1376 AT ednor DOT casa DOT cgf DOT cx> <031222CBCF33214AB2EB4ABA279428A30140C1ACA378 AT SJCPMAILBOX01 DOT citrite DOT net>
MIME-Version:	1.0
In-Reply-To:	<031222CBCF33214AB2EB4ABA279428A30140C1ACA378@SJCPMAILBOX01.citrite.net>
User-Agent:	Mutt/1.5.21 (2010-09-15)

Please don't http://cygwin.com/acronyms/#TOFU.

Thank you.

On Apr 11 18:14, Oleg Moskalenko wrote:
> I am sending the test case in the attachment. 
> 
> In the attachment, you will find source code for two programs -
> udpbugserver and udpbugclient. "make" will build them both. They work
> perfectly together in Linux, FreeBSD and Solaris. But they fail in
> Cygwin.

Thanks for the testcase.

Honestly, I have no idea how to fix this issue.  Keep in mind that the
underlying socket functions are still WinSock functions.  The fact that
the wrong socket receives the information is not determined by Cygwin
but by the underlying WinSock behaviour.

Here's an excerpt from MSDN(*):

  "Once the second socket has successfully bound, the behavior for all
   sockets bound to that port is indeterminate. For example, if all of
   the sockets on the same port provide TCP service, any incoming TCP
   connection requests over the port cannot be guaranteed to be handled
   by the correct socket — the behavior is non-deterministic."

(*) http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621%28v=vs.85%29.aspx

I don't see anywhere a description about different, more deterministic
behaviour in case of UDP sockets,  neither connected, nor unconnected.
I see an openssl bug report concerning this behaviour on the openssl
developer's list, though:
http://www.mail-archive.com/openssl-dev AT openssl DOT org/msg29500.html
There's also a matching description in a bug report on the WSK
forum, but unfortunately nobody replied:
http://social.msdn.microsoft.com/Forums/en-US/wsk/thread/caccfb5e-46ed-4d52-8a95-2d5da22dfbb0

However, I think I found a workaround on the application level.
Apparently all packets sent to a specific address are sent to the first
socket which has been bound to the address.  If that socket has been
closed, the next in line gets the packets (unless it has been connected
and the sender is not the connected address).  So what I did was this:

Before starting step 14, I created a third socket, which then replaced
the server socket:

        printf("Step 11 end\n");

        int server_fd_2 = open_socket(); /* SOCKET A */
        addr_bind(server_fd_2, &server_addr);
        close (server_fd);
        server_fd = server_fd_2;

        set_socket_nonblocking(client_fd);
        set_socket_nonblocking(server_fd);

        printf("Step 14 start\n");

It's ugly, but I don't see another potential solution, given how the
underlying WinSock functions work.  I'm also not sure other clients
will still be able to connect to the listening 

Having said that, if anybody knows a way around this which can be
applied on the library level, please keep me informed.  I'd be glad to
change Cygwin to adhere to the expectations on POSIX systems.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -