This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: UDP/DTLS sockets communication pattern is broken in Cygwin
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 12 Apr 2013 13:43:54 +0200
- Subject: Re: UDP/DTLS sockets communication pattern is broken in Cygwin
- 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>
- Reply-to: cygwin at cygwin dot com
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@openssl.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