locked
Missing IGMP leaves RRS feed

  • Question

  • We're working on an application which requires joining and leaving several multicast groups and we observe that if we add more than three IP group memberships

        if (SOCKET_ERROR == ::setsockopt(
            m_mySocket, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char *)&mreq, sizeof (mreq)))
        { .... }

    And then remove IP membership - same call but with IP_DROP_MEMBERSHIP - we end up only seeing two IGMP leaves in the network trace.

    We know our "DROP" is being processed by the IP stack because we check using "netsh interface ipv4 show joins" before and after invoking the call.  The box also responds correctly to the next IGMP query (i.e. doesn't send a join for the DROPped group). We also know we're capturing it correctly since we've traced this in multiple PCs, in multiple locations, on the box running the software itself, from our network monitor port on our switch, and using two different capture tools.

    So, I have a few questions:

    1. Is there a configuration that would cause Windows7 to only send out two leaves?  And if so, how do we change it?

    2. Was this an IP stack design decision?  It seems like we could end up with a lot of unnecessary multicast routes in our network if we only synch up on the next IGMP query (in our dev lab its set to 30 seconds).

    3. Is there a good source that describes the IP stack multicast limitations/behaviors?

    Please feel free to move/let me know if there is a better forum for this question - I don't see a general "network programming" forum.  I submitted it to Peer-to-peer networking also, but haven't received any feedback there.

    Tuesday, March 6, 2012 9:31 PM

Answers

  • We discovered the reason for the missing joins.  From RFC 2236:

       When a host leaves a multicast group, if it was the last host to reply to a Query with a Membership Report for that group, it SHOULD send a Leave Group message to the all-routers multicast group (224.0.0.2). If it was not the last host to reply to a Query, it MAYsend nothing as there must be another member on the subnet. 

    The IP stack in our previous products embedded OS did not implement the optimization and always left regardless of what other boxes were joined to the group.  The Windows IP stack appears to have implemented the optimization described above by monitoring what other boxes have responded to the last group query and letting them send the leave.  Once we tracked down what other devices were joining and leaving (or NOT leaving) the same group, we removed them from the equation and saw the leaves we were expecting originally.

    • Marked as answer by Larry_1971 Wednesday, March 7, 2012 10:40 PM
    Wednesday, March 7, 2012 10:40 PM