Picon
Favicon

Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results

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*/

(Continue reading)

Corinna Vinschen | 1 Aug 2012 11:05
Favicon

Re: Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results

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*/
(Continue reading)

Picon
Favicon

RE: Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results

> 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

Corinna Vinschen | 1 Aug 2012 20:57
Favicon

Re: Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results

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


Gmane