Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Service Location Protocol
open-in-new
<h2 id="overview">Overview</h2> <p>SLP is used by devices to announce <i>services</i> on a local network. Each service must have a <a href="/facts/Uniform_Resource_Locator/pPD5g7Wq">URL</a> that is used to locate the service. Additionally it may have an unlimited number of name/value pairs, called <i>attributes</i>. Each device must always be in one or more <i>scopes</i>. Scopes are simple strings and are used to group services, comparable to the <i>network neighborhood</i> in other systems. A device cannot see services that are in different scopes. </p><p>The URL of a printer could look like: </p> service:printer:lpr://myprinter/myqueue <p>This URL describes a queue called "myqueue" on a printer with the host name "myprinter". The protocol used by the printer is <a href="/facts/Line_Printer_Daemon_protocol/FAGe70Yn">LPR</a>. Note that a special URL scheme "service:" is used by the printer. "service:" URLs are not required: any URL scheme can be used, but they allow you to search for all services of the same type (e.g. all printers) regardless of the protocol that they use. The first three components of the "service:" URL type ("service:printer:lpr") are also called <i>service type</i>. The first two components ("service:printer") are called <i>abstract service type</i>. In a non-"service:" URL the schema name is the service type (for instance "http" in "<a href="https://www.wikipedia.org">http://www.wikipedia.org</a>"). </p><p>The attributes of the printer could look like: </p> (printer-name=Hugo), (printer-natural-language-configured=en-us), (printer-location=In my home office), (printer-document-format-supported=application/postscript), (printer-color-supported=false), (printer-compression-supported=deflate, gzip) <p>The example uses the standard syntax for attributes in SLP, only newlines have been added to improve readability. </p><p>The definition of a "service:" URL and the allowed attributes for the URL are specified by a <i>service template</i>, a formalized description of the URL syntax and the attributes. Service templates are defined in RFC 2609. </p><p>SLP allows several query types to locate services and obtain information about them: </p> <ul><li>It can search for all services with the same service type or abstract service type</li> <li>The query can be combined with a query for attributes, using <a href="/facts/Lightweight_Directory_Access_Protocol/KgpfD8nR">LDAP</a>'s query language.</li> <li>Given its URL, the attributes of a service can be requested. In standard SLP the attributes are not returned in the query result and must be fetched separately. The Attribute List Extension (RFC 3059) fixes this problem.</li> <li>A list of all service types can be obtained</li> <li>A list of all existing scopes can be requested.</li></ul> <h2 id="roles">Roles</h2> <p>SLP has three different roles for devices. A device can also have two or all three roles at the same time. </p> <ul><li><i>User Agents</i> (UA) are devices that search for services</li> <li><i>Service Agents</i> (SA) are devices that announce one or more services</li> <li><i>Directory Agents</i> (DA) are devices that cache services information. They are used in larger networks to reduce the amount of traffic and allow SLP to scale. The existence of DAs in a network is optional, but if a DA is present, UAs and SAs are required to use it instead of communicating directly.</li></ul> <p>Today most implementations are <a href="/facts/Daemon_(computer_software)/bzuEVGGX">daemons</a> that can act both as UA and SA. Usually they can be configured to become a DA as well. </p> <h2 id="network-protocol">Network protocol</h2> <p>SLP is a packet-oriented protocol. Most packets are transmitted using <a href="/facts/User_Datagram_Protocol/dxLU0D6q">UDP</a>, but <a href="/facts/Transmission_Control_Protocol/WW4sPrt9">TCP</a> can also be used for the transmission of longer packets. Because of the potential unreliability of UDP, SLP repeats all multicasts several times in increasing intervals until an answer has been received. All devices are required to listen on port 427 for UDP packets, Service Agents (SA) and Directory Agents (DA) should also listen for TCP on the same port. <a href="/facts/Multicast/D9IspSfl">Multicasting</a> is used extensively by SLP, especially by devices that join a network and need to find other devices. </p><p>The operation of SLP differs considerably, depending on whether a DA is in the network or not. When a client first joins a network it multicasts a query for DAs on the network. If no DA answers it will assume that it is in a network without DAs. It is also possible to add DAs later, as they multicast a 'heartbeat' packet in a predefined interval that will be received by all other devices. When an SA discovers a DA, it is required to register all services at the DA. When a service disappears the SA should notify the DA and unregister it. </p><p>In order to send a query in a network without a DA, the UA sends a multicast UDP packet that contains the query. All SAs that contain matches will send a UDP answer to the UA. If the answer is too large to fit into a single UDP packet, the packet will be marked as "overflown" and the UA is free to send the query directly to the SA using TCP, which can transmit packets of any size. </p><p>In order to send a query in a network with a DA, the UA will send the query packet to the DA using either UDP or TCP. As every SA must register all services with the DA, the DA is able to fulfill the request completely and simply sends the result back to the UA. </p> <h2 id="security">Security</h2> <p>SLP contains a security mechanism, based on <a href="/facts/Public_key/gowoFTxS">public-key cryptography</a>, that allows signing of service announcements. In practice it is rarely used: </p> <ul><li>The public keys of every service provider must be installed on every UA. This requirement defeats the original purpose of SLP, being able to locate services without prior configuration.</li> <li>Protecting only the services is not enough. Service URLs contain host names or IP addresses, and in a local network it is almost impossible to prevent <a href="/facts/Internet_protocol_spoofing/W7Ba2do5">IP or DNS spoofing</a>. Thus only guaranteeing the authenticity of the URL is not enough if any device can respond to the address.</li> <li>As addresses can be spoofed, the authenticity of the device must be proven at a different level anyway, e.g. in the application protocol (e.g. with <a href="/facts/Secure_Sockets_Layer/pGy16TnA">SSL</a>) or in the packet layer (<a href="/facts/IPsec/01MwcET1">IPsec</a>). Doing it additionally in SLP does not provide much additional security.</li></ul> <h2 id="adoption">Adoption</h2> <ul><li>SLP is frequently used for locating printers and supported by printing systems such as <a href="/facts/CUPS/GH6I7g3U">CUPS</a>.</li> <li>SLP is often found in LAN-enabled printers, so that they are discoverable out of the box. Some client print drivers can use this for printer discovery.</li> <li><a href="/facts/Architecture_for_Control_Networks/YBnj25hA">ACN</a>, a protocol being developed for entertainment control, uses SLP to find different devices such as dimmers and intelligent lights.</li> <li><a href="/facts/Classic_Mac_OS/I5fQq44K">Classic Mac OS</a> and <a href="/facts/Mac_OS_X/Y93vVpTm">Mac OS X</a> up to version 10.1 used SLP to locate file shares and other services. However, features introduced with <a href="/facts/Mac_OS_X/Y93vVpTm">Mac OS X</a> (version 10.2 onwards) use <a href="/facts/Zeroconf/r16BGGIV">Zeroconf</a>.</li> <li><a href="/facts/Netware_Core_Protocol/EyfafDgW">Netware Core Protocol</a> (NCP) clients in a pure IP environment use SLP to locate <a href="/facts/Novell_NetWare/cfnyxMzs">Novell NetWare</a> and <a href="/facts/Novell_Open_Enterprise_Server/oWwhg2AV">Novell Open Enterprise Server</a> (OES) servers.</li> <li><a href="/facts/SUSE_Linux/TAEDo44B">SUSE Linux</a> supports SLP for a variety of services since version 9.1.</li> <li><a href="/facts/Sun_Microsystems/VJ9EzEFd">Sun Microsystems</a> supports SLPv1 and SLPv2 including SA, UA and DA functionality.<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a></li> <li>The <a href="/facts/Distributed_Management_Task_Force/rIh0qDbI">Distributed Management Task Force</a> has standardized discovery of <a href="/facts/Web-Based_Enterprise_Management/3lzqbFqq">WBEM Services</a> via SLP.</li> <li>The <a href="/facts/Storage_Networking_Industry_Association/nWXbIQI2">Storage Networking Industry Association</a> has mandated the use of SLP for services discovery in the <a href="/facts/SMI-S/wX2JSyHh">Storage Management Initiative - Specification</a>.</li></ul> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Avahi_(software)/gYEFgKA8">Avahi</a></li> <li><a href="/facts/Bonjour_(software)/gFBhvEtj">Bonjour</a></li> <li><a href="/facts/Dynamic_Host_Configuration_Protocol/lpASHnhz">Dynamic Host Configuration Protocol</a></li> <li><a href="/facts/Jini/Yb5YMeXB">Jini</a></li> <li><a href="/facts/Link-Local_Multicast_Name_Resolution/9H7aGMP5">Link-Local Multicast Name Resolution</a></li> <li><a href="/facts/OSGi/qh2yzbsu">OSGi</a> Alliance</li> <li><a href="/facts/Universal_Plug_and_Play/nrUmlpGr">Universal Plug and Play</a> (UPnP)</li> <li><a href="/facts/WS-Discovery/uloFqqhW">WS-Discovery</a></li> <li><a href="/facts/Zero-configuration_networking/r16BGGIV">Zero-configuration networking</a> (Zeroconf)</li></ul> <ul><li><a href="/facts/Silvia_Hagen/3J6rMgTE">Silvia Hagen</a>, Guide to Service Location Protocol, Podbooks.Com LLC, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 1-893939-35-9</li> <li>James Kempf, Robert St. Pierre, Pete St. Pierre: Service Location Protocol for Enterprise Networks: Implementing and Deploying a Dynamic Service Finder, John Wiley & Sons, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-471-31587-7</li> <li>Golden G. Richard: Service and Device Discovery : Protocols and Programming, McGraw-Hill Professional, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-07-137959-2</li> <li>Johan Hjelm: Creating Location Services for the Wireless Web, John Wiley & Sons, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-471-40261-3</li> <li>Anna Hac: Mobile Telecommunications Protocols for Data Networks, John Wiley & Sons, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-470-85056-6</li></ul> <h2 id="external-links">External links</h2> <ul><li><a href="https://web.archive.org/web/20150526232229/http://www.livetribe.org/Livetribe-SLP">The LiveTribe SLP/OSGi Module</a></li> <li><a href="http://srvloc.sourceforge.net/">Service Location Protocol Project</a></li> <li><a href="http://mslp.sourceforge.net/">Service Location Protocol Enhancements</a></li> <li><a href="http://www.openslp.org/">OpenSLP</a></li> <li><a href="http://jslp.sourceforge.net/">jSLP - A pure Java SLP implementation.</a></li> <li><a href="http://sourceforge.net/projects/sblim/">SBLIM CIM Client for Java</a> - includes an RFC 2614 compliant SLP implementation in Java.</li> <li><a href="http://citeseer.ist.psu.edu/334042.html">A Comparison Of Service Discovery Protocols And Implementation Of The Service Location Protocol</a></li> <li><a href="https://web.archive.org/web/20050312060250/http://www.ietf.org/html.charters/svrloc-charter.html">https://web.archive.org/web/20050312060250/http://www.ietf.org/html.charters/svrloc-charter.html</a> -- IETF SRVLOC <a href="/facts/Working_group/dFlAPASD">working group</a>, which created the SLP standard</li> <li><a href="https://web.archive.org/web/20070221140919/http://www.dmtf.org/standards/published_documents/DSP0205.pdf">WBEM Discovery Using SLP</a> by <a href="/facts/DMTF/rIh0qDbI">DMTF</a></li> <li><a href="https://web.archive.org/web/20070208002346/http://www.dmtf.org/standards/wbem/wbem.1.0.en">WBEM SLP Template</a> by DMTF</li> <li><a href="https://web.archive.org/web/20090124234243/http://www.ibm.com/developerworks/linux/library/l-slp/">Automate Client Management with the Service Location Protocol</a> a developerWorks article by M. Tim Jones</li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>Service Location Protocol Administration Guide (PDF), Sun Microsystems, February 2000, retrieved 2010-08-19 <a href="http://docs.oracle.com/cd/E19455-01/806-1412/806-1412.pdf" target="_blank">http://docs.oracle.com/cd/E19455-01/806-1412/806-1412.pdf</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> </ol>