<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Stefan Seyfried wrote:<br>
<blockquote type="cite"
cite="midiseg61-7s6.ln1@message-id.slipkontur.de">
<pre wrap="">Psycho Ph <a class="moz-txt-link-rfc2396E" href="mailto:degreane@yahoo.com"><degreane@yahoo.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">MMM I am interested with your "V4L-VOD Suite" Can I
have more information about It ????
</pre>
</blockquote>
<pre wrap=""><!---->
<a class="moz-txt-link-freetext" href="http://www.via.ecp.fr/via/ml/streaming/200310/msg00134.html">http://www.via.ecp.fr/via/ml/streaming/200310/msg00134.html</a>
</pre>
<blockquote type="cite">
<pre wrap="">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 !!!!!
</pre>
</blockquote>
<pre wrap=""><!---->
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 :-)</pre>
</blockquote>
<br>
I'm not sure how many switches work with multicast control, but<br>
a quick search on the internet found Zarlink, that suppresses forwarding<br>
multicast packets if there are no clients - thus a session goes from
server<br>
to switch and is dropped. Okay, it's still a load on the server, but
not<br>
the LAN.<br>
<br>
If the Linux box is doing Multicast routing, I believe it should<br>
send out IGMP packets occasionally to everyone on the LAN,<br>
but not send actual data packets unless they're subscribed.<br>
(If you're not on a switched network, you get to see the traffic<br>
anyway)<br>
<br>
There's a new type of multicasting called "Explicit Multicasting"<br>
that actually contains recipient lists. I don't know how well this<br>
is supported, but there are papers at:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.switch.ch/network/ipmcast/references.html#xcast">http://www.switch.ch/network/ipmcast/references.html#xcast</a><br>
<br>
ANother approach might be to try putting vls on an internal<br>
loopback interface, and then define a multicast route that goes<br>
to the LAN, so that the daemon should(?) break this down<br>
into individual sessions for the LAN rather than flooding the<br>
multicast data to all addresses on the LAN.....<br>
<br>
<blockquote type="cite"
cite="midiseg61-7s6.ln1@message-id.slipkontur.de">
<pre wrap="">
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
</pre>
<blockquote type="cite">
<pre wrap="">Best Regards
F.B.
--- Stefan Seyfried <a class="moz-txt-link-rfc2396E" href="mailto:seife@gmane0305.slipkontur.de"><seife@gmane0305.slipkontur.de></a>
wrote:
</pre>
</blockquote>
<pre wrap=""><!---->
oh, and fullquotes at the end are almost always a bad idea.
</pre>
</blockquote>
<br>
</body>
</html>