[streaming] Re: Multicast question

[Bill Eldridge]

Stefan Seyfried wrote:

>Psycho Ph <degreane at yahoo.com> writes:
>  
>
>>MMM I am interested with your "V4L-VOD Suite" Can I
>>have more information about It ????
>>    
>>
>
>http://www.via.ecp.fr/via/ml/streaming/200310/msg00134.html
>
>  
>
>>That would allow alot of bandwidth saving over the
>>local network ..... I Believe its a serious issue when
>>talking about VideoLan as a solution to replace normal
>>RF Cabling !!!!!
>>    
>>
>
>well, but it is a quick hack by me, mostly to serve 1 client
>of 1 server. But it stops the streaming when you quit the client :-)
>

I'm not sure how many switches work with multicast control, but
a quick search on the internet found Zarlink, that suppresses forwarding
multicast packets if there are no clients - thus a session goes from server
to switch and is dropped.  Okay, it's still a load on the server, but not
the LAN.

If the Linux box is doing Multicast routing, I believe it should
send out IGMP packets occasionally to everyone on the LAN,
but not send actual data packets unless they're subscribed.
(If you're not on a switched network, you get to see the traffic
anyway)

There's a new type of multicasting called "Explicit Multicasting"
that actually contains recipient lists. I don't know how well this
is supported, but there are papers at:

http://www.switch.ch/network/ipmcast/references.html#xcast

ANother approach might be to try putting vls on an internal
loopback interface, and then define a multicast route that goes
to the LAN, so that the daemon should(?) break this down
into individual sessions for the LAN rather than flooding the
multicast data to all addresses on the LAN.....

>It would be easy to implement it the way i wrote in the last mail:
>do some "keep-alive-ping" from the clients and kill the server if
>he doesn't receive such a ping for a certain time.
>Of course this scheme can be extended to more than one channel and
>more than one server.
>The pros of a solution like this are:
>  - no need for multicast enabled switches
>  - easy to implement (no patching of vls/vlc needed)
>The cons are:
>  - very hacky (an "admin solution" as my cow-orkers would say :-)
>  - need for an extra application / wrapper for vlc to notify the server
>    if the client has exited.
>  - need for an extra server process which listens for the keepalive-pings
>    and starts vls if someone is listening / kills vls if not.
>
>This extra application is easy to code for someone who has already
>heard of "fork" and "SIGCHLD", at least on linux it is just some lines
>of perl. The extra server is also very easy, some shell and inetd magic
>will do.
>
>Good luck
>
>    Stefan
>
>  
>
>>Best Regards
>>F.B.
>>--- Stefan Seyfried <seife at gmane0305.slipkontur.de>
>>wrote:
>>    
>>
>
>oh, and fullquotes at the end are almost always a bad idea.
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/streaming/attachments/20031022/1dac5d6e/attachment.htm