Sophie

Sophie

distrib > Mageia > 7 > armv7hl > media > core-release > by-pkgid > 7f3cf0ce551979d4886ecd4fa3b092cf > files > 21

openslp-2.0.0-10.mga7.armv7hl.rpm

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<!-- #BeginTemplate "../../../openslp.dwt" -->

<!--
    
    Pristine 1.0
    
    Design copyright Matt Dibb 2006
    www.mdibb.net

    Please feel free to use and modify this template for use on your site.  I dont mind
    if you use it for your personal site or a commercial site, but I do insist that it is
    not sold or given away in some "50,000 Templates!" package or something like that.

-->

    <head profile="http://www.w3.org/2005/10/profile">
        <meta http-equiv="Content-Language" content="en-gb" />
        <meta http-equiv="Content-Type" content="text/html; charset=windows-1252" />
        <link rel="stylesheet" type="text/css" href="../../../site.css" />
        <link rel="stylesheet" type="text/css" href="../../../print.css" media="print" />
        <link rel="alternate" type="application/rss+xml" title="OpenSLP&#8230;Recent Activity" href="http://www.sourceforge.net/export/rss2_keepsake.php?group_id=1730" />
        <link rel="alternate" type="application/rss+xml" title="OpenSLP&#8230;News" href="http://www.sourceforge.net/export/rss2_projnews.php?group_id=1730" />
        <link rel="alternate" type="application/rss+xml" title="OpenSLP&#8230;File Releases" href="http://www.sourceforge.net/api/file/index/project-id/1730/mtime/desc/limit/20/rss" />
        <link rel="alternate" type="application/rss+xml" title="OpenSLP&#8230;Reviews" href="http://www.sourceforge.net/projects/openslp/reviews_feed.rss" />
		<link rel="shortcut icon" href="../../../images/openslp_favicon_256color_48px.ico" />
        <!-- #BeginEditable "Page%20Style%20and%20Scripts" -->
	    <!-- #EndEditable -->
        <!-- #BeginEditable "Page%20Title" -->
<title>OpenSLP - Introduction To SLP</title>
	    <!-- #EndEditable -->
    </head>
    <body>
        <div id="content">
            <div id="header">
            	<a href="http://openslp.org/">
				<img src="../../../images/openslp_logo_web_color_150px.jpg" alt="" /></a>
            </div>
            <div id="body">
                <!-- #BeginEditable "Left%20Navigation%20-%20Context%20Specific" -->

                <!-- #EndEditable -->
                <div id="links">
                    <p><a href="../../../index.html">About</a><br/>
                       what is openslp</p>
                    <p><a href="../../../download.html">Download</a><br/>
                       how to get openslp</p>
                    <p><a href="../../../contribute.html">Contribute</a><br/>
                       how to help out</p>
                    <p><a href="../../../documentation.html">Documentation</a><br/>
                       how to find out more</p>
                    <p><a href="../../../credits.html">Credits</a><br/>
                       who to blame</p>
                    <p><a href="http://sourceforge.net/projects/openslp"><img src="http://sflogo.sourceforge.net/sflogo.php?group_id=1730&amp;type=2" alt="Get OpenSLP at SourceForge.net. Fast, secure and Free Open Source software downloads"/></a></p>
                </div>

                <div id="main">
                <!-- #BeginEditable "Page%20Content" -->

<h2>What Is Service Location Protocol?</h2>

<b>Original Draft: <a href="http://www.calderasystems.com">Caldera
Systems, Inc</a></b><br/>
<b>Current Revision: <a href="http://www.novell.com">openslp.org</a></b>

<p>The <em>Service Location Protocol</em> (SLP) was originally an 
<em>Internet Engineering Task Force</em> (IETF) standards track protocol that
provides a framework to allow networking applications to discover the existence,
location, and configuration of networked services in enterprise networks.
Traditionally, in order to locate services on the network, users of network
applications have been required to supply the host name or network address
of the machine that provides a desired service. Ensuring that users
and applications are supplied with the correct information has, in many
cases, become an administrative nightmare.</p>

<p>Protocols that support service location are often taken for granted,
mostly because they are already included (without fanfare) in many network
operating systems. For example, without Microsoft's SMB service location
facilities, "Network Neighborhood" could not discover services available
for use on the network and Novell NetWare would be unable to locate
eDirectory trees. Nevertheless, an IETF sponsored protocol for service
location was not standardized until the advent of SLP. Because it is not 
tied to a proprietary technology, SLP provides a service location solution 
that could become extremely important (especially on Unix) platforms.</p>

<h3>About this Document</h3>
<p>Like all IETF standards, SLP is described in great detail by documents called Request
For Comments (RFC's). IETF RFCs are usually lengthy, very detailed, and written 
using precise language and notations. This whitepaper, on the other hand, was 
written to give a general overview of SLP. This document will, by nature, 
omit important details that would be interesting to the more technical reader. 
For these details, the reader is referred the following RFCs:</p>

<blockquote>
  <a href="../../rfc/rfc2165.txt">RFC 2165</a> - Service Location Protocol, Version 1<br />
  <a href="../../rfc/rfc2608.txt">RFC 2608</a> - Service Location Protocol, Version 2<br />
  <a href="../../rfc/rfc2609.txt">RFC 2609</a> - Service Templates and Service Schemes<br />
  <a href="../../rfc/rfc2614.txt">RFC 2614</a> - An API for Service Location Protocol
</blockquote>

<h3>SLP for Users and Administrators</h3>

<p>SLP can eliminate the need for users to know the names of network
hosts. With SLP, the user only needs to know the description of the
service he is interested in. Based on this description, SLP is then able to
return the URL of the desired service.</p>

<p>Consider the following example of a new employee setting up his workstation
to use one of the department printers. Here's a dialog between this new
employee (<em>Newbie</em>), and his coworker (<em>Stan</em>), who's been
around for a while:</p>

<blockquote>
<b><u>Traditional</u></b><br/>
  <em>Newbie</em>: "Hey Stan, the setup program is asking me for the name
of our printer. What should I type in?"<br/>
  <em>Stan</em>: "Which printer do you want?"<br/>
  <em>Newbie</em>: "The big one by the copier."<br/>
  <em>Stan</em>: "I've heard it doesn't work well with postscript
applications. You'll have to use the one down the hall."<br/>
  <em>Newbie</em>: "Ok. What should I type in."<br/>
  <em>Stan</em>: "Actually, I don't know; I use the one by the copier. You'll
probably have to call the IS help desk."<br/>
  <em>Newbie</em>: &lt;groan&gt; ...

  <p><b><u>With SLP</u></b><br/>
A setup program uses SLP to display to the user the description (including
location) of the printers that work with postscript. The user selects one
that is close to his office. The SLP service returns all necessary
addressing information directly to his device setup application.</p>
</blockquote>

<h3>SLP for Software Developers</h3>

<p>In many cases, SLP can eliminate the need for software applications to
prompt users for host names, or to read host names from configuration
files.</p>

<p>Consider the following example of a software engineer who is writing
an LDAP-enabled application.&nbsp;&nbsp;</p>

<blockquote><b><u>Traditional</u></b><br/>
Currently, the only way to know the hostname of the LDAP server to
use in the call to ldap_init() is to read it from a configuration file.
The configuration file must be created at install time and updated as the
location of the LDAP server changes. Keeping this configuration file
up to date becomes a real problem, especially when the LDAP application
is installed on a laptop that connects to various networks.

<p><b><u>With SLP</u></b><br/>
The developer uses SLP to obtain the host names and attributes of LDAP
servers that are displayed to the user at install time, and again if the
user desires to connect to a different LDAP server.</p>

</blockquote>
<p>As illustrated in the example above, SLP does not always eliminate the
need to prompt users for information.&nbsp; However, it does allow the
software developer to present a descriptive list of services that can be
understood by the user.</p>

<h3>Agents</h3>

<p>In order to understand the rest of this document (as well as all other
SLP documentation), you will need to know about SLP <em>agents</em>. In SLP
an agent is a software entity that processes SLP protocol messages.
There are three types of SLP agents:&nbsp;<br/>

<blockquote>
<p><b>User Agent (UA)</b><br/>
The SLP <em>User Agent</em> is a software entity that is looking for the location
of one or more services. Usually implemented (at least partially), as a
library to which client applications link, it provides client applications with 
a simple interface for accessing SLP registered service information.</p>

<p><b>Service Agent (SA)</b><br/>
The SLP <em>Service Agent</em> is a software entity that advertises the location
of one or more services. SLP advertisement is designed to be both
scalable and effective, minimizing the use of network bandwidth through
the use of targeted multi-cast messages, and uni-cast responses to queries.</p>

<p><b>Directory Agent(DA)</b><br/>
The SLP <em>Directory Agent</em> is a software entity that acts as a centralized
repository for service location information. Both Service Agents and
User Agents make it a priority to discover available Directory Agents,
as using a Directory Agent minimizes the amount of multi-cast messages
sent by the protocol on the network.</p>
</blockquote>

<h3>Messages</h3>

<p>In order to be able to provide a "framework" for service location, SLP
agents communicate with each other using eleven (11) different types of
messages. The dialog between agents is usually limited to very simple
exchanges of request and reply messages.</p>

<blockquote>
<p><b>Service Request (SrvRqst)</b><br/>
Message sent by UA's to SA's and DA's to request the location of a service.</p>

<p><b>Service Reply (SrvRply)</b><br/>
Message sent by SA's and DA's in response to a SrvRqst message. The SrvRply
contains the URL of the requested service.</p>

<p><b>Service Registration (SrvReg)</b><br/>
Message sent by SA's to DA's containing information about a service that
is available.</p>

<p><b>Service Deregister (SrvDeReg)</b><br/>
Message sent by SA's to inform DA's that a service is no longer available.</p>

<p><b>Service Acknowledge (SrvAck)</b><br/>
A generic acknowledgment that is sent by DA's to SA's in response to SrvReg
and SrvDeReg messages.</p>

<p><b>Attribute Request (AttrRqst)</b><br/>
Message sent by UA's to request the attributes of a service.</p>

<p><b>Attribute Reply (AttrRply)</b><br/>
Message sent by SA's and DA's in response to a AttrRqst. The AttrRply
contains the list of attributes that were requested.</p>

<p><b>Service Type Request (SrvTypeRqst)</b><br/>
Message sent by UA's to SA's and DA's requesting the types of services
that are available.</p>

<p><b>Service Type Reply (SrvTypeRply)</b><br/>
Message by SA's and DA's in response to a SrvTypeRqst. The SrvTypeRply
contains a list of requested service types.</p>

<p><b>DA Advertisement (DAAdvert)</b><br/>
Message sent by DA's to let SA's and UA's know where they are.</p>

<p><b>SA Advertisement (SAAdvert)</b><br/>
Message sent by SA's to let UA's know where they are.</p>
</blockquote>

<h3>Unicast, Multicast and Broadcast</h3>

<p>SLP is a unicast and multicast protocol. This means that the messages
described in the previous section can be sent to one agent at a time (unicast) 
or to all (listening) agents at the same time (multicast). A multicast 
is not a broadcast. In theory, broadcast messages are "heard" by <i>every</i> node
on the network. Multicast differs from broadcast because multicast messages are only 
"heard" by the nodes on the network that have "joined the multicast group" - by
definition, those that are interested in the information.</p>

<p>For obvious reasons, network routers filter almost all broadcast
traffic. This means that broadcasts that are generated on one subnet will not be
forwarded, or "routed" to any of the other subnets connected to the router
(from the router's perspective, a subnet is all machines connected to one
of its ports). Multicast messages, on the other hand, <em>are</em> forwarded by
routers. Multicast traffic from a given group is forwarded by routers to all subnets
that have at least one machine that is interested in receiving the multicast
for that group.</p>

<h3>Agent Dialog Examples</h3>

<p>Agent Initialization<br />
<em>(to be completed)</em></p>

<p>Service Registration<br />
<em>(to be completed)</em></p>

<p>Service Request/Reply<br />
<em>(to be completed)</em></p>

<h3>SLP Application Programmer's Interface</h3>

<p>One of the most important parts of the SLP specification is the
standard <em>Application Programmer's Interface</em> (API). The SLP API is a 
library interface that allows programmers to use SLP in their applications to locate
services. Without the API, SLP would be little more than a specification. With
the API, developers can add easily add SLP based features to their
programs. The SLP API provides applications with the same sort of
interface to service information that the LDAP client API provides to
LDAP enabled applications.</p>

<p>The following is a list of the major SLP API function calls (more information
can be found in the <a href="../ProgrammersGuide/index.html">OpenSLP Programmer's
Guide</a> or <a href="../../rfc/rfc2614.txt">RFC 2614</a>):</p>

<blockquote>
<p><b>SLPReg()</b><br/>
Registers a service URL and service attributes with SLP.</p>

<p><b>SLPDeReg()</b><br/>
Deregisters a previously registered service.</p>

<p><b>SLPFindSrvs()</b><br/>
Finds services based on service type or attributes.</p>

<p><b>SLPFindAttrs()</b><br/>
Obtains a list of attributes for services registered with SLP.</p>

<p><b>SLPFindSrvTypes()</b><br/>
Obtains a list of the types of services that have been registered with SLP.</p>
</blockquote>

<h3>Additional Information</h3>

<p>Technical readers probably have additional questions that are beyond the
scope of this document.</p>

<p><b>Security</b><br/>
SLPv2 has been designed to be a secure protocol. When properly implemented, 
SLPv2 can ensure integrity and authenticity of data being transmitted
between SLP agents. See <a href="../../rfc/rfc2608.txt">RFC 2608</a>, section 9.2 
for more information.</p>

<p><b>Scalability</b><br/>
SLPv2 was designed to be a scalable solution for enterprise service location. 
It is not intended to be a solution for the global Internet. However, as an enterprise 
solution, SLP can be configured to use "scopes" (see <a href="../../rfc/rfc2608.txt">RFC 2608</a> 
section 11) and SLP Directory Agents in ways that should allow it to scale well in very 
large networks. More concrete evidence of SLPv2 scalability will become available when SLP is
more widely used.</p>

<p><b>Implementations</b><br/>
The following is a list of known SLP implementations:</p>

<blockquote>
<p><a href="http://www.openslp.org">OpenSLP</a><br/>
An OpenSource project that aims to provide a full SLPv2 implementation. Today, most Linux distributions either pre-install OpenSLP, or make it available to the user via the distribution's package management software.</p>

<p><a href="http://research.sun.com/slp">Sun Microsystems</a><br/>
Offers a "reference implementation" of SLPv2 that is available under
the Sun Community License</p>

<p><a href="http://www.novell.com">Novell NetWare</a><br/>
SLPv2 is implemented by Novell NetWare servers in NetWare versions 5
through 7.</p>

<p><a href="http://www.axis.com">Axis Communications</a><br/>
Uses SLP in its thin server products</p>

<p><a href="http://www.hp.com">Hewlett-Packard</a><br/>
Uses SLP in its high-end printers</p>

<p><a href="http://www.xerox.com">Xerox</a><br/>
Uses SLP in its printers</p>
</blockquote>


                <!-- #EndEditable -->
                </div>
            </div>

            <div id="footer">
                Copyright &copy; 2011 <a href="http://www.openslp.org/">openslp.org</a>. All Rights Reserved.<br/>
                Design by <a href="http://www.mdibb.net" title="Website of Matt Dibb">Matt Dibb</a>
                2006. <a href="http://jigsaw.w3.org/css-validator/check/referer" title="Validate CSS">CSS</a> 
                <a href="http://validator.w3.org/check/referer" title="Validate XHTML">XHTML</a>
                <br/>Courtesy of <a href="http://www.openwebdesign.org">Open Web Design</a>
                &amp; <a href="http://seo-services.us">seo</a>
            </div>
        </div>
    </body>
<!-- #EndTemplate -->
</html>