This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: UDP/DTLS sockets communication pattern is broken in Cygwin



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]