Score:0

Does Windows automatically leave unused multicast groups?

cg flag

When troubleshooting multicast, I found no reference on the meaning of the fields returned by this command:

C:\Users\Administrator>netsh int ip show joins level=verbose
    
 Interface 5: Ethernet0
    
 Multicast Address : 224.0.0.1
 Scope             : 0
 References        : 0
 Last Reporter?    : Yes
    
 Multicast Address : 224.0.0.251
 Scope             : 0
 References        : 2
 Last Reporter?    : Yes
    
 Multicast Address : 224.0.0.252
 Scope             : 0
 References        : 1
 Last Reporter?    : Yes

What do Scope, References and Last Reporter mean?

I guess References mean the number of processes listening to that specific multicast group. In case an application stops/crashes before leaving the multicast group it was using that number goes to zero, but actually it's not removed from the list and the machine keeps receiving multicast stream. Is there any setting preventing this e.g. after some time the multicast group is no longer used by any process, the OS leaves it automatically?

This is happening on Windows 10 and Windows Server 2019 using (by default) IGMPv3.

Score:0
cn flag

The formal name for IGMP join/leave is IGMP Membership Report. An upstream router that deals with IGMP on a multiaccess network is called Querier. It does indeed Query all hosts (224.0.0.1) periodically for their actual group membership status.

As multiaccess network could be quite large, this may trigger an influx of IGMP Membership Reports that may overwhelm the network or a Querier itself; given the nature of multicast it does not really matter how many hosts on a network listen to the particular group, just one would be sufficient to continue streaming this group on an interface.

For that matter upon receiving IGMP Query all hosts start a random timer and first one to expire sends its Membership Report to 224.0.0.1 for the Querier and others to hear. If host has heard that it's groups have been already reported, it cancels the timer. The architecture is built so that in most cases only a few hosts will actually respond to Query. The host that has reported a group during this process is called Last Reporter for this group.

As you can see the upstream router has no idea how many clients listen to a particular group. So when host sends Leave Report the router does not (and should not by design) immediately stop this multicast stream on an interface as there could be other clients listening to it. Instead it sends IGMP Specific Query to this particular group (i.e. 239.0.0.1) to trigger some other clients that listen to it to send back their Membership Report.

As all of this Query/Report stuff is sent asynchronously and unreliably over multicast there is a non-zero probability that this Specific Query might not get an immediate Report back due to packet loss or other issues, so the router by default tries to send it twice (over two Query Intervals) and only then the multicast group is pruned on an interface and traffic flow stops. The same applies if for a standard Membership Query (on 224.0.0.1) the particular group is not reported back twice, this might happen if a software or hardware malfunctions before being able to send a Leave Report for a group.

The Scope as such is a multicast address scope that roots back in the days of old and glorious Global Internet Multicast Routing Dream and specifies the area where this group should circulate, 0 means local network in IPv4.

kuma avatar
cg flag
_this might happen if a software or hardware malfunctions before being able to send a Leave Report for a group_ I guess in this case this group will keep appearing in the output of `netsh int ip show join` with 0 references, and will be received by the computer until shutdown? If so, is there a way to prevent this?
Peter Zhabin avatar
cn flag
This group will be garbage collected by kernel and wiped after certain small amount of time. Just did a quick test - launched my IPTV client on a Windows PC and started some channel. It appeared in `netsh int ip show join` with 2 references, as the client has two processes. Then, I killed it with fire, that is I have terminated it forcefully with `TerminateProcess`. The group in question was shown with 0 references for about 10-15 seconds after that and then it disappeared completely. What is the real problem you're trying to solve?
kuma avatar
cg flag
the group in question is shown with 0 references, never disappears and packets from that multicast group are received indefinitely. Apparently the garbage collector is not working? How to check that?
Peter Zhabin avatar
cn flag
In your example above `224.0.0.1` is `all-hosts` and treated by the kernel itself, so it has 0 references but would never disappear. It might be the group you're looking at is something like this, could you please be more specific, i.e. provide group address and usage scenario?
kuma avatar
cg flag
the multicast I'm referring to was not captured in the screenshot. It was an administratively scoped multicast (e.g. 239.10.10.10). My scenario is very similar to that previous of yours: launched a custom application which joined a multicast group, then I terminate the application forcefully and the multicast group in question is shown with 0 references, never disappears and packets from that group are received indefinitely. I don't understand why this happens and why doing the same with VLC (terminating the application forcefully) causes the group to disappear immediately.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.