Recvfrom() not returning - Unix

This is a discussion on Recvfrom() not returning - Unix ; Hello, When I call recvfrom() for a UDP multicast client it runs fine on Windows XP, but does not return on Fedora Core 6. I know it is a blocking call and when the multicast peer transmits a message the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Recvfrom() not returning

  1. Recvfrom() not returning

    Hello,

    When I call recvfrom() for a UDP multicast client it runs fine on
    Windows XP, but does not return on Fedora Core 6. I know it is a
    blocking call and when the multicast peer transmits a message the
    exact same code running on a Windows machine on the same network will
    get the message and handle it properly while a Linux machine just
    doesn't return from the recvfrom() call. Furthermore, tcpdump shows a
    packet being transmitted by the source computer. Any ideas?

    Some fancy code:

    int MulticastClient:pen( char * address, int port )
    {
    int rc;
    struct ip_mreq mreq;
    struct in_addr mcastAddr;
    struct sockaddr_in mcast_group;
    struct hostent *h;
    #ifdef WIN32
    WORD wVersionRequested;
    WSADATA wsaData;

    wVersionRequested = MAKEWORD( 2, 0 );
    if(WSAStartup( wVersionRequested, &wsaData ) != 0) {
    printf( "1 Multicast:pen(), Windows Socket Initialization Error
    \n" );
    return 0;
    }
    #endif

    h = gethostbyname( address );
    if (h == NULL) {
    printf( "2 Multicast:pen(), gethostbyname failed '%s'\n",
    address );
    return 0;
    }

    memcpy(&mcastAddr, h->h_addr_list[0],h->h_length);

    /* check if dest address is multicast */
    if(!IN_MULTICAST(ntohl(mcastAddr.s_addr))) {
    printf( "3 Multicast:pen(), address '%s' is not multicast \n",
    inet_ntoa(mcastAddr) );
    #ifdef WIN32
    std::cout<<"Create_Socket:::Binding Error: "< occurred, could not create socket\n";
    WSACleanup();
    #else
    std::cout<<"Create_Socket:::Binding Error: could not create socket
    \n";
    #endif
    return 0;
    }

    /* create socket */
    sd = socket( AF_INET, SOCK_DGRAM, 0 );
    if (sd < 0) {
    perror( "4 Multicast:pen(), socket" );
    std::cout<<"Create_Socket:::Binding Error: could not create socket
    \n";
    return 0;
    }

    /* bind any port number */
    serverAddr.sin_family = AF_INET;
    serverAddr.sin_addr.s_addr = htonl( INADDR_ANY );
    //serverAddr.sin_addr.s_addr = inet_addr( address );
    serverAddr.sin_port = htons( port );

    memset(&mcast_group, 0, sizeof(mcast_group));
    mcast_group.sin_family = AF_INET;
    mcast_group.sin_port = htons((unsigned short int)strtol("7502", NULL,
    0));
    mcast_group.sin_addr.s_addr = inet_addr(address);


    u_int on = 0;
    std::string sOn = "0";
    #ifdef WIN32
    rc = setsockopt ( sd, SOL_SOCKET, SO_REUSEADDR, sOn.c_str(), sizeof
    ( on ) ) ;
    #else
    rc = setsockopt ( sd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof
    ( on ) ) ;
    #endif
    if( rc<0 ) {
    std::cout<<"Create_Socket:::Binding Error: could not set socket
    options.\n";
    }

    if ( bind( sd, (struct sockaddr *) &mcast_group,
    sizeof(mcast_group) ) < 0 ) {
    perror( "5 Multicast:pen(), bind" );
    #ifdef WIN32
    std::cout<<"Create_Socket:::Binding Error: "< occurred, could not create socket\n";
    WSACleanup();
    #else
    std::cout<<"Create_Socket:::Binding Error: could not create socket
    \n";
    #endif
    return 0;
    }

    /* join multicast group */
    //mreq.imr_multiaddr.s_addr=mcastAddr.s_addr;
    mreq.imr_multiaddr = mcast_group.sin_addr;
    mreq.imr_interface.s_addr=htonl(INADDR_ANY);

    char mreq_ch[128] = {0};
    std::string mreq_st;
    sprintf(mreq_ch,"%s",(char *) &mreq);
    mreq_st = mreq_ch;
    rc = setsockopt(sd,IPPROTO_IP,IP_ADD_MEMBERSHIP, (char *) &mreq,
    sizeof(mreq));
    if (rc < 0) {
    perror( "6 Multicast:pen(), setsockopt,
    IP_ADD_MEMBERSHIP" );
    #ifdef WIN32
    std::cout<<"Create_Socket:::Binding Error: "< occurred, could not create socket\n";
    WSACleanup();
    #else
    std::cout<<"Create_Socket:::Binding Error: could not create socket
    \n";
    #endif
    return 0;
    }

    printf( "7 INFO: listening to mgroup %s:%d\n",
    inet_ntoa(mcastAddr), port);
    return 1;
    }


    int MulticastClient::read( void )
    {
    //printf("MulticastClient::read()\n");
    memset( &clientAddr, 0, sizeof( clientAddr ) );
    socklen_t clientLen = sizeof( clientAddr );
    setBufferSize(20000);
    printf("MulticastClient::read() - recvfrom() before.\n");
    dataSize = recvfrom( sd, (char *)buffer, bufferSize, 0, (struct
    sockaddr *) &clientAddr, &clientLen );
    //dataSize = recvfrom( sd, (char *)buffer, bufferSize,
    MSG_WAITALL, (struct sockaddr *) &clientAddr, &clientLen );
    //dataSize = recv( sd, (char *)buffer, bufferSize, 0 );
    printf("MulticastClient::read() - recvfrom() after. read %d bytes\n",
    dataSize);
    if( dataSize < 0) {
    perror( "MulticastClient::read, recvfrom" );
    }
    return dataSize;
    }


  2. Re: Recvfrom() not returning

    sfncook@gmail.com wrote:
    > Hello,
    >
    > When I call recvfrom() for a UDP multicast client it runs fine on
    > Windows XP, but does not return on Fedora Core 6. I know it is a
    > blocking call and when the multicast peer transmits a message the
    > exact same code running on a Windows machine on the same network will
    > get the message and handle it properly while a Linux machine just
    > doesn't return from the recvfrom() call. Furthermore, tcpdump shows a
    > packet being transmitted by the source computer. Any ideas?


    Well, the client on the Linux machine doesn't realise that the message
    is addressed to it.

    netstat will tell you what messages it is listening for.

    Robert

    >
    > Some fancy code:
    >
    > [snip]


  3. Re: Recvfrom() not returning

    sfncook wrote:

    > When I call recvfrom() for a UDP multicast client it runs fine on
    > Windows XP, but does not return on Fedora Core 6. I know it is a
    > blocking call and when the multicast peer transmits a message the
    > exact same code running on a Windows machine on the same network will
    > get the message and handle it properly while a Linux machine just
    > doesn't return from the recvfrom() call. Furthermore, tcpdump shows a
    > packet being transmitted by the source computer. Any ideas?


    Start your app, then switch to a console.

    What is the ouput of netstat -g

  4. Re: Recvfrom() not returning

    Output from netstat -g:

    [root@localhost-localdomain simpleMCastServer]# netstat -g
    IPv6/IPv4 Group Memberships
    Interface RefCnt Group
    --------------- ------ ---------------------
    lo 1 ALL-SYSTEMS.MCAST.NET
    eth0 1 234.0.1.2
    eth0 1 224.0.0.251
    eth0 1 ALL-SYSTEMS.MCAST.NET
    lo 1 ff02::1
    eth0 1 ff02::fb
    eth0 1 ff02::1:ff7e:6bc6
    eth0 1 ff02::1


    That's my app listening to 234.0.1.2 (port 1501). The plot has
    thickened thusly: 234.0.1.2:1501 shows up on netstat-g but my app
    still does not respond (it blocks on recvfrom() and doesn't return).
    However, 234.0.1.2:1501 is *not* the iport I want to use. I need to
    be using 224.0.0.2:7502 in order to listen to another app (someone
    else's app - out of my hands). But when I configure my app to listen
    to that iport it does *not* show up in netstat -g. This may be an
    entirely unrelated issue and I would almost rather just get this
    iport working and force the developer of the server app to change
    his iport before dealing with yet another problem here.

    I'm going to repeat myself here: the multicast client library I'm
    using works fine on both Windows *and* Mac (10.4 and others).

    Thanks for any further help, folks.

    -S.


  5. Re: Recvfrom() not returning

    I just found this post that seems a little similar:

    http://groups.google.com/group/mlist...300876779b8af2

    On Oct 9, 11:45 am, sfnc...@gmail.com wrote:
    > Output from netstat -g:
    >
    > [root@localhost-localdomain simpleMCastServer]# netstat -g
    > IPv6/IPv4 Group Memberships
    > Interface RefCnt Group
    > --------------- ------ ---------------------
    > lo 1 ALL-SYSTEMS.MCAST.NET
    > eth0 1 234.0.1.2
    > eth0 1 224.0.0.251
    > eth0 1 ALL-SYSTEMS.MCAST.NET
    > lo 1 ff02::1
    > eth0 1 ff02::fb
    > eth0 1 ff02::1:ff7e:6bc6
    > eth0 1 ff02::1
    >
    > That's my app listening to 234.0.1.2 (port 1501). The plot has
    > thickened thusly: 234.0.1.2:1501 shows up on netstat-g but my app
    > still does not respond (it blocks on recvfrom() and doesn't return).
    > However, 234.0.1.2:1501 is *not* the iport I want to use. I need to
    > be using 224.0.0.2:7502 in order to listen to another app (someone
    > else's app - out of my hands). But when I configure my app to listen
    > to that iport it does *not* show up in netstat -g. This may be an
    > entirely unrelated issue and I would almost rather just get this
    > iport working and force the developer of the server app to change
    > his iport before dealing with yet another problem here.
    >
    > I'm going to repeat myself here: the multicast client library I'm
    > using works fine on both Windows *and* Mac (10.4 and others).
    >
    > Thanks for any further help, folks.
    >
    > -S.




  6. Re: Recvfrom() not returning

    Mmmmmmy bad. ) Just a firewall getting all up in my business. I
    disabled that and it immediately started working. Don't you love
    those problems?

    For posterity: the firewall was allowing the message to be read by
    tcpdump - but not sending the message on to my application.

    -S.



    On Oct 9, 12:16 pm, sfnc...@gmail.com wrote:
    > I just found this post that seems a little similar:
    >
    > http://groups.google.com/group/mlist...hread/thread/3...
    >
    > On Oct 9, 11:45 am, sfnc...@gmail.com wrote:
    >
    > > Output from netstat -g:

    >
    > > [root@localhost-localdomain simpleMCastServer]# netstat -g
    > > IPv6/IPv4 Group Memberships
    > > Interface RefCnt Group
    > > --------------- ------ ---------------------
    > > lo 1 ALL-SYSTEMS.MCAST.NET
    > > eth0 1 234.0.1.2
    > > eth0 1 224.0.0.251
    > > eth0 1 ALL-SYSTEMS.MCAST.NET
    > > lo 1 ff02::1
    > > eth0 1 ff02::fb
    > > eth0 1 ff02::1:ff7e:6bc6
    > > eth0 1 ff02::1

    >
    > > That's my app listening to 234.0.1.2 (port 1501). The plot has
    > > thickened thusly: 234.0.1.2:1501 shows up on netstat-g but my app
    > > still does not respond (it blocks on recvfrom() and doesn't return).
    > > However, 234.0.1.2:1501 is *not* the iport I want to use. I need to
    > > be using 224.0.0.2:7502 in order to listen to another app (someone
    > > else's app - out of my hands). But when I configure my app to listen
    > > to that iport it does *not* show up in netstat -g. This may be an
    > > entirely unrelated issue and I would almost rather just get this
    > > iport working and force the developer of the server app to change
    > > his iport before dealing with yet another problem here.

    >
    > > I'm going to repeat myself here: the multicast client library I'm
    > > using works fine on both Windows *and* Mac (10.4 and others).

    >
    > > Thanks for any further help, folks.

    >
    > > -S.




+ Reply to Thread