* Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results
@ 2012-07-31 16:44 Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2012-08-01 9:05 ` Corinna Vinschen
0 siblings, 1 reply; 4+ messages in thread
From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2012-07-31 16:44 UTC (permalink / raw)
To: cygwin
Hi,
Observed is an inconsistent result when recvmsg() is used on a
UDP socket with or without ancillary control message parameters.
Here's is an example:
static char buf[1 << 16];
struct sockaddr_in sin;
struct msghdr msg;
struct iovec iov;
#ifndef CYGWIN_BUG
char cmsgbuf[32];
#endif /*CYGWIN_BUG*/
int n;
iov.iov_base = buf;
iov.iov_len = sizeof(buf);
memset(&sin, 0, sizeof(sin));
memset(&msg, 0, sizeof(msg));
msg.msg_name = (caddr_t) &sin;
msg.msg_namelen = sizeof(sin);
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
#ifndef CYGWIN_BUG
memset(cmsgbuf, 0, sizeof(cmsgbuf));
msg.msg_control = cmsgbuf;
msg.msg_controllen = sizeof(cmsgbuf);
#endif /*CYGWIN_BUG*/
if ((n = recvmsg(sock, &msg, 0/*no special flags*/)) <= 0) {
/* Handle error */
return;
}
/* HERE: msg.msg_flags is inconsistent here for non-unicast UDP sockets */
For a non-unicast socket "sock", the returned msg.msg_flags will have proper WSA
bits (MSG_BCAST or MSG_MCAST) set if CYGWIN_BUG is not defined (i.e. the recvmag()
call is passed non-zero msg.msg_controllen). Otherwise, msg.msg_flags will always
get returned 0.
The relevant code from CYGWIN source suggests that the native WSA flags should
have got preserved (fhandler_socket.cc, fhandler_socket::recvmsg):
msg->msg_flags = wsamsg.dwFlags;
yet apparently this had slipped away in fhandler_socket::recv_internal, which
branches on the presence of msg_controllen (and opts out for use other WSA API
call if that is not set, even for non-stream sockets):
if (wsamsg->Control.len > 0)
{
...
use_recvmsg = true;
}
Can this please be rectified?
Thanks,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results
2012-07-31 16:44 Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results Lavrentiev, Anton (NIH/NLM/NCBI) [C]
@ 2012-08-01 9:05 ` Corinna Vinschen
2012-08-01 18:45 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C]
0 siblings, 1 reply; 4+ messages in thread
From: Corinna Vinschen @ 2012-08-01 9:05 UTC (permalink / raw)
To: cygwin
On Jul 31 12:43, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Hi,
>
> Observed is an inconsistent result when recvmsg() is used on a
> UDP socket with or without ancillary control message parameters.
>
> Here's is an example:
>
> static char buf[1 << 16];
> struct sockaddr_in sin;
> struct msghdr msg;
> struct iovec iov;
> #ifndef CYGWIN_BUG
> char cmsgbuf[32];
> #endif /*CYGWIN_BUG*/
> int n;
>
> iov.iov_base = buf;
> iov.iov_len = sizeof(buf);
> memset(&sin, 0, sizeof(sin));
> memset(&msg, 0, sizeof(msg));
> msg.msg_name = (caddr_t) &sin;
> msg.msg_namelen = sizeof(sin);
> msg.msg_iov = &iov;
> msg.msg_iovlen = 1;
> #ifndef CYGWIN_BUG
> memset(cmsgbuf, 0, sizeof(cmsgbuf));
> msg.msg_control = cmsgbuf;
> msg.msg_controllen = sizeof(cmsgbuf);
> #endif /*CYGWIN_BUG*/
>
> if ((n = recvmsg(sock, &msg, 0/*no special flags*/)) <= 0) {
> /* Handle error */
> return;
> }
>
> /* HERE: msg.msg_flags is inconsistent here for non-unicast UDP sockets */
>
> For a non-unicast socket "sock", the returned msg.msg_flags will have proper WSA
> bits (MSG_BCAST or MSG_MCAST) set if CYGWIN_BUG is not defined (i.e. the recvmag()
> call is passed non-zero msg.msg_controllen). Otherwise, msg.msg_flags will always
> get returned 0.
>
> The relevant code from CYGWIN source suggests that the native WSA flags should
> have got preserved (fhandler_socket.cc, fhandler_socket::recvmsg):
>
> msg->msg_flags = wsamsg.dwFlags;
>
> yet apparently this had slipped away in fhandler_socket::recv_internal, which
> branches on the presence of msg_controllen (and opts out for use other WSA API
> call if that is not set, even for non-stream sockets):
>
> if (wsamsg->Control.len > 0)
> {
> ...
> use_recvmsg = true;
> }
>
> Can this please be rectified?
I applied a patch which should fix this problem. It always uses
WSARecvMsg now, if called from recvmsg, still provided it is possible,
of course (No SOCK_STREAM, no AF_LOCAL).
I'm just generating a new developer snapshot. Please give the today's
snapshot from http://cygwin.com/snapshots/ a try. Should be up in about
half an hour.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results
2012-08-01 9:05 ` Corinna Vinschen
@ 2012-08-01 18:45 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2012-08-01 19:25 ` Corinna Vinschen
0 siblings, 1 reply; 4+ messages in thread
From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2012-08-01 18:45 UTC (permalink / raw)
To: cygwin
> I applied a patch which should fix this problem. It always uses
> WSARecvMsg now, if called from recvmsg, still provided it is possible,
> of course (No SOCK_STREAM, no AF_LOCAL).
>
> I'm just generating a new developer snapshot. Please give the today's
> snapshot from http://cygwin.com/snapshots/ a try. Should be up in
> about
> half an hour.
The patched DLL now returns consistent msg_flags regardless of whether
or not the control message has been requested. Thanks!
Could I ask for another favor that since the native WSA msg_flags get
propagated to the CYGWIN environment, the definitions for the additional
flag bits, MSG_MCAST and MSG_BCAST (as defined by WSA) to be added to
<cygwin/socket.h> please?
http://msdn.microsoft.com/en-us/library/windows/desktop/ms741645%28v=vs.85%29.aspx
Anton Lavrentiev
Contractor NIH/NLM/NCBI
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results
2012-08-01 18:45 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C]
@ 2012-08-01 19:25 ` Corinna Vinschen
0 siblings, 0 replies; 4+ messages in thread
From: Corinna Vinschen @ 2012-08-01 19:25 UTC (permalink / raw)
To: cygwin
On Aug 1 14:35, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > I applied a patch which should fix this problem. It always uses
> > WSARecvMsg now, if called from recvmsg, still provided it is possible,
> > of course (No SOCK_STREAM, no AF_LOCAL).
> >
> > I'm just generating a new developer snapshot. Please give the today's
> > snapshot from http://cygwin.com/snapshots/ a try. Should be up in
> > about
> > half an hour.
>
> The patched DLL now returns consistent msg_flags regardless of whether
> or not the control message has been requested. Thanks!
>
> Could I ask for another favor that since the native WSA msg_flags get
> propagated to the CYGWIN environment, the definitions for the additional
> flag bits, MSG_MCAST and MSG_BCAST (as defined by WSA) to be added to
> <cygwin/socket.h> please?
Done. These are Windows-specific values not docuemnted by POSIX.
But Linux defines its own return values as well, so, never mind.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-08-01 18:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-31 16:44 Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2012-08-01 9:05 ` Corinna Vinschen
2012-08-01 18:45 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2012-08-01 19:25 ` Corinna Vinschen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).