This is a discussion on mrouted configuration question within the Linux Networking forums, part of the Linux Forums category; I have a problem with an IP Multicast application running on Red Hat Linux with mrouted version 3.9 beta ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
I have a problem with an IP Multicast application running on Red Hat Linux with mrouted version 3.9 beta 3. The problem is that when my application drops a group (first by using IP_DROP_MEMBERSHIP, then closing the socket), the nearest mrouted router continues to forward packets from the group to the client. There occurs even when I have just 1 client running, so it isn't that there are other clients on the same LAN requesting the same multicast group. Is there any way to make mrouted act upon the IP_DROP_MEMBERSHIP command? How can I get the smallest latency between the IP_DROP_MEMBERSHIP command and the actual end of packets being forwarded along my local link? Thanks, Dave |
|
|||
|
David Gotz wrote:
> I have a problem with an IP Multicast application running on Red Hat > Linux with mrouted version 3.9 beta 3. > > The problem is that when my application drops a group (first by using > IP_DROP_MEMBERSHIP, then closing the socket), the nearest mrouted > router continues to forward packets from the group to the client. > > There occurs even when I have just 1 client running, so it isn't that > there are other clients on the same LAN requesting the same multicast > group. > > Is there any way to make mrouted act upon the IP_DROP_MEMBERSHIP > command? How can I get the smallest latency between the IP_DROP_MEMBERSHIP > command and the actual end of packets being forwarded along my > local link? > > Thanks, > Dave > > it's very strange because when a client LEAVE the group multicast send a "igmp v2/v3 leave" then the mrouted daemon have few seconds to leave the client from group. Which type of leave send your client to mrouted v2 or v3? Platform of client? pppee |