How to find which process joined a multicast group?
Hi all Can anyone tell me how I find which process joined a multicast group? Basically I'm looking for the equivalent of 'netstat -ano', which lists all listening ports and which process is listening on them, but for multicast. I know I can use 'netsh interface ipv4 show joins' to show me which groups my PC has joined, but how can I find which process on my PC is responsible for each join? Hope that's clear, but let me know if any clarification is needed. Many thanks Rich.
January 19th, 2012 6:48am

Hi, Thank you for your question. I am trying to involve someone familiar with this topic to further look at this issue. Regards, Leo Huang TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.Leo Huang TechNet Community Support
Free Windows Admin Tool Kit Click here and download it now
January 23rd, 2012 2:08am

Thanks Leo. I really hope someone has the answer! I can't believe it can't be done!
January 23rd, 2012 6:24am

I don't know if this will help, but you can install Microsoft's Network Monitor 3.4: http://www.microsoft.com/download/en/details.aspx?id=4865. You may be able to set a filter for multicast groups. In either case NetMon is a very nice tool to have.
Free Windows Admin Tool Kit Click here and download it now
January 23rd, 2012 11:52am

Hi Rich, Per my knowledge, Multicasts work in the 2&3layers of the 7-layer OSI model. Unlike the binding relationship between Ports Number and Processes ID, the idea is that joining a multicast group only tells the IP and Data Link layer (which in some cases explicitly tells the hardware) to accept multicast datagrams destined to that group's IP address. It is not a per-process membership, but a per-host membership. Therefore, a process can just bind to a specfic port instead of an IP address for specfic usage. Thanks, Steven XiaoPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
January 23rd, 2012 4:47pm

Hi Steven, thanks for your reply. I agree that multicast works at both the data link and network layers and that it is the responsibility of the OS to form memberships and receive the frames and datagrams and pass them up the tree. I understand that the process wouldn't itself do all the work to communicate to the network drivers or the NIC hardware directly. However, the process must still request of the OS that it wants it to join a multicast group, surely? Think of the unicast parallel: a webserver, i.e. the process, tells the OS that it wants to listen on TCP port 80 and 443 and the OS then creates a listening socket on those ports, which we can interrogate with 'netstat -ano'. How is this different with multicast? Say I had a video player on which I wanted to receive an IPTV stream, I would enter into its config the multicast group to which that video was being streamed and then the video player process would request of the OS that it should join that multicast group. The OS must know to which process it needs to hand the data from the multicast packets, and all I'm after is a way to interrogate that. Does that make sense? Rich.
Free Windows Admin Tool Kit Click here and download it now
January 24th, 2012 7:08am

Thanks Darien, I'll definitely check out Network Monitor. I haven't used it before, but I have used Wireshark for packet capture. Perhaps Network Monitor can do stuff over and above Wireshark, but if they are similar then I suspect all it's going to do is show me the packets. I might be able to deduce from their contents what the process that sent them is, e.g. if the payload is an NTP packet then we could be pretty sure that it was a NTP process that joined the multicast group, but it's not definitive. But anyway, I will check it out and maybe it's more powerful than I can possibly imagine! ;-)
January 24th, 2012 2:54pm

Hi Rich, In my opinion, there is difference between the multicast and port when handling the requests from the OS to listen on the incoming information. The Ports are running on the Transport Level of OSI which is above the Network Level where the IP address(including Multicast) works. The Muticast is just an IP address in a specfic group. And just as we cannot nail down the process which owns the computer's IP address, it is hard to determine which process opens the IP addresses for multicasting. Best regards, Steven XiaoPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
January 26th, 2012 3:23am

Hi Rich, In my opinion, there is difference between the multicast and port when handling the requests from the OS to listen on the incoming information. The Ports are running on the Transport Level of OSI which is above the Network Level where the IP address(including Multicast) works. The Muticast is just an IP address in a specfic group. And just as we cannot nail down the process which owns the computer's IP address, it is hard to determine which process opens the IP addresses for multicasting. Best regards, Steven XiaoPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
January 26th, 2012 11:20am

Hi Rich, Is there any update regarding my further explanation? Thanks, Steven XiaoPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
January 29th, 2012 9:58pm

Hi, As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios. If the issue still persists, please feel free to reply this post directly so we will be notified to follow it up. You can also choose to unmark the answer as you wish. BTW, we’d love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems. Thanks for your understanding and efforts. Regards, Leo Huang TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here. Leo Huang TechNet Community Support
January 31st, 2012 2:40am

Hi Steven Sorry I haven't replied sooner, I was away all of last week. I'm afraid I still don't accept your explanation and I think all this talk of OSI layers is just a red herring. Joining a multicast group must be per process. I tell VLC, say, to listen to a video stream on a multicast address. I physically enter the address, say 239.255.255.240 into VLC's config. The VLC process then tells the OS to join the 239.255.255.240 group and it then sends out an IGMP request and the network does its thing. There must be something internal to the OS that maps the multicast group joined to the process that requested it. Otherwise how else would the OS know to which process to pass the data. Now, if there's no way to interrogate that, then fine, but it must exist in some form or other. In Linux this is all fairly straightforward. I can issue a 'netstat -anup' command and I get this back: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 239.255.255.240:1234 0.0.0.0:* 1879/vlc udp 0 0 0.0.0.0:46819 0.0.0.0:* 898/avahi-daemon: r udp 0 0 0.0.0.0:5353 0.0.0.0:* 898/avahi-daemon: r udp 0 0 0.0.0.0:68 0.0.0.0:* 932/dhclient udp6 0 0 :::5353 :::* 898/avahi-daemon: r udp6 0 0 :::45508 :::* 898/avahi-daemon: r I can clearly see that the 'vlc' process is the one responsible for joining the 239.255.255.240 group. Is there no way to do this on Windows? Thanks Rich.
Free Windows Admin Tool Kit Click here and download it now
February 6th, 2012 10:13am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics