[vlc-devel] Re: CVS Commit (lool)

[Loïc Minier]

> STATUS AUTHORS

   (Added SLP.)

   Quick test :

    slptool register \
        service:vls.services.videolan.org:udpm://239.255.20.130:1234
    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
    manner,
  - 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
    client machine).

 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
    recommendations.
      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
    earlier.

 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
    callbacks.

 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
 sub-parsing.
   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
   stream easily


-- 
lool
-- 
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>