RFE: IGMP support

[lars18th]

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]

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, lars18th<notifications@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]

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

The code related to IGMP management is here:
http://github.com/varaslt/vdr-plugin-streamdev/blob/9c12dba267d0ad21258a0e847ba99c6cebc75ae2/server/componentIGMP.c
http://github.com/varaslt/vdr-plugin-streamdev/blob/9c12dba267d0ad21258a0e847ba99c6cebc75ae2/server/connectionIGMP.c

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]

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]

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]

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]

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]

Hi,

I discovered that someone is working on it: nerosketch@b30b45c

[lars18th]

Hi,

I hope someone will continue developing this: nerosketch@b30b45c

Regards.

[lars18th]

Hi,

No one interested in merge this? nerosketch@b30b45c

[lars18th]

Hi @gfto ,

It's now time to merge nerosketch@b30b45c ?
And nerosketch@a717fd9 too?

Please, comment.
Regards.

[gfto]

Sure, just submit a MR and I'll check it out.

[lars18th]

Hi,

Some news: Initial (external) support is added in #12 .