[vlc-devel] Re: CVS Commit (lool)
lool at via.ecp.fr
Fri Jan 10 06:56:48 CET 2003
> STATUS AUTHORS
Quick test :
slptool register \
vlc --nosap slp:
I introduced a new access module based on libslp, let me explain the
reasons for this choice:
1/ reasons for this module
- we need a way to get the list of available streams in a simple
- preferably with a standardized, modern protocol,
- the smaller the amount of code to maintain, the better.
2/ advantages and inconvenients versus the SAP module
a/ The SAP module relies on a receive only protocol, which means that
when you launch your program, it has to wait for the next announce
to come. Instead of proceeding the same way, the SLP module
announces its need for a service.
This permits the caching of service adresses at the client system
level. This is usually implemented as a daemon listenin and
answering on a first socket for client queries and sending or
listening queries on the multicast public socket.
As fenrir had some thoughts on implementing SAP in vlc, he came
to the conclusion that to satisfy our users we should have a daemon
listening to the announces somewhere (on the network or on the
b/ Another solution would be to shorten the delay between SAP
announces, but this increases the traffic noticeably if you
plan to use multiple SAP announcers. And this violates the SAP
To address the problem of immediate channel listing at the start
of vlc, the only option seems to be a local daemon. OpenSLP provides
such a daemon, that's something less to develop.
c/ SAP has a limited namespace and can only provide some formats like
SDP, SLP does not come with a particular session description
protocol but is meant to be universal. SLP offers a wider namespace,
different types of searches (imagine a "findsrv vls channel=2" or a
"findsrv vls name=djtv", you're close to the protocol).
d/ SLP is very flexible on the source of the data: the library (the
User Agent) first tries a connection with a local daemon, then
searchs in its scope for a Service Agent which could have buffered
the informations, or searchs directly on a Directory Agent (bound to
many Service Agents). The SA and DA might forward the requests by
themselves, or have hardcoded values, or have recorded the answers
e/ Currently, SAP is wider spread than SLP.
f/ There's no more need for a vlcs, the slpd server manages the SA, and
DA roles in parallel.
3/ Current problems with the SLP and SAP modules
a/ The SLP module only searches for "vls.services.videolan.org:udpm"
services, I choosed our DNS as namespace and udpm for multicast over
udp. This might be a wrong choice, I picked the first value I found.
b/ The modules only expects a dns:port or ip:port answer, and discards
parameters and lifetime.
c/ The SAP module is always built, and always loaded on startup.
d/ The SLP module sends a -1 on return of Open() to skip to the next
item of the playlist.
e/ The SLP module is synchronous, but libslp allows asynchronous
f/ vls isn't yet SLP aware.
4/ Why an access module?
I wanted something easy to load on user demand and capable or url
I would be pleased to hear of nicer ways to do this.
Random thoughts :
. we now might have multiple servers destinated to the same udp port
for two programs on the same system (consider servers sending to a
broadcast address instead of a multicast address)
. we might announce multiple streams or multiple servers for the same
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vlc-devel