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
