RFE: IGMP support - Githubissues

lars18th commented 7 years ago

Hi,

I have one suggestion: Add support for IGMP server support. The idea is do the streaming only when someone joins the multicast address. The objective is execute the HTTP request only when some user needs the multicast stream.

This sounds good?

joolzg commented 7 years ago

Great idea. Question is there a mechanism that allows the notification of someone joining a new group

Sent from Yahoo Mail on Android

On Fri, 27 Jan 2017 at 15:31, lars18thnotifications@github.com wrote:
Hi,

I have one suggestion: Add support for IGMP server support. The idea is do the streaming only when someone joins the multicast address. The objective is execute the HTTP request only when some user needs the multicast stream.

This sounds good?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

lars18th commented 7 years ago

Hi @joolzg ,

Great idea. Question is there a mechanism that allows the notification of someone joining a new group

Fortunately exists one opensource project with this function implemented: the VDR plugin streamdev.

See the help here: http://github.com/varaslt/vdr-plugin-streamdev/blob/master/README#L297

And the main code only instantiates the "componentIGMP class": http://github.com/varaslt/vdr-plugin-streamdev/blob/9c12dba267d0ad21258a0e847ba99c6cebc75ae2/server/server.c#L44

I don't say that you need to incorporate this code, but you can use it as example. All the useful functions are here. However, if you like a more simple protocol description, then we can work together for describe it.

What you think?

lars18th commented 7 years ago

Hi @joolzg ,

I found another interesting source that you can use: the good old "imgpproxy" project. Here one uptodate fork: http://github.com/ViToni/igmpproxy

I feel you can use this project to incorporating some code. Let me to explain it:

The interesting code is the "igmp.c" source: http://github.com/ViToni/igmpproxy/blob/next/src/igmp.c It has the basic functions for Init, Read and Send IMGP packets.
The second part is the main loop running in the tool. Here the loop: http://github.com/ViToni/igmpproxy/blob/d595329bcb55e936b9f8a2b0a719d07086fd2c5f/src/igmpproxy.c#L269 This loop is executed after the call to "initIgmp()" and the interesting part is the call to "acceptIgmp(recvlen);" when a new IGMP packet arrives. This is related to the 'listening' part of the protocol.
The 'sending' part isn't relevant (found here: http://github.com/ViToni/igmpproxy/blob/d595329bcb55e936b9f8a2b0a719d07086fd2c5f/src/request.c#L192 ). As you only need to start/stop traffic as listeners joins/leaves the group, you don't care about sending IGMP messages. So you only listen to them!

You will like to implement some initial support?

lars18th commented 7 years ago

Hi @gfto ,

You agree to implement this function?

At time, I can't found any opensource project (except the VDR plugin streamdev) with this funcionality. I feel will be very useful to have one "on-demand" multicast server based on IGMP.

I hope this sounds good to you! ;) Regards.

lars18th commented 7 years ago

Hi,

I'm considering an alternative implementation for supporting IGMP:

The idea is run one imgp-proxy daemon or pim-router daemon inside the same server where is running the tomcast process and catch the kernel routing table. So, when a new multicast route appears, then enable the channel inside the tomcast instance.

For implementing in this way, some changes are needed in tomcast. One of them is the avility for starting/stopping channels on-the-fly. So I suggest an approach similar to dvblast.sock and the dvblastctl tool:

Tomcast will include a control file like "/tmp/tomcast.sock", and using some calls to this file, you can execute internal commands, like:

echo "start 239.80.80.80:5000" > /tmp/tomcast.sock
echo "stop 239.80.80.80:5000" > /tmp/tomcast.sock
echo "start chan3" > /tmp/tomcast.sock
echo "stop chan3" > /tmp/tomcast.sock

I prefer the option for using the multicast output address as the id of the channel, instead of the name used in the channels.conf file. However, I feel it's easy to support both, and several users should prefer to use the name.

What you think?

lars18th commented 6 years ago

Hi @gfto ,

You feel that you can add some support for "starting"/"stoping" the channels using an external tool? If yes, then I can program an external tool for sending such messages (start-stop) to your tool based on IGMP requests.

You agree?

lars18th commented 6 years ago

Hi,

I discovered that someone is working on it: https://github.com/nerosketch/tomcast/commit/b30b45c8cce6019beed798e4f2915e99af77e758

lars18th commented 4 years ago

Hi,

I hope someone will continue developing this: https://github.com/nerosketch/tomcast/commit/b30b45c8cce6019beed798e4f2915e99af77e758

Regards.

lars18th commented 3 years ago

Hi,

No one interested in merge this? https://github.com/nerosketch/tomcast/commit/b30b45c8cce6019beed798e4f2915e99af77e758

lars18th commented 3 months ago