diff options
Diffstat (limited to 'debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html')
47 files changed, 5204 insertions, 0 deletions
diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/AgentInit.jpg b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/AgentInit.jpg Binary files differnew file mode 100644 index 00000000..f2aba293 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/AgentInit.jpg diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/ServiceReg.jpg b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/ServiceReg.jpg Binary files differnew file mode 100644 index 00000000..f2aba293 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/ServiceReg.jpg diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/ServiceRqst.jpg b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/ServiceRqst.jpg Binary files differnew file mode 100644 index 00000000..f2aba293 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/ServiceRqst.jpg diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/index.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/index.html new file mode 100644 index 00000000..beb0d45a --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/IntroductionToSLP/index.html @@ -0,0 +1,345 @@ +<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" + content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" + content="Mozilla/4.76C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>An Introduction to SLP</title> +</head> +<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" + vlink="#551a8b"> +<h1> +An Introduction to the Service Location Protocol (SLP)<br> +</h1> +<h2> +<b>Whitepaper <br> +</b></h2> +<b>Original Draft: <a href="http://www.calderasystems.com">Caldera +Systems, Inc</a></b><b><br> +Final Revision: <a href="http://www.novell.com">Novell, Inc</a></b> +<hr width="100%"> +<h3>What Is Service Location Protocol?</h3> +<p>The <span style="font-style: italic;">Service Location Protocol</span> +(SLP) was originally an <span style="font-style: italic;">Internet +Engineering Task Force</span> (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.<br> +</p> +<h3>About this Document</h3> +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: +<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> +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>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 (<span style="font-style: italic;">Newbie</span>), and his +coworker (<span style="font-style: italic;">Stan</span>), who's been +around for a while: <br> +</p> +<blockquote><b><u>Traditional</u></b> <br> + <span style="font-style: italic;">Newbie</span>: "Hey Stan, the setup +program is asking me for the name +of our printer. What should I type in?"<br> + <span style="font-style: italic;">Stan</span>: "Which printer do you +want?"<br> + <span style="font-weight: bold;"></span><span + style="font-style: italic;">Newbie</span>: "The big one by the copier."<br> + <span style="font-weight: bold;"></span><span + style="font-style: italic;">Stan</span>: "I've heard it doesn't work +well with postscript +applications. You'll have to use the one down the hall."<br> + <span style="font-weight: bold;"></span><span + style="font-style: italic;">Newbie</span>: "Ok. What should I type in."<br> + <span style="font-weight: bold;"></span><span + style="font-style: italic;">Stan</span>: "Actually, I don't know; I +use the one by the copier. You'll +probably have to call the IS help desk."<br> + <span style="font-weight: bold;"></span><span + style="font-style: italic;">Newbie</span>: <groan> ... + <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.<span + style="font-weight: bold;"></span></p> +</blockquote> +<h3>SLP for Software Developers</h3> +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>Consider the following example of a software engineer who is writing +an LDAP-enabled application. +<br> +</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.<br> + </p> +</blockquote> +<p>As illustrated in the example above, SLP does not always eliminate +the +need to prompt users for information. However, it does allow the +software developer to present a descriptive list of services that can +be +understood by the user.</p> +<blockquote></blockquote> +<h3> +Agents</h3> +In order to understand the rest of this document (as well as all other +SLP documentation), you will need to know about SLP <span + style="font-style: italic;">agents</span>. In +SLP +an agent is a software entity that processes SLP protocol +messages. +There are three types of SLP agents: + <br> +<blockquote><b>User Agent (UA)</b> <br> +The SLP <span style="font-style: italic;">User Agent</span> 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><b>Service Agent (SA)</b> <br> +The SLP <span style="font-style: italic;">Service Agent</span> 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 <span style="font-style: italic;">Directory Agent</span> 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.<br> + </p> +</blockquote> +<h3> +Messages</h3> +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. +<blockquote><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><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> +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 agents (that are listening) 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.<br> +<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, <span + style="font-style: italic;">are</span> 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. <br> +</p> +<h3>Agent Dialog Examples</h3> +Agent Initialization +<br> +<img src="AgentInit.jpg" height="40" width="237"> +<p>Service Registration +<br> +<img src="ServiceReg.jpg" height="40" width="237"></p> +<p>Service Request/Reply +<br> +<img src="ServiceRqst.jpg" height="40" width="237"> <br> +</p> +<h3>SLP Application Programmer's Interface</h3> +One of the most important parts of the SLP specification is the +standard +<span style="font-style: italic;">Application Programmer's Interface</span> +(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. <br> +<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>): <br> +</p> +<blockquote> <b>SLPReg()</b> <br> +Registers a service URL and service attributes with SLP. + <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> +Technical readers probably have additional questions that are beyond +the +scope of this document. +<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 larger 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><a href="http://www.openslp.org">OpenSLP</a> <br> +An OpenSource project that aims to provide a full SLPv2 implementation + <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.<br> + </p> + <p><a href="http://www.axis.com">Axis Communications</a> <br> +Uses SLP in its thin server products </p> +</blockquote> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Callbacks.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Callbacks.html new file mode 100644 index 00000000..ba3e0a66 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Callbacks.html @@ -0,0 +1,114 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - Callbacks</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +Callbacks</h2> + +<hr WIDTH="100%"> +<h3> +What's a callback function?</h3> +If you are new to asynchronous programming, or have never used callback +functions before, just think of the SLP callback functions as a pieces +of code the you must write but never call directly. Yep, that's right, +you will probably never call your callback function directly, instead, +it will be called by the library when it is ready to report the status +or results of an operation. This allows your program to do other +things while data is being collected by the callback function. Callback +functions are required for all of the major SLP APIs for more information +see <a href="SLPReg.html">SLPReg()</a>, +<a href="SLPDereg.html">SLPDeReg()</a>, +<a href="SLPDelAttrs.html">SLPDelAttrs()</a>, +<a href="SLPFindSrvs.html">SLPFindSrvs()</a>, +<a href="SLPFindAttrs.html">SLPFindAttrs()</a>, +and <a href="SLPFindSrvTypes.html">SLPFindSrvTypes()</a>, +<p>Callback functions must accept the parameters that the caller (the SLP +library) expects to pass to them. This is why callback function types +are defined. See <a href="SLPRegReport.html">SLPRegReport()</a>, +<a href="SLPSrvURLCallback.html">SLPSrvURLCallback()</a>, +<a href="SLPAttrCallback.html">SLPAttrCallback()</a>. +<h3> +What's different about SLP callback functions?</h3> +Callbacks are an integral part of the SLP API. Developers usually +associate callbacks with asynchronous APIs, but the SLP API uses callbacks +for both synchronous and asynchronous operations. Whether the callback +is called synchronously or asynchronously, depends on the <tt><a href="SLPOpen.html#isasync">isasync</a> +</tt>parameter in the call to <tt><a href="SLPOpen.html">SLPOpen()</a></tt>. +Remember the following rules and you should not have any problems with +your callback functions. +<ul> +<li> +Callback functions are called in both synchronous and asynchronous cases. +The only difference is that in a synchronous case, the initiating function +(SLPReg(), SLPFindSrvs(), etc) will block until all results are reported +to the callback function.</li> + +<li> +The memory passed in to callback functions is owned by the library. +i.e. the callback must <tt>strdup()</tt> strings before using them permanently +because the memory passed in will be <tt>free()</tt>d by the library when +the callback returns.</li> + +<li> +<blink>Make your callback functions as efficient as possible.</blink> +This is especially important when a call is made with an async <tt><a href="SLPTypes.html#SLPHandle">SLPHandle</a></tt> +because results are not collected or collated by the library before the +callback function is called. In other words, in async mode, +the library will call the callback each time a reply message is received +until the request times out.</li> + +<li> +If the <tt>errcode</tt> upon entry to the callback is set to anything but +<tt>SLP_OK</tt>, +the rest of the parameters may be invalid. Check the error code first.</li> + +<li> +Use the <tt>cookie</tt> parameter. It is the best way to get information +to and from your callback.</li> +</ul> + +<h3> +How does OpenSLP library handle asynchronous operation?</h3> +When an SLP library call is made with an SLPHandle that was opened in async +mode, the library does everything it can with out blocking. It then +creates a thread (hopefully a user level thread) and returns SLP_OK. +The newly created thread processes the request (possibly blocking to wait +for data to arrive from the network) and calls the callback function as +data is received. +<p>An important thing to remember is that <i>no collection or collation +of results is performed by the library when a call is initiated in async +mode. </i>This means that the callback may be called multiple times with +the same result. This would happen for example if two SAs or DAs +maintained the same registration. +<p>Currently all the code is in libslp to allow for asynchronous operation +except for the calls to pthread_create(). The reason for this is +mainly that no one has really needed asynchronous operation. If you +feel like you have a good reason to use asynchronous operation then please +send email to openslp-devel@lists.sourceforge.net. +<h3> +How does OpenSLP library handle synchronous operation?</h3> +When an SLP library call is made with an SLPHandle that was opened in sync +mode, the library will not create a thread. Instead, the calling +thread will perform all processing (which may block) and report results +to the callback function. When in sync mode, all of the results are +collated to ensure no duplicates are returned. The API function call +will not return until all results are finished being reported through the +callback. +<h3> +Why not just have separate synchronous and asynchronous APIs?</h3> +That would have been good choice, but for some reason, the SLP designers +thought their way would be better. OpenSLP API is just an implementation +of a standardized specification described in RFC 2614 +<h3> +Can I see some example code?</h3> +Yes, example code can be found in the documentation for the <a href="SLPReg.html">SLPReg()</a>, +<a href="SLPFindSrvs.html">SLPFindSrv()</a>, +<a href="SLPFindAttrs.html">SLPFindAttrs()</a> and <a href="SLPFindSrvTypes.html">SLPFindSrvTypes()</a> +functions. +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Divergence.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Divergence.html new file mode 100644 index 00000000..4cfa98d9 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Divergence.html @@ -0,0 +1,180 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - Divergence from RFC 2614</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +Divergence from RFC 2614</h2> + +<hr WIDTH="100%"> +<h3> +SLP Service URLs are required</h3> +SLP Service URL syntax is required for all functions that accept url strings. +The following is a list of affected functions: +<ul> +<li> +<tt>SLPReg()</tt></li> + +<li> +<tt>SLPDeReg()</tt></li> + +<li> +<tt>SLPDelAttrs()</tt></li> + +<li> +<tt>SLPFindAttrs()</tt></li> + +<li> +<tt>SLPParseSrvURL()</tt></li> + +<li> +<tt>SLPSrvURLCallback()</tt></li> +</ul> +The decision to require SLP Service URL syntax was made based on in part +the following scenario: +<blockquote>Suppose that two calls were made to SLPReg() with <tt>srvurl</tt>s +and <tt>srvtype</tt>s of "192.168.100.2","http" and "192.168.100.2","ftp". +Now the developer wants to deregister one service with out deregistering +the other. How can it be done? The SLPDeReg() call does not +have a service type parameter so it would be impossible for the underlying +implementation to distinguish between the two registrations. In attempt +to standardize, OpenSLP expects valid Service URLS.</blockquote> +OpenSLP requires strict Service URL syntax because a Service URL can be +treated as a unique "database key" that identifies a registered service. +Not requiring Service URL syntax allows for several ambiguities like the +one mentioned above. +<br> +<h3> +Scopelist may be the empty string ("")</h3> +In the calls where a scope list is accepted as a parameters, RFC 2614 says +that this parameter may not be the empty string or NULL. +OpenSLP allows scope list to be NULL or the empty string. If the +empty string is passed in as a scopelist, then OpenSLP will use the scopelist +the system administrator has configured for the machine. This saves +99% of all developers the time of calling SLPFindScopes() and parsing the +result. +<p>Scoping is almost entirely an administrative task that is only required +for scalebility of the SLP wire protocol. Having to deal with and +understand scopes will be a burdon to the large majority of programmers. +Unless they are writing some sort of SLP browser, they will be very content +to use the scope that the machine is configured to use. +<br> +<h3> +The SLPSetProperty() is ignored</h3> +The SLPSetProperty() and SLPGetProperty() calls are impossible implement +in a way that would be both scalable and thread safe. The SLPGetProperty() +call could never be made thread safe unless return value was a pointer +to a buffer dynamically allocated the library and freed by the caller. +The SLPSetProperty() call would still access with the data store in such +a way that mutexes would be required to ensure that SLPSetProperty() and +SLPGetProperty() were never used the same buffers at the same time. +Even if a thread safe data store were devised, the SLPGetProperty() call +would be used so frequently during internal operations of the library that +performance might be adversely affected due to mutex bottlenecking or the +amount of processing required to resolve the attribute name to a value. +<br> +<h3> +NULL and empty string are acceptable parameters</h3> +According to RFC 2614, NULL is not exceptable value for any parameter. +Instead programmers are instructed to passed the empty string "". +OpenSLP allows programmers to use either NULL or the empty string. +It is very easy to deal with both NULL or empty string in the implementation, +and allows developers to write more familiar and slightly more efficient +code. There should not be any reason why the compiler should be required +to pass a pointer to a static constant empty string when NULL will do just +a well. This is why the vast majority of C APIs use NULL to +indicate an ignored parameter or default value -- not the empty string +(""). +<br> +<h3> +Incremental registrations an de-registrations</h3> +The only reason I can think of ever wanting to expose the functionality +of incremental registration and deregistration is to represent dynamic +data via SLP attributes. I can think of a long list of reasons why +this is a very very bad idea. With out doubt, it is best to instruct +SLP developers to minimize when ever possible, the number of calls that +ultimately generate SrvReg and SrvDereg messages. If dynamic data +is to be represented, it is best do do it via a specialized protocol optimized +for the given service. OpenSLP does not support incremental registrations +and de-registrations via SLPReg() and SLPDelAttrs() because we have found +that when developers really learn what happens "under the SLP covers" they +are very careful *not* to call then very often. +<p>In addition to poor usage of network resources, incremental registrations +and de-registrations require additional code that decreases the efficiency +of and increases the size, and complexity of API and agent implementations. +<p>The work around for this behavior involves the following: +<ul> +<li> +Design application usage of SLP such that SLP is not used to store great +quantities of data</li> + +<li> +Design application usage of SLP such that SLP is not used to store dynamic +data</li> + +<li> +If the need does arise to add or remove an attribute from an existing registration +simply re-register the service with new attributes as "fresh" registration.</li> +</ul> + +<h3> +Addition of a very simple attribute parsing function</h3> +The following function is secretly included with OpenSLP and has proven +to be very useful. +<p><tt>/*=========================================================================*/</tt> +<br><tt>SLPError SLPParseAttrs(const char* pcAttrList,</tt> +<br><tt> +const char *pcAttrId,</tt> +<br><tt> +char** ppcAttrVal);</tt> +<br><tt>/* +*/</tt> +<br><tt>/* Used to get individual attribute values from an attribute string +that */</tt> +<br><tt>/* is passed to the SLPAttrCallback +*/</tt> +<br><tt>/* +*/</tt> +<br><tt>/* pcAttrList (IN) A character buffer containing a comma separated, +null */</tt> +<br><tt>/* +terminated list of attribute id/value assignments, in */</tt> +<br><tt>/* +SLP wire format; i.e. "(attr-id=attr-value-list)" +*/</tt> +<br><tt>/* +*/</tt> +<br><tt>/* pcAttrId (IN) The string indicating which attribute +value to return. */</tt> +<br><tt>/* +MUST not be null. MUST not be the empty string (""). +*/</tt> +<br><tt>/* +*/</tt> +<br><tt>/* ppcAttrVal (OUT) A pointer to a pointer to the buffer to receive +*/</tt> +<br><tt>/* +attribute value. The memory should be freed by a call */</tt> +<br><tt>/* +to SLPFree() when no longer needed. +*/</tt> +<br><tt>/* +*/</tt> +<br><tt>/* Returns: Returns SLP_PARSE_ERROR if an attribute of the specified +id */</tt> +<br><tt>/* was not +found otherwise SLP_OK +*/</tt> +<br><tt>/*=========================================================================*/</tt> +<br> +<h3> +Some .conf properties are ignored</h3> +See the <a href="../UsersGuide/SlpConf.html">OpenSLP Users Guide</a> for +more details +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Examples.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Examples.html new file mode 100644 index 00000000..81baa46c --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Examples.html @@ -0,0 +1,18 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - Examples</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +OpenSLP Example Code</h2> + +<h2> + +<hr WIDTH="100%"></h2> +< put example code here > +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPAttrCallback.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPAttrCallback.html new file mode 100644 index 00000000..026b0a45 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPAttrCallback.html @@ -0,0 +1,106 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPAttrCallback</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPAttrCallback</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>typedef <a href="SLPTypes.html#SLPBoolean">SLPBoolean</a> SLPAttrCallback( +<a href="SLPTypes.html#SLPHandle">SLPHandle</a> +<a href="#hslp">hslp</a>,</tt> +<br><tt> +const char* attrlist,</tt> +<br><tt> + + <a href="SLPTypes.html#SLPError">SLPError</a> <a href="#errcode">errcode</a>,</tt> +<br><tt> +void* <a href="#cookie">cookie</a> )</tt> +<h3> +Description</h3> +The <tt>SLPAttrCallback</tt> type is the type of the callback function +passed as a parameter to the <tt><a href="SLPFindAttrs.html">SLPFindAttrs()</a></tt> +function. The behavior of the library is differs depending on whether +the attribute request was by Service URL or by service type. +<p>If the <tt><a href="SLPFindAttrs.html">SLPFindAttrs()</a></tt> function +was called with a Service URL, then the callback is called once regardless +of whether the handle was opened asynchronously or synchronously. +The <tt>attrlist</tt> parameter will contain a comma separated list of +attributes. +<p>If the <tt><a href="SLPFindAttrs.html">SLPFindAttrs()</a></tt> function +was called with a service type, then the callback called is until no more +results are available. The <tt>attrlist</tt> parameter will contain +a comma separated list of attributes. Returns will be collated to remove +duplicates if <tt><a href="SLPFindAttrs.html">SLPFindAttrs()</a></tt> was +called synchronously. If it was called asynchronously the <tt>attrlist</tt> +may return duplicates. +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="hslp"></a><tt>hslp</tt></td> + +<td NOSAVE>The language specific <tt>SLPHandle</tt> that was passed into +the <tt>SLPFindAttrs()</tt> function.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="attrlist"></a><tt>attrlist</tt></td> + +<td NOSAVE>Pointer to a buffer containing a comma separated null terminated +list of attribute id/value assignments in SLP wire format "(attr-id=attr-value-list)". </td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="errcode"></a><tt>errcode</tt></td> + +<td NOSAVE>An error code indicating if an error occurred during the operation. +The callback should check this error code before processing the parameters. </td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="cookie"></a><tt>cookie</tt></td> + +<td NOSAVE>The same cookie that was passed as a parameter to the <tt>SLPFindAttrs()</tt> +call</td> +</tr> + +<caption ALIGN=BOTTOM> </caption> +</table> + +<h3> +Returns</h3> +The callback should return <tt>SLP_TRUE</tt> if more data is desired. +The callback may continue to return <tt>SLP_TRUE</tt> until it is called +with an <tt>errcode</tt> of <tt><a href="SLPError.html#SLP_LAST_CALL">SLP_LAST_CALL</a></tt>. +If no more data is requested the callback should return <tt>SLP_FALSE</tt>.. +Since discovery of attributes by service-type is not supported, there is +really no reason to return anything but <tt>SLP_FALSE</tt> from the +SLPAttrCallback(). +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 1.0.0</td> + +<td NOSAVE><tt>SLPAttrCallback</tt> function is implemented as specified +by RFC 2614</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="/Syntax.html">Syntax</a>, +<a href="/Callbacks.html">Callbacks</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPClose.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPClose.html new file mode 100644 index 00000000..95cfd24e --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPClose.html @@ -0,0 +1,66 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPClose</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPClose</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt>void SLPClose(<a href="SLPTypes.html#SLPHandle">SLPHandle</a> <a href="#hslp">hslp</a>)</tt> +<br> +<h3> +Description</h3> +Frees all resources associated with the handle. If the handle was +invalid, the functions returns silently. Any outstanding synchronous +or asynchronous operations are canceled so their callback functions will +not be called any longer. +<p>In the OpenSLP implementation, SLPHandles are used to cache information +that is costly to obtain (in terms of network usage and time). +Since the RFC 2614 API does not provide function calls to for library initialization, +OpenSLP keeps track of the number of SLPHandles that are open. +Several global library data structures are initialized when the first SLPHandle +is opened and maintained until the last SLPHandle is closed. Therefore, +it is most efficient to leave SLPHandles open for as long as you will need +them (often for the entire life of a process). If you +can help it, DO NOT make a habit of opening and closing SLPHandles frequently. +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="hslp"></a>hslp</td> + +<td NOSAVE>An open <tt>SLPHandle</tt> that was returned by <tt><a href="SLPOpen.html">SLPOpen()</a></tt></td> +</tr> +</table> + +<h3> +Returns</h3> +None +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.0</td> + +<td NOSAVE>Fully implemented as specified by RFC 2614</td> +</tr> +</table> + +<h3> +See Also</h3> +<tt><a href="SLPOpen.html">SLPOpen()</a></tt> +<br> +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPDelAttrs.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPDelAttrs.html new file mode 100644 index 00000000..77ea46b7 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPDelAttrs.html @@ -0,0 +1,102 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPDelAttrs()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +SLPDelAttrs</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt><a href="SLPError.html">SLPError</a> SLPDelAttrs( SLPHandle <a href="#hslp">hslp</a>,</tt> +<br><tt> +const char* <a href="#srvurl">srvurl</a>,</tt> +<br><tt> +const char* attrs,</tt> +<br><tt> +<a href="SLPRegReport.html">SLPRegReport</a> <a href="#callback">callback</a>,</tt> +<br><tt> +void* <a href="#cookie">cookie</a> )</tt> +<h3> +Description</h3> +Deletes specified attributes from a registered service. OpenSLP +will not implement this function in the 1.0 development cycle because of +a lack of interest and the existance of an obvious work-around replacement. +Instead of calling <tt>SLPDelAttrs() </tt>developers writing to OpenSLP +should use simply <tt><a href="SLPDereg.html">SLPDeReg()</a></tt> to de-register +the entire service then call <tt><a href="SLPReg.html">SLPReg()</a></tt> +to re-register the service with out the undesired attributes. +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="hslp"></a><tt>hslp</tt></td> + +<td NOSAVE>The language specific <tt>SLPHandle</tt> to use for deleting +attributes.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="srvurl"></a><tt>srvurl</tt></td> + +<td>The SLP Service URL of the registered service to delete attributes +from. May not be the empty string. May not be NULL. Must +conform to SLP Service URL syntax or <tt><a href="SLPError.html#INVALID_REGISTRATION">SLP_INVALID_REGISTRATION</a></tt> +will be returned. See <a href="/Syntax.html">Syntax</a> for more +information on SLP Service URL syntax.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="attrs"></a><tt>attrs</tt></td> + +<td>A comma separated list of attribute ids to be deleted from the registration. +May not be the empty string. May not be NULL.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="callback"></a><tt>callback</tt></td> + +<td NOSAVE>The address of an <tt><a href="/SLPRegReport.html">SLPRegReport</a></tt> +function that will be called to report the operation completion status. +May not be NULL. See <a href="/Callbacks.html">Callbacks</a> for more information +on how callbacks are used by the SLPAPI.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="cookie"></a><tt>cookie</tt></td> + +<td NOSAVE>Pointer to memory that gets passed to the callback code. +May be NULL.</td> +</tr> +</table> + +<h3> +Returns</h3> +Always returns <tt><a href="SLPError.html#SLP_NOT_IMPLEMENTED">SLP_NOT_IMPLEMENTED</a></tt> +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 1.0 </td> + +<td NOSAVE>Will not be implemented in the OpenSLP 1.0 development cycle. +Always returns <tt><a href="SLPError.html#SLP_NOT_IMPLEMENTED">SLP_NOT_IMPLEMENTED</a></tt></td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="/SLPReg.html">SLPReg()</a>, <a href="SLPDereg.html">SLPDeReg()</a>, +<a href="/Syntax.html">Syntax</a>, +<a href="/Callback.html">Callbacks</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPDereg.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPDereg.html new file mode 100644 index 00000000..96084f4a --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPDereg.html @@ -0,0 +1,183 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPDereg()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPDereg</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt><a href="/SLPError.html">SLPError</a> SLPDereg( <a href="SLPTypes.html#SLPHandle">SLPHandle</a><a href="#hslp">hslp</a>,</tt> +<br><tt> +const char* <a href="#srvurl">srvurl</a>,</tt> +<br><tt> +<a href="SLPRegReport.html">SLPRegReport</a> <a href="#callback">callback</a>,</tt> +<br><tt> +void* <a href="#cookie">cookie</a> )</tt> +<h3> +Description</h3> +Deregisters the advertisement for URL <tt>srvurl</tt> in all scopes where +the service is registered and all language locales. The deregistration +is not just confined to the locale of the <tt>SLPHandle</tt>,. The +API library is required to perform the operation in all scopes obtained +through configuration. +<br> +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="hslp"></a><tt>hslp</tt></td> + +<td NOSAVE>The language specific <tt>SLPHandle</tt> on which to de-register +the service.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="srvurl"></a><tt>srvurl</tt></td> + +<td>The SLP Service URL to de-register. May not be the empty string. +May not be NULL. Must conform to SLP Service URL syntax.. See +<a href="Syntax.html">Syntax</a> +for more information on SLP Service URL syntax.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="callback"></a><tt>callback</tt></td> + +<td NOSAVE>The address of an <tt><a href="SLPRegReport.html">SLPRegReport</a></tt> +function that will be called to report the operation completion status. +May not be NULL. See <a href="Callbacks.html">Callbacks</a> for more information +on how callbacks are used by the SLPAPI.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="cookie"></a><tt>cookie</tt></td> + +<td NOSAVE>Pointer to memory that gets passed to the callback code. +May be NULL.</td> +</tr> +</table> + +<h3> +Returns</h3> + +<table BORDER NOSAVE > +<tr NOSAVE> +<td NOSAVE>SLP_OK</td> + +<td>Indicates that the no error occurred during the operation.</td> +</tr> + +<tr> +<td>SLP_INVALID_REGISTRATION</td> + +<td>The deregistered service url does not conform to valid service url +syntax. The service url being deregistered is not registered this +means that either it was never registered via a call to SLPReg() or that +the registration lifetime has expired. SLP_INVALID_REGISTRATION +is commonly returned when an attempt is made to deregister a service that +was registered by a call to SLPReg() on a different host.</td> +</tr> + +<tr> +<td>SLP_PARSE_ERROR</td> + +<td>The SLP message was rejected by a remote SLP agent. The API returns +this error only when no information was retrieved, and at least one SA +or DA indicated a protocol error. The data supplied through the API may +be malformed or a may have been damaged in transit.</td> +</tr> + +<tr> +<td>SLP_AUTHENTICATION_ABSENT</td> + +<td>If the SLP framework supports authentication, this error arises when +the UA or SA failed to send an authenticator for requests or registrations.</td> +</tr> + +<tr> +<td>SLP_AUTHENTICATION_FAILED</td> + +<td>If the SLP framework supports authentication, this error arises when +a authentication on an SLP message failed.</td> +</tr> + +<tr> +<td>SLP_NETWORK_TIMED_OUT</td> + +<td>When no reply can be obtained in the time specified by the configured +timeout interval for a unicast request, this error is returned. In +other words, slpd is running, but something is wrong with it</td> +</tr> + +<tr> +<td>SLP_NETWORK_INIT_FAILED</td> + +<td>If the network cannot initialize properly, this error is returned. +Will also be returned if an SA or DA agent (slpd) can not be contacted. +slpd must be running in order to call SLPReg() or SLPDereg().</td> +</tr> + +<tr> +<td>SLP_MEMORY_ALLOC_FAILED </td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td>SLP_PARAMETER_BAD</td> + +<td>If a parameter passed into a function is bad, this error is returned.</td> +</tr> + +<tr> +<td>SLP_NETWORK_ERROR</td> + +<td>The failure of networking during normal operations causes this error +to be returned. In OpenSLP, this is the error you'll get if an underlying +socket() call failed.</td> +</tr> + +<tr> +<td>SLP_INTERNAL_SYSTEM_ERROR</td> + +<td>A basic failure of the API causes this error to be returned. This occurs +when a system call or library fails. The operation could not recover.</td> +</tr> + +<tr> +<td>SLP_HANDLE_IN_USE</td> + +<td>Callback functions are not permitted to recursively call into the API +on the same SLPHandle, either directly or indirectly. If an attempt is +made to do so, this error is returned from the called API function.</td> +</tr> +</table> + +<p>Be aware, especially if the call is async, of error codes that may be +passed to the SLPRegReport() callback function. +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.0</td> + +<td NOSAVE>Fully implemented as specified by RFC 2614 </td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="SLPReg.html">SLPReg()</a>, <a href="Syntax.html">Syntax</a>, <a href="Callbacks.html">Callbacks</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPError.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPError.html new file mode 100644 index 00000000..736c7205 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPError.html @@ -0,0 +1,223 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPError Codes</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPError Codes</h2> + +<hr WIDTH="100%"> +<p>The following is an explanation of the SLP error codes are returned +by SLP functions: +<br> +<table BORDER WIDTH="100%" NOSAVE > +<tr NOSAVE> +<td NOSAVE><a NAME="SLP_LAST_CALL"></a>SLP_LAST_CALL</td> + +<td>1</td> + +<td>Passed to callback functions when the API library has no more data +for them and therefore no further calls will +<br>be made to the callback on the currently outstanding operation. The +callback can use this to signal the main body of the client code that no +more data will be forthcoming on the operation, so that the main body of +the client code can break out of data collection loops. On the last call +of a callback during both a synchronous and synchronous call, the error +code parameter has value SLP_LAST_CALL, and the other parameters are all +NULL. If no results are returned by an API operation, then only one call +is made, with the error parameter set to SLP_LAST_CALL.</td> +</tr> + +<tr> +<td><a NAME="SLP_OK"></a>SLP_OK</td> + +<td>0</td> + +<td>indicates that the no error occurred during the operation.</td> +</tr> + +<tr> +<td><a NAME="LANGUAGE_NOT_SUPPORTED"></a>SLP_LANGUAGE_NOT_SUPPORTED</td> + +<td>-1</td> + +<td>No DA or SA has service advertisement or attribute information in the +language requested, but at least one DA or SA indicated, via the LANGUAGE_NOT_SUPPORTED +error code, that it might have information for that service in another +language</td> +</tr> + +<tr> +<td><a NAME="PARSE_ERROR"></a>SLP_PARSE_ERROR</td> + +<td>-2</td> + +<td>The SLP message was rejected by a remote SLP agent. The API returns +this error only when no information was retrieved, and at least one SA +or DA indicated a protocol error. The data supplied through the API may +be malformed or a may have been damaged in transit.</td> +</tr> + +<tr> +<td><a NAME="INVALID_REGISTRATION"></a>SLP_INVALID_REGISTRATION</td> + +<td>-3</td> + +<td>The API may return this error if an attempt to register a service was +rejected by all DAs because of a malformed URL or attributes. SLP does +not return the error if at least one DA accepted the registration. +The deregistered service url does not conform to valid service url syntax. +The service url being deregistered is not registered this means that either +it was never registered via a call to SLPReg() or that the registration +lifetime has expired. SLP_INVALID_REGISTRATION is commonly +returned when an attempt is made to deregister a service that was registered +by a call to SLPReg() on a different host.</td> +</tr> + +<tr> +<td><a NAME="SCOPE_NOT_SUPPORTED"></a>SLP_SCOPE_NOT_SUPPORTED</td> + +<td>-4</td> + +<td>The API returns this error if the SA has been configured with net.slp.useScopes +value-list of scopes and the SA request did not specify one or more of +these allowable scopes, and no others. It may be returned by a DA or SA +if the scope included in a request is not supported by the DA or SA. </td> +</tr> + +<tr> +<td><a NAME="AUTHENTICATION_ABSENT"></a>SLP_AUTHENTICATION_ABSENT</td> + +<td>-6</td> + +<td>If the SLP framework supports authentication, this error arises when +the UA or SA failed to send an authenticator for requests or registrations +in a protected scope.</td> +</tr> + +<tr> +<td><a NAME="AUTHENTICATION_FAILED"></a>SLP_AUTHENTICATION_FAILED</td> + +<td>-7</td> + +<td>If the SLP framework supports authentication, this error arises when +a authentication on an SLP message failed</td> +</tr> + +<tr> +<td><a NAME="SLP_INVALID_UPDATE"></a>SLP_INVALID_UPDATE</td> + +<td>-13</td> + +<td>An update for a non-existing registration was issued, or the update +includes a service type or scope different than that in the initial registration, +etc.</td> +</tr> + +<tr> +<td><a NAME="SLP_REFRESH_REJECTED"></a>SLP_REFRESH_REJECTED</td> + +<td>-15</td> + +<td>The SA attempted to refresh a registration more frequently than the +minimum refresh interval. The SA should call the appropriate API function +to obtain the minimum refresh interval to use.</td> +</tr> + +<tr> +<td><a NAME="SLP_NOT_IMPLEMENTED"></a>SLP_NOT_IMPLEMENTED</td> + +<td>-17</td> + +<td>If an unimplemented feature is used, this error is returned.</td> +</tr> + +<tr> +<td><a NAME="SLP_BUFFER_OVERFLOW"></a>SLP_BUFFER_OVERFLOW</td> + +<td>-18</td> + +<td>An outgoing request overflowed the maximum network MTU size. The request +should be reduced in size or broken into pieces and tried again.</td> +</tr> + +<tr> +<td><a NAME="SLP_NETWORK_TIMED_OUT"></a>SLP_NETWORK_TIMED_OUT</td> + +<td>-19</td> + +<td>When no reply can be obtained in the time specified by the configured +timeout interval for a unicast request, this error is returned.</td> +</tr> + +<tr> +<td><a NAME="SLP_NETWORK_INIT_FAILED"></a>SLP_NETWORK_INIT_FAILED</td> + +<td>-20</td> + +<td>If the network cannot initialize properly, this error is returned. +Will also be returned if an SA or DA agent (slpd) can not be contacted. +See SLPReg() and SLPDeReg() for more information.</td> +</tr> + +<tr> +<td><a NAME="SLP_MEMORY_ALLOC_FAILED"></a>SLP_MEMORY_ALLOC_FAILED </td> + +<td>-21</td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td><a NAME="SLP_PARAMETER_BAD"></a>SLP_PARAMETER_BAD</td> + +<td>-22</td> + +<td>If a parameter passed into a function is bad, this error is returned.</td> +</tr> + +<tr> +<td><a NAME="SLP_NETWORK_ERROR"></a>SLP_NETWORK_ERROR</td> + +<td>-23</td> + +<td>The failure of networking during normal operations causes this error +to be returned.</td> +</tr> + +<tr> +<td><a NAME="SLP_INTERNAL_SYSTEM_ERROR"></a>SLP_INTERNAL_SYSTEM_ERROR</td> + +<td>-24</td> + +<td>A basic failure of the API causes this error to be returned. This occurs +when a system call or library fails. The operation could not recover.</td> +</tr> + +<tr> +<td><a NAME="SLP_HANDLE_IN_USE"></a>SLP_HANDLE_IN_USE</td> + +<td>-25</td> + +<td>In the C API, callback functions are not permitted to recursively call +into the API on the same SLPHandle, either directly or indirectly. If an +attempt is made to do so, this error is returned from the called API function.</td> +</tr> + +<tr> +<td><a NAME="SLP_TYPE_ERROR"></a>SLP_TYPE_ERROR </td> + +<td>-26</td> + +<td>If the API supports type checking of registrations against service +type templates, this error can arise if the attributes in a registration +do not match the service type template for the service.</td> +</tr> +</table> + +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPEscape.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPEscape.html new file mode 100644 index 00000000..05f0e711 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPEscape.html @@ -0,0 +1,100 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPEscape()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPEscape</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt><a href="/SLPError.html">SLPError</a> SLPEscape( const char* <a href="#unescaped">unescaped</a>,</tt> +<br><tt> +char** <a href="#escaped">escaped</a>,</tt> +<br><tt> + +<a href="SLPTypes.html#SLPBoolean">SLPBoolean</a> <a href="#ist">istag</a> +)</tt> +<h3> +Description</h3> +Process the input string to escape any SLP reserved characters. If +the <tt>istag</tt> parameter is SLP_TRUE then SLPEscape() will look for +bad tag characters. +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="unescaped"></a><tt>unescaped</tt></td> + +<td NOSAVE>Pointer to the string to be escaped</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="escaped"></a>escaped</td> + +<td NOSAVE>Pointer to a pointer for the dynamically allocated output string. +The memory should be freed by a call to <a href="SLPFree.html">SLPFree()</a> +when no longer needed.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="ist"></a>istag</td> + +<td NOSAVE>When SLP_TRUE the input buffer is checked for bad characters</td> +</tr> +</table> + +<h3> +Returns</h3> + +<table BORDER NOSAVE > +<tr> +<td>SLP_OK</td> + +<td>Indicates that the no error occurred during the operation.</td> +</tr> + +<tr> +<td>SLP_PARSE_ERROR</td> + +<td>The API returns this error only when no information was retrieved, +and at least one SA or DA indicated a protocol error. The data supplied +through the API may be malformed or a may have been damaged in transit.</td> +</tr> + +<tr> +<td>SLP_MEMORY_ALLOC_FAILED </td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td>SLP_PARAMETER_BAD</td> + +<td>If a parameter passed into a function is bad, this error is returned.</td> +</tr> +</table> + +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.7</td> + +<td NOSAVE>Fully implemented as specified by RFC 2614.</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="SLPUnescape.html">SLPUnescape()</a>, <a href="SLPFree.html">SLPFree()</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindAttrs.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindAttrs.html new file mode 100644 index 00000000..3e1d8950 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindAttrs.html @@ -0,0 +1,255 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPFindAttrs</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPFindAttrs</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt><a href="/SLPError.html">SLPError</a> SLPFindAttrs( <a href="SLPTypes.html#SLPHandle">SLPHandle</a> +<a href="#hslp">hslp</a>,</tt> +<br><tt> +const char* srvurl,</tt> +<br><tt> +const char* <a href="#scopelist">scopelist</a>,</tt> +<br><tt> +const char* attrids,</tt> +<br><tt> +<a href="SLPAttrCallback.html">SLPAttrCallback</a> <a href="#callback">callback</a>,</tt> +<br><tt> +void* <a href="#cookie">cookie</a>)</tt> +<h3> +Description</h3> +This function returns service attributes matching the <tt>attrids</tt> +for the indicated Service URL or service type. OpenSLP does +not support location of attributes by service type with <tt>attrids</tt> +containing wildcards (see status below). +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="hslp"></a><tt>hslp</tt></td> + +<td NOSAVE>The language specific <tt>SLPHandle</tt> on which to search +for attributes the service.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="srvurlorsrvtype"></a><tt>srvurl</tt></td> + +<td NOSAVE>The service URL of the service to the attributes of. See +<a href="Syntax.html#Service Type">Syntax</a> +for more information SLP Service URLs.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="attrids"></a><tt>attrids</tt></td> + +<td>A comma separated list of attribute ids to return. Use the empty string +("") for all attributes. Wildcards are not supported.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="scopelist"></a><tt>scopelist</tt></td> + +<td NOSAVE>A pointer to a comma separated list of scope names. <i>May +be the empty string</i> if you wish to use scopes this machine is configured +for.. </td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="callback"></a><tt>callback</tt></td> + +<td NOSAVE>The address of an <a href="SLPAttrCallback.html">SLPAttrCallback</a> +function that will be called to report the results of the operation. +May not be NULL. See <a href="Callbacks.html">Callbacks</a> for more information +on how callbacks are used by the SLPAPI.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="cookie"></a><tt>cookie</tt></td> + +<td NOSAVE>Pointer to memory that gets passed to the callback code. +May be NULL.</td> +</tr> +</table> + +<h3> +Returns</h3> + +<table BORDER NOSAVE > +<tr NOSAVE> +<td NOSAVE>SLP_OK</td> + +<td>Indicates that the no error occurred during the operation.</td> +</tr> + +<tr> +<td>SLP_PARSE_ERROR</td> + +<td>The SLP message was rejected by a remote SLP agent. The API returns +this error only when no information was retrieved, and at least one SA +or DA indicated a protocol error. The data supplied through the API may +be malformed or a may have been damaged in transit.</td> +</tr> + +<tr> +<td>SLP_AUTHENTICATION_ABSENT</td> + +<td>If the SLP framework supports authentication, this error arises when +the UA or SA failed to send an authenticator for requests or registrations.</td> +</tr> + +<tr> +<td>SLP_AUTHENTICATION_FAILED</td> + +<td>If the SLP framework supports authentication, this error arises when +a authentication on an SLP message failed.</td> +</tr> + +<tr> +<td>SLP_NETWORK_TIMED_OUT</td> + +<td>When no reply can be obtained in the time specified by the configured +timeout interval for a unicast request, this error is returned. In +other words, slpd is running, but something is wrong with it</td> +</tr> + +<tr> +<td>SLP_NETWORK_INIT_FAILED</td> + +<td>If the network cannot initialize properly, this error is returned. +Will also be returned if an SA or DA agent (slpd) can not be contacted. +slpd must be running in order to call SLPReg() or SLPDereg().</td> +</tr> + +<tr> +<td>SLP_MEMORY_ALLOC_FAILED </td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td>SLP_PARAMETER_BAD</td> + +<td>If a parameter passed into a function is bad, this error is returned.</td> +</tr> + +<tr> +<td>SLP_NETWORK_ERROR</td> + +<td>The failure of networking during normal operations causes this error +to be returned. In OpenSLP, this is the error you'll get if an underlying +socket() call failed.</td> +</tr> + +<tr> +<td>SLP_INTERNAL_SYSTEM_ERROR</td> + +<td>A basic failure of the API causes this error to be returned. This occurs +when a system call or library fails. The operation could not recover.</td> +</tr> + +<tr> +<td>SLP_HANDLE_IN_USE</td> + +<td>Callback functions are not permitted to recursively call into the API +on the same SLPHandle, either directly or indirectly. If an attempt is +made to do so, this error is returned from the called API function.</td> +</tr> +</table> + +<p>If no service types can be found, no error is returned. However, +no calls (other than the SLP_LAST_CALL) will be made to the SLPSrvTypesCallback. +Be aware, especially if the call is async, of error codes that may be passed +to the <tt>SLPAttrCallback</tt> callback function. +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.9.1</td> + +<td NOSAVE>Fully implemented as specified by RFC2614 except for finding +attributes by service type or with attrids containing wildcards. +These behaviors are expected to be depreciated in the next RFC 2614 revision.</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="SLPSrvTypeCallback.html">SLPSrvTypeCallback</a>, <a href="Syntax.html">Syntax</a>, +<a href="Callbacks.html">Callbacks</a> +<br> +<h3> +Example Code</h3> + +<blockquote><tt>SLPBoolean myAttrCallback(SLPHandle hslp,</tt> +<br><tt> +const char* attrlist,</tt> +<br><tt> +SLPError errcode,</tt> +<br><tt> +void* cookie )</tt> +<br><tt>{</tt> +<br><tt> if(errcode == SLP_OK)</tt> +<br><tt> {</tt> +<br><tt> printf("%s\n",attrlist);</tt> +<br><tt> }</tt> +<p><tt> return SLP_FALSE;</tt> +<br><tt>}</tt> +<br> +<p><tt>int main(int argc, char* argv[])</tt> +<br><tt>{</tt> +<br><tt> SLPError result;</tt> +<br><tt> SLPHandle hslp;</tt> +<p><tt> if(SLPOpen("en",SLP_FALSE,&hslp) == SLP_OK)</tt> +<br><tt> {</tt> +<p><tt> result = SLPFindAttrs(hslp,</tt> +<br><tt> +"service:myservice.x://myhost.mydomain.org"</tt> +<br><tt> +"", /* return all attributes */</tt> +<br><tt> +"", /* use configured scopes */</tt> +<br><tt> +myAttrCallback,</tt> +<br><tt> +NULL);</tt> +<br><tt> if(result != SLP_OK)</tt> +<br><tt> {</tt> +<br><tt> +printf("errorcode: %i\n",result);</tt> +<br><tt> }</tt> +<p><tt> result = SLPFindAttrs(hslp,</tt> +<br><tt> +"service:myservice.x://myhost.mydomain.org"</tt> +<br><tt> +"attr1,attr2", /* return attr1 and attr1 only */</tt> +<br><tt> +"", /* use configured scopes */</tt> +<br><tt> +myAttrCallback,</tt> +<br><tt> +NULL);</tt> +<br><tt> if(result != SLP_OK)</tt> +<br><tt> {</tt> +<br><tt> +printf("errorcode: %i\n",result);</tt> +<br><tt> }</tt> +<p><tt> SLPClose(hslp);</tt> +<br><tt> }</tt> +<br><tt>}</tt></blockquote> + +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindScopes.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindScopes.html new file mode 100644 index 00000000..c5781eb6 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindScopes.html @@ -0,0 +1,110 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPFindScopes()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPFindScopes</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt><a href="/SLPError.html">SLPError</a> SLPFindScopes( SLPHandle <a href="#hslp">hslp</a>,</tt> +<br><tt> +char** <a href="#scopelist">scopelist</a> )</tt> +<br> +<h3> +Description</h3> +Sets the scopelist parameter to a pointer to a comma separated list of +all available scope values. The most desirable values are always +placed first in the list. There is always one value, "DEFAULT", in +the list. +<br> +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td><a NAME="hslp"></a><tt>hslp</tt></td> + +<td NOSAVE>Pointer to the string to be un-escaped</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="scopelist"></a><tt>scopelist</tt></td> + +<td NOSAVE>Pointer to a pointer for the dynamically allocated list of scopes. +The memory should be freed by a call to <tt><a href="SLPFree.html">SLPFree()</a></tt> +when no longer needed.</td> +</tr> +</table> + +<h3> +Returns</h3> + +<table BORDER NOSAVE > +<tr NOSAVE> +<td NOSAVE>SLP_OK</td> + +<td>Indicates that the no error occurred during the operation.</td> +</tr> + +<tr> +<td>SLP_NETWORK_TIMED_OUT</td> + +<td>When no reply can be obtained in the time specified by the configured +timeout interval for a unicast request, this error is returned. In +other words, slpd is running, but something is wrong with it</td> +</tr> + +<tr> +<td>SLP_NETWORK_INIT_FAILED</td> + +<td>If the network cannot initialize properly, this error is returned. +Will also be returned if an SA or DA agent (slpd) can not be contacted. +slpd must be running in order to call SLPReg() or SLPDereg().</td> +</tr> + +<tr> +<td>SLP_MEMORY_ALLOC_FAILED </td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td>SLP_NETWORK_ERROR</td> + +<td>The failure of networking during normal operations causes this error +to be returned. In OpenSLP, this is the error you'll get if an underlying +socket() call failed.</td> +</tr> + +<tr> +<td>SLP_INTERNAL_SYSTEM_ERROR</td> + +<td>A basic failure of the API causes this error to be returned. This occurs +when a system call or library fails. The operation could not recover.</td> +</tr> +</table> + +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.8.0</td> + +<td NOSAVE>Fully implemented as specified by RFC 2608.</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="doc/html/UsersGuide/index.html">Open SLP Users Guide</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindSrvTypes.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindSrvTypes.html new file mode 100644 index 00000000..9a0f8a40 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindSrvTypes.html @@ -0,0 +1,192 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPFindSrvTypes()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPFindSrvTypes</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt><a href="SLPError.html">SLPError</a> SLPFindSrvTypes( <a href="SLPTypes.html#SLPHandle">SLPHandle</a> +<a href="#hslp">hslp</a>,</tt> +<br><tt> +const char* <a href="#namingauthority">namingauthority</a>,</tt> +<br><tt> +const char* <a href="#scopelist">scopelist</a>,</tt> +<br><tt> +<a href="SLPSrvTypeCallback.html">SLPSrvTypeCallback</a> <a href="#callback">callback</a>,</tt> +<br><tt> +void* <a href="#cookie">cookie</a>)</tt> +<h3> +Description</h3> +The <tt>SLPFindSrvType()</tt> function issues an SLP service type request +for service types in the scopes indicated by the <tt>scopelist</tt>. The +results are returned through the <tt>callback</tt> parameter. The service +types are independent of language locale, but only for services registered +in one of scopes and for the indicated naming authority. +<p>If the <tt>namingauthority</tt> is "*", then results are returned for +all naming authorities. If the naming authority is the empty string, i.e. +"", then the default naming authority, "IANA", is used. "IANA" is not a +valid naming authority name, and it is a <tt><a href="SLPError.html#SLP_PARAMETER_BAD">SLP_PARAMETER_BAD</a></tt> +error to include it explicitly. +<p>The service type names are returned with the naming authority intact. +If the naming authority is the default (i.e. empty string) then it is omitted, +as is the separating ".". Service type names from URLs of the service: +scheme are returned with the "service:" prefix intact. +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="hslp"></a><tt>hslp</tt></td> + +<td NOSAVE>The language specific <tt>SLPHandle</tt> on which to register +the service.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="namingauthority"></a><tt>namingauthority</tt></td> + +<td NOSAVE>The naming authorities to search. Use "*" for all naming +authorities and the empty string, "", for the default naming authority +(IANA). See <a href="Syntax.html#Service Type">Syntax</a> for more +information on naming authorities.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="scopelist"></a><tt>scopelist</tt></td> + +<td NOSAVE>A pointer to a comma separated list of scope names. <i>May +be the empty string</i> if you wish to use scopes this machine is configured +for. May not be NULL.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="callback"></a><tt>callback</tt></td> + +<td NOSAVE>The address of an <tt><a href="SLPSrvTypeCallback.html">SLPSrvTypeCallback</a></tt> +function that will be called to report the operation completion status. +May not be NULL. See <a href="Callbacks.html">Callbacks</a> for more information +on how callbacks are used by the SLPAPI.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="cookie"></a><tt>cookie</tt></td> + +<td NOSAVE>Pointer to memory that gets passed to the callback code. +May be NULL.</td> +</tr> +</table> + +<h3> +Returns</h3> + +<table BORDER NOSAVE > +<tr NOSAVE> +<td NOSAVE>SLP_OK</td> + +<td>Indicates that the no error occurred during the operation.</td> +</tr> + +<tr> +<td>SLP_PARSE_ERROR</td> + +<td>The SLP message was rejected by a remote SLP agent. The API returns +this error only when no information was retrieved, and at least one SA +or DA indicated a protocol error. The data supplied through the API may +be malformed or a may have been damaged in transit.</td> +</tr> + +<tr> +<td>SLP_AUTHENTICATION_ABSENT</td> + +<td>If the SLP framework supports authentication, this error arises when +the UA or SA failed to send an authenticator for requests or registrations.</td> +</tr> + +<tr> +<td>SLP_AUTHENTICATION_FAILED</td> + +<td>If the SLP framework supports authentication, this error arises when +a authentication on an SLP message failed.</td> +</tr> + +<tr> +<td>SLP_NETWORK_TIMED_OUT</td> + +<td>When no reply can be obtained in the time specified by the configured +timeout interval for a unicast request, this error is returned. In +other words, slpd is running, but something is wrong with it</td> +</tr> + +<tr> +<td>SLP_NETWORK_INIT_FAILED</td> + +<td>If the network cannot initialize properly, this error is returned. </td> +</tr> + +<tr> +<td>SLP_MEMORY_ALLOC_FAILED </td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td>SLP_PARAMETER_BAD</td> + +<td>If a parameter passed into a function is bad, this error is returned.</td> +</tr> + +<tr> +<td>SLP_NETWORK_ERROR</td> + +<td>The failure of networking during normal operations causes this error +to be returned. In OpenSLP, this is the error you'll get if an underlying +socket() call failed.</td> +</tr> + +<tr> +<td>SLP_INTERNAL_SYSTEM_ERROR</td> + +<td>A basic failure of the API causes this error to be returned. This occurs +when a system call or library fails. The operation could not recover.</td> +</tr> + +<tr> +<td>SLP_HANDLE_IN_USE</td> + +<td>Callback functions are not permitted to recursively call into the API +on the same SLPHandle, either directly or indirectly. If an attempt is +made to do so, this error is returned from the called API function.</td> +</tr> +</table> + +<p>If no service types can be found, no error is returned. However, +no calls (other than the SLP_LAST_CALL) will be made to the SLPSrvTypesCallback. +Be aware, especially if the call is async, of error codes that may be passed +to the <tt>SLPSrvTypeCallback</tt> callback function. +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.7.4</td> + +<td NOSAVE>Fully implemented as specified by RFC 2614</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="SLPSrvTypeCallback.html">SLPSrvTypeCallback</a>, <a href="Syntax.html">Syntax</a>, +<a href="Callbacks.html">Callbacks</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindSrvs.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindSrvs.html new file mode 100644 index 00000000..a6f8052d --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFindSrvs.html @@ -0,0 +1,282 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPFindSrvs()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPFindSrvs</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt><a href="SLPError.html">SLPError</a> SLPFindSrvs( <a href="SLPTypes.html#SLPHandle">SLPHandle</a> +<a href="#hslp">hslp</a>,</tt> +<br><tt> +const char* <a href="#srvtype">srvtype</a>,</tt> +<br><tt> +const char* <a href="#scopelist">scopelist</a>,</tt> +<br><tt> +const char* <a href="#filter">filter</a>,</tt> +<br><tt> + +<a href="SLPSrvURLCallback.html">SLPSrvURLCallback</a> callback,</tt> +<br><tt> +void* <a href="#cookie">cookie</a>)</tt> +<h3> +Description</h3> +Issue a query for services. +<br> +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="hslp"></a><tt>hslp</tt></td> + +<td NOSAVE>The language specific <tt>SLPHandle</tt> on which to register +the service.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="srvtype"></a><tt>srvtype</tt></td> + +<td NOSAVE>The service type string, including the authority string (if +any) for the request. May not be the empty string, "". May not be +NULL. See <a href="Syntax.html">Syntax</a> more information on Service +Type syntax. </td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="scopelist"></a><tt>scopelist</tt></td> + +<td NOSAVE>A pointer to a comma separated list of scope names. <i>May +be the empty string </i>if you wish to use scopes this machine is configured +for.. </td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="filter"></a><tt>filter</tt></td> + +<td>A query formulated of attribute pattern matching expressions in the +form of an LDAPv3 search filter. Pass in the empty string, +"" for all services of the requested type. See <a href="Syntax.html">Syntax</a> +for more information on LDAP3 search filter syntax.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="callback"></a><tt>callback</tt></td> + +<td NOSAVE>The address of an <a href="SLPSrvURLCallback.html">SLPSrvURLCallback</a> +function that will be called to report the results of the query. +May not be NULL. See <a href="Callbacks.html">Callbacks</a> for more information +on how callbacks are used by the SLPAPI.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="cookie"></a><tt>cookie</tt></td> + +<td NOSAVE>Pointer to memory that gets passed to the callback code. +May be NULL.</td> +</tr> +</table> + +<h3> +Returns</h3> + +<table BORDER NOSAVE > +<tr NOSAVE> +<td NOSAVE>SLP_OK</td> + +<td>Indicates that the no error occurred during the operation.</td> +</tr> + +<tr> +<td>SLP_PARSE_ERROR</td> + +<td>The SLP message was rejected by a remote SLP agent. The API returns +this error only when no information was retrieved, and at least one SA +or DA indicated a protocol error. The data supplied through the API may +be malformed or a may have been damaged in transit.</td> +</tr> + +<tr> +<td>SLP_AUTHENTICATION_ABSENT</td> + +<td>If the SLP framework supports authentication, this error arises when +the UA or SA failed to send an authenticator for requests or registrations.</td> +</tr> + +<tr> +<td>SLP_AUTHENTICATION_FAILED</td> + +<td>If the SLP framework supports authentication, this error arises when +a authentication on an SLP message failed.</td> +</tr> + +<tr> +<td>SLP_NETWORK_TIMED_OUT</td> + +<td>When no reply can be obtained in the time specified by the configured +timeout interval for a unicast request, this error is returned. In +other words, slpd is running, but something is wrong with it</td> +</tr> + +<tr> +<td>SLP_NETWORK_INIT_FAILED</td> + +<td>If the network cannot initialize properly, this error is returned. +Will also be returned if an SA or DA agent (slpd) can not be contacted. +slpd must be running in order to call SLPReg() or SLPDereg().</td> +</tr> + +<tr> +<td>SLP_MEMORY_ALLOC_FAILED </td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td>SLP_PARAMETER_BAD</td> + +<td>If a parameter passed into a function is bad, this error is returned.</td> +</tr> + +<tr> +<td>SLP_NETWORK_ERROR</td> + +<td>The failure of networking during normal operations causes this error +to be returned. In OpenSLP, this is the error you'll get if an underlying +socket() call failed.</td> +</tr> + +<tr> +<td>SLP_INTERNAL_SYSTEM_ERROR</td> + +<td>A basic failure of the API causes this error to be returned. This occurs +when a system call or library fails. The operation could not recover.</td> +</tr> + +<tr> +<td>SLP_HANDLE_IN_USE</td> + +<td>Callback functions are not permitted to recursively call into the API +on the same SLPHandle, either directly or indirectly. If an attempt is +made to do so, this error is returned from the called API function.</td> +</tr> +</table> + +<p>If no services can be found, no error is returned. However, no +calls (other than the SLP_LAST_CALL) will be made to the SLPSrvURLCallback. +Be aware, especially if the call is async, of error codes that may be passed +to the <tt>SLPSrvURLCallback</tt> callback function. +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.9.1</td> + +<td NOSAVE>Implemented as specified by RFC 2614.</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="Syntax.html">Syntax</a>, <a href="Callbacks.html">Callbacks</a> +<br> +<h3> +Example Code</h3> + +<blockquote><tt>#include <slp.h></tt> +<p><tt>SLPBoolean MySLPSrvURLCallback( SLPHandle hslp,</tt> +<br><tt> +const char* srvurl,</tt> +<br><tt> +unsigned short lifetime,</tt> +<br><tt> +SLPError errcode,</tt> +<br><tt> +void* cookie )</tt> +<br><tt>{</tt> +<br><tt> if(errcode == SLP_OK || errcode == SLP_LAST_CALL)</tt> +<br><tt> {</tt> +<br><tt> printf("Service URL += %s\n",srvurl);</tt> +<br><tt> printf("Service Timeout += %i\n",lifetime);</tt> +<br><tt> *(SLPError*)cookie = +SLP_OK;</tt> +<br><tt> }</tt> +<br><tt> else</tt> +<br><tt> {</tt> +<br><tt> *(SLPError*)cookie = +errcode;</tt> +<br><tt> }</tt> +<p><tt> /* return SLP_TRUE because we want to be called +again */</tt> +<br><tt> /* if more services were found +*/</tt> +<p><tt> return SLP_TRUE;</tt> +<br><tt>}</tt> +<p><tt>int main( int argc, char* argv[])</tt> +<br><tt>{</tt> +<br><tt> SLPError err;</tt> +<br><tt> SLPError callbackerr;</tt> +<br><tt> SLPHandle hslp;</tt> +<p><tt> err = SLPOpen("en",SLP_FALSE,&hslp);</tt> +<br><tt> if(err != SLP_OK)</tt> +<br><tt> {</tt> +<br><tt> printf("Error opening +slp handle %i\n",err);</tt> +<br><tt> return err;</tt> +<br><tt> }</tt> +<br> +<p><tt> err = SLPFindSrvs( hslp,</tt> +<br><tt> +"myservice.myorg",</tt> +<br><tt> +0, +/* use configured scopes */</tt> +<br><tt> +0, +/* no attr filter */</tt> +<br><tt> +MySLPSrvURLCallback,</tt> +<br><tt> +&callbackerr );</tt> +<p><tt> /* err may contain an error code that occurred +as the slp library */</tt> +<br><tt> /* _prepared_ to make the call. +*/</tt> +<br><tt> if((err != SLP_OK) || (callbackerr != SLP_OK))</tt> +<br><tt> {</tt> +<br><tt> printf("Error registering +service with slp %i\n",err);</tt> +<br><tt> return err;</tt> +<br><tt> }</tt> +<p><tt> /* callbackerr may contain an error code (that +was assigned through */</tt> +<br><tt> /* the callback cookie) that occurred as slp +packets were sent on */</tt> +<br><tt> /* the wire */</tt> +<br><tt> if( callbackerr != SLP_OK)</tt> +<br><tt> {</tt> +<br><tt> printf("Error registering +service with slp %i\n",callbackerr);</tt> +<br><tt> return callbackerr;</tt> +<br><tt> }</tt> +<p><tt> /* Now that we're done using slp, close the slp +handle */</tt> +<br><tt> SLPClose(hslp);</tt> +<br> +<p><tt> /* rest of program */</tt> +<br><tt>}</tt></blockquote> + +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFree.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFree.html new file mode 100644 index 00000000..2136222a --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPFree.html @@ -0,0 +1,57 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.79 [en] (X11; U; Linux 2.4.18-10smp i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPFree()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPFree</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt>void SLPFree( void* <a href="#srvurl">mem</a>)</tt> +<h3> +Description</h3> +Frees memory that was returned from <tt><a href="SLPParseSrvURL.html">SLPParseSrvURL()</a></tt>, +<tt><a href="SLPFindScopes.html">SLPFindScopes()</a></tt>, +<tt><a href="SLPEscape.html">SLPEscape()</a></tt>, +and <tt><a href="SLPUnescape.html">SLPUnescape()</a></tt> +<br> +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="srvurl"></a><tt>mem</tt></td> + +<td NOSAVE>A pointer to the memory to free</td> +</tr> +</table> + +<h3> +Returns</h3> +None +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.0</td> + +<td NOSAVE>Fully implemented as specified by RFC 2614.</td> +</tr> +</table> + +<h3> +See Also</h3> +<tt><a href="SLPParseSrvURL.html">SLPParseSrvURL()</a></tt>, <tt><a href="SLPFindScopes.html">SLPFindScopes()</a></tt>, +<tt><a href="SLPEscape.html">SLPEscape()</a></tt>, +<tt><a href="SLPUnescape.html">SLPUnescape()</a></tt> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPGetProperty.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPGetProperty.html new file mode 100644 index 00000000..7c27cb9d --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPGetProperty.html @@ -0,0 +1,66 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPGetProperty()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPGetProperty</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt>const char* SLPGetProperty( const char* <a href="#name">name</a>)</tt> +<br> +<h3> +Description</h3> +Returns the value of the corresponding SLP property name. The returned +string is owned by the library and MUST NOT be freed. +<br> +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="name"></a><tt>name</tt></td> + +<td NOSAVE>The name of a net.slp property to get. See <a href="/broken">OpenSLP +Users Guide</a> for a list of supported properties</td> +</tr> +</table> + +<h3> +Returns</h3> +A very thread unsafe character pointer to a string containing the property +value. If an error occurs, like the property <tt>name</tt> is not +found, NULL is returned so don't forget to check for NULL! +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.0</td> + +<td NOSAVE>Fully implemented as specified by RFC 2614.</td> +</tr> +</table> + +<h3> +Notes</h3> +For some reason the SLP API writers decided to make SLPGetProperty() and +SLPSetProperty() calls impossible to implement in a thread safe manner. +For this reason OpenSLP only allows read only access to SLP properties. +Properties are read into static data structures when the process loads, +and never changed so at least SLPGetProperty() can be called from threaded +applications. +<h3> +See Also</h3> +<a href="SLPSetProperty.html">SLPSetProperty()</a>, <a href="/broken">Open +SLP Users Guide</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPGetRefreshInterval.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPGetRefreshInterval.html new file mode 100644 index 00000000..af0d9d34 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPGetRefreshInterval.html @@ -0,0 +1,56 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPGetRefreshInterval()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPGetRefreshInterval</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt>unsigned short SLPGetRefreshInterval()</tt> +<h3> +Description</h3> +Returns the minimum refresh interval that will be accepted by all SLP agents +on the network. +<h3> +Parameters</h3> +None +<h3> +Returns</h3> +A positive integer value that is the smallest value that should be passed +as a <tt><a href="SLPReg.html#lifetime">lifetime</a></tt> to <tt><a href="SLPReg.html">SLPReg()</a></tt>. +If no agents advertise a minimum refresh interval, then zero is returned. +( Zero is not a valid value for the <tt><a href="SLPReg.html#lifetime">lifetime</a></tt> +parameter to <a href="SLPReg.html">SLPReg()</a> .) +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.7.8</td> + +<td NOSAVE>Not Implemented. Always returns SLP_NOT_IMPLEMENTED</td> +</tr> +</table> + +<h3> +Notes</h3> +RFC 2614 is really not clear as to how this function works. In fact +the RFC declares the return to be of type <tt>unsigned short</tt> and specifies +that (negative) <a href="SLPError.html">SLPError</a> codes are returned +on error. Since a negative return could also be interpreted as (a +very large) unsigned value, OpenSLP does not return <a href="SLPError.html">SLPError</a> +codes cast to unsigned shorts it just returns zero. +<h3> +See Also</h3> +<a href="SLPReg.html">SLPReg()</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPOpen.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPOpen.html new file mode 100644 index 00000000..b7497a24 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPOpen.html @@ -0,0 +1,142 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPOpen</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPOpen</h2> + +<hr WIDTH="100%"> +<h3> +Include</h3> + +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt><a href="SLPError.html">SLPError</a> SLPOpen(const char* <a href="#lang">lang</a>, +<a href="SLPTypes.html#SLPBoolean">SLPBoolean</a> +<a href="#isasync">isasync</a>, +<a href="SLPTypes.html#SLPHandle">SLPHandle</a>* +<a href="#phslp">phslp</a>)</tt> +<br> +<h3> +Description</h3> +Returns a <tt>SLPHandle</tt> handle in the <tt>phslp</tt> parameter for +the language locale passed in as the <tt>lang</tt> parameter. The client +indicates if operations on the handle are to be synchronous or asynchronous +through the <tt>isasync</tt> parameter. The handle encapsulates the language +locale for SLP requests issued through the handle, and any other resources +required by the implementation. The return value of the function is an +<tt>SLPError</tt> +code indicating the status of the operation. Upon failure, the <tt>phslp</tt> +parameter is NULL. +<p>An <tt>SLPHandle</tt> can only be used for one SLP API operation at +a time. If the original operation was started asynchronously, any attempt +to start an additional operation on the handle while the original operation +is pending results in the return of an <tt>SLP_HANDLE_IN_USE</tt> error +from the API function. The <tt>SLPClose()</tt> API function terminates +any outstanding calls on the handle. If an implementation is unable to +support a asynchronous( resp. synchronous) operation, due to memory constraints +or lack of threading support, the <tt>SLP_NOT_IMPLEMENTED </tt>flag may +be returned when the isasync flag is <tt>SLP_TRUE</tt> (resp. <tt>SLP_FALSE</tt>). +<p>In the OpenSLP implementation, SLPHandles are used to cache information +that is costly to obtain (in terms of network usage and time). +Since the RFC 2614 API does not specify functions to initialize the +implementation library, OpenSLP keeps track of the number of SLPHandles +that are open. Several global library data structures are initialized +when the first SLPHandle is opened and maintained until the last SLPHandle +is closed. Therefore, it is most efficient to leave SLPHandles open +for as long as you will need them (often for the entire life of a process). +If you can help it, DO NOT make a habit of opening and closing SLPHandles +frequently. +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="lang"></a><tt>lang</tt></td> + +<td NOSAVE>A pointer to null terminated array of characters containing +the RFC 1766 Language Tag for the natural language locale of requests and +registrations issued on the handle. Pass in NULL or the empty string, +"" to use the local the machine is configured to use.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="isasync"></a><tt>isasync</tt></td> + +<td NOSAVE>A <tt>SLPBoolean</tt> value indicating whether the <tt>SLPHandle</tt> +should be opened for asynchronous operation or not.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="phslp"></a><tt>phslp</tt></td> + +<td NOSAVE>A pointer to an <tt>SLPHandle</tt>, in which the open <tt>SLPHandle</tt> +is returned. If an error occurs, the value upon return is NULL.</td> +</tr> +</table> + +<h3> +Returns</h3> + +<table BORDER NOSAVE > +<tr> +<td>SLP_AUTHENTICATION_FAILED</td> + +<td>If the SLP framework supports authentication, this error arises when +a authentication on an SLP message failed.</td> +</tr> + +<tr> +<td>SLP_MEMORY_ALLOC_FAILED </td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td>SLP_PARAMETER_BAD</td> + +<td>If a parameter passed into a function is bad, this error is returned.</td> +</tr> + +<tr> +<td>SLP_INTERNAL_SYSTEM_ERROR</td> + +<td>A basic failure of the API causes this error to be returned. This occurs +when a system call or library fails. The operation could not recover.</td> +</tr> + +<tr> +<td>SLP_HANDLE_IN_USE</td> + +<td>Callback functions are not permitted to recursively call into the API +on the same SLPHandle, either directly or indirectly. If an attempt is +made to do so, this error is returned from the called API function.</td> +</tr> +</table> + +<p>Be aware, especially if the call is async, of error codes that may be +passed to the SLPRegReport() callback function. +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.0</td> + +<td NOSAVE>Fully implemented as specified by RFC 2614</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="SLPClose.html">SLPClose()</a> +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPParseSrvURL.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPParseSrvURL.html new file mode 100644 index 00000000..7eb970c4 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPParseSrvURL.html @@ -0,0 +1,103 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPParseSrvURL()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPParseSrvURL</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt><a href="SLPError.html">SLPError</a> SLPParseSrvURL( const char* +<a href="#srvurl">srvurl</a>,</tt> +<br><tt> +<a href="SLPTypes.html#SLPSrvURL">SLPSrvURL</a>** +<a href="#parsedurl">parsedurl</a> +)</tt> +<h3> +Description</h3> +Parses a Service URL passed in as a character string and returns the results +in a pointer to a dynamically allocated <tt><a href="SLPTypes.html#SLPSrvURL">SLPSrvURL</a></tt> +structure. The pointer returned in <tt>parsedurl</tt> should be freed +by <a href="SLPFree.html">SLPFree()</a>. +<br> +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="srvurl"></a><tt>srvurl</tt></td> + +<td NOSAVE>Pointer to a character buffer containing the null terminated +URL string to parse. See <a href="Syntax.html#Service Url">Syntax</a> +for more information on Service URL syntax.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="parsedurl"></a><tt>parsedurl</tt></td> + +<td NOSAVE>Pointer to a pointer for the <tt><a href="SLPTypes.html#SLPSrvURL">SLPSrvURL</a></tt> +structure that receives the parsed URL. The memory should be freed +by a call to <a href="SLPFree.html">SLPFree()</a> when no longer needed.</td> +</tr> +</table> + +<h3> +Returns</h3> + +<table BORDER NOSAVE > +<tr NOSAVE> +<td NOSAVE>SLP_OK</td> + +<td>Indicates that the no error occurred during the operation.</td> +</tr> + +<tr> +<td>SLP_PARSE_ERROR</td> + +<td>The service url being parsed is not of valid syntax</td> +</tr> + +<tr> +<td>SLP_MEMORY_ALLOC_FAILED </td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td>SLP_PARAMETER_BAD</td> + +<td>If a parameter passed into a function is bad, this error is returned.</td> +</tr> + +<tr> +<td>SLP_INTERNAL_SYSTEM_ERROR</td> + +<td>A basic failure of the API causes this error to be returned. This occurs +when a system call or library fails. The operation could not recover.</td> +</tr> +</table> + +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.0</td> + +<td NOSAVE>Fully implemented as specified by RFC 2614.</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="SLPFree.html">SLPFree()</a>, <a href="SLPTypes.html">SLPTypes</a>, +<a href="Syntax.html">Syntax</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPReg.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPReg.html new file mode 100644 index 00000000..3d15ead2 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPReg.html @@ -0,0 +1,313 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPReg()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPReg</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt><a href="SLPError.html">SLPError</a> SLPReg( <a href="SLPTypes.html#SLPHandle">SLPHandle</a> +<a href="#hslp">hslp</a>,</tt> +<br><tt> +const char* <a href="#srvurl">srvurl</a>,</tt> +<br><tt> +unsigned short <a href="#lifetime">lifetime</a>,</tt> +<br><tt> +const char* <a href="#srvtype">srvtype</a>,</tt> +<br><tt> +const char* <a href="#attrs">attrs</a>,</tt> +<br><tt> +<a href="SLPTypes.html#SLPBoolean">SLPBoolean</a> <a href="#fresh">fresh</a>,</tt> +<br><tt> +<a href="SLPRegReport.html">SLPRegReport</a> <a href="#callback">callback</a>,</tt> +<br><tt> +void* <a href="#cookie">cookie </a>)</tt> +<h3> +Description</h3> +Registers the URL in <tt>srvurl</tt> having the lifetime <tt>lifetime</tt> +with the attribute list in <tt>attrs</tt>. The <tt>attrs</tt> list is a +comma separated list of attribute assignments in the wire format (including +escaping of reserved characters). The <tt>lifetime</tt> parameter must +be nonzero and less than or equal to <tt><a href="SLPTypes.html#SLPURLLifetime">SLP_LIFETIME_MAXIMUM</a></tt>. +If the <tt>fresh</tt> flag is <tt>SLP_TRUE</tt>, then the registration +is new (the SLP protocol FRESH flag is set) and the registration replaces +any existing registrations. The <tt>srvtype</tt> parameter is a service +type name and can be included for service URLs that are not in the service: +scheme. If the URL is in the service: scheme, the <tt>srvtype</tt> parameter +is ignored. If the fresh flag is <tt>SLP</tt>_FALSE, then an existing registration +is updated. Registrations and updates take place in the language locale +of the <tt>hslp</tt> handle. +<br> +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="hslp"></a><tt>hslp</tt></td> + +<td NOSAVE>The language specific <tt>SLPHandle</tt> on which to register +the service.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="srvurl"></a><tt>srvurl</tt></td> + +<td NOSAVE>The service URL to register. May not be the empty string. +May not be NULL. Must conform to SLP Service URL syntax. <tt><a href="SLPError.html#INVALID_REGISTRATION">SLP_INVALID_REGISTRATION</a></tt> +will be returned if srvurl is not a SLP Service URL. See <a href="Syntax.html">Syntax</a> +for more information on Service URL syntax.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="lifetime"></a><tt>lifetime</tt></td> + +<td NOSAVE>An unsigned short giving the lifetime of the service in seconds. +The value must be an unsigned integer less than or equal to <tt><a href="SLPTypes.html#SLPURLLifetime">SLP_LIFETIME_MAXIMUM</a></tt> +and greater than zero. <i>If lifetime is set to <tt><a href="SLPTypes.html#SLPURLLifetime">SLP_LIFETIME_MAXIMUM</a></tt>, +it will remain registered for the life of the calling process.</i></td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="srvtype"></a>srvtype</td> + +<td NOSAVE>This parameter is always ignored because the Service URL syntax +required for the <tt>srvurl</tt> parameter encapsulates the service-type. +See <a href="Syntax.html">Syntax</a> for more information on Service URL +syntax.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="attrs"></a>attrs</td> + +<td>A list of attribute assignment expressions for the attributes of the +registered service. Use the empty string, "" for no attributes. +Example: "(attr1=val1),(attr2=val2),(attr3=val3)"</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="fresh"></a><tt>fresh</tt></td> + +<td NOSAVE>An SLPBoolean that is <tt>SLP_TRUE</tt> if the registration +is new or <tt>SLP_FALSE</tt> for a re-registration. Currently, OpenSLP +does not support incremental registrations. If <tt>fresh</tt> is +<tt>SLP_FALSE</tt>, +<tt>SLPReg()</tt> +will return <tt><a href="SLPError.html#SLP_NOT_IMPLEMENTED">SLP_NOT_IMPLEMENTED</a></tt>.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="callback"></a><tt>callback</tt></td> + +<td NOSAVE>The address of an <tt><a href="SLPRegReport.html">SLPRegReport</a></tt> +function that will be called to report the operation completion status. +Man not be NULL. See <a href="Callbacks.html">Callbacks</a> for more information +on how callbacks are used by the SLPAPI.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="cookie"></a><tt>cookie</tt></td> + +<td NOSAVE>Pointer to memory that gets passed to the callback code. +May be NULL.</td> +</tr> +</table> + +<h3> +Returns</h3> + +<table BORDER NOSAVE > +<tr NOSAVE> +<td NOSAVE>SLP_OK</td> + +<td>Indicates that the no error occurred during the operation.</td> +</tr> + +<tr> +<td>SLP_INVALID_REGISTRATION</td> + +<td>The deregistered service url does not conform to valid service url +syntax. The service url being deregistered is not registered this +means that either it was never registered via a call to SLPReg() or that +the registration lifetime has expired. SLP_INVALID_REGISTRATION +is commonly returned when an attempt is made to deregister a service that +was registered by a call to SLPReg() on a different host.</td> +</tr> + +<tr> +<td>SLP_PARSE_ERROR</td> + +<td>The SLP message was rejected by a remote SLP agent. The API returns +this error only when no information was retrieved, and at least one SA +or DA indicated a protocol error. The data supplied through the API may +be malformed or a may have been damaged in transit.</td> +</tr> + +<tr> +<td>SLP_AUTHENTICATION_ABSENT</td> + +<td>If the SLP framework supports authentication, this error arises when +the UA or SA failed to send an authenticator for requests or registrations.</td> +</tr> + +<tr> +<td>SLP_AUTHENTICATION_FAILED</td> + +<td>If the SLP framework supports authentication, this error arises when +a authentication on an SLP message failed.</td> +</tr> + +<tr> +<td>SLP_NETWORK_TIMED_OUT</td> + +<td>When no reply can be obtained in the time specified by the configured +timeout interval for a unicast request, this error is returned. In +other words, slpd is running, but something is wrong with it</td> +</tr> + +<tr> +<td>SLP_NETWORK_INIT_FAILED</td> + +<td>If the network cannot initialize properly, this error is returned. +Will also be returned if an SA or DA agent (slpd) can not be contacted. +slpd must be running in order to call SLPReg() or SLPDereg().</td> +</tr> + +<tr> +<td>SLP_MEMORY_ALLOC_FAILED </td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td>SLP_PARAMETER_BAD</td> + +<td>If a parameter passed into a function is bad, this error is returned.</td> +</tr> + +<tr> +<td>SLP_NETWORK_ERROR</td> + +<td>The failure of networking during normal operations causes this error +to be returned. In OpenSLP, this is the error you'll get if an underlying +socket() call failed.</td> +</tr> + +<tr> +<td>SLP_INTERNAL_SYSTEM_ERROR</td> + +<td>A basic failure of the API causes this error to be returned. This occurs +when a system call or library fails. The operation could not recover.</td> +</tr> + +<tr> +<td>SLP_HANDLE_IN_USE</td> + +<td>Callback functions are not permitted to recursively call into the API +on the same SLPHandle, either directly or indirectly. If an attempt is +made to do so, this error is returned from the called API function.</td> +</tr> +</table> + +<p>Be aware, especially if the call is async, of error codes that may be +passed to the SLPRegReport() callback function. +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.8.0</td> + +<td NOSAVE>Fully implemented as specified by RFC 2614</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="SLPDereg.html">SLPDeReg()</a>, <a href="Syntax.html">Syntax</a>, +<a href="Callbacks.html">Callbacks</a> +<br> +<h3> +Example Code</h3> + +<blockquote><tt>#include <slp.h></tt> +<p><tt>void MySLPRegReport(SLPHandle hslp, SLPError errcode, void* cookie)</tt> +<br><tt>{</tt> +<br><tt> /* return the error code in the cookie */</tt> +<br><tt> *(SLPError*)cookie = errcode;</tt> +<p><tt> /* You could do something else here like print +out */</tt> +<br><tt> /* the errcode, etc. Remember, as a general +rule, */</tt> +<br><tt> /* do not try to do too much in a callback because +*/</tt> +<br><tt> /* it is being executed by the same thread that +is */</tt> +<br><tt> /* reading slp packets from the wire. +*/</tt> +<br><tt>}</tt> +<p><tt>int main(int argc, char* argv[])</tt> +<br><tt>{</tt> +<br><tt> SLPError err;</tt> +<br><tt> SLPError callbackerr;</tt> +<br><tt> SLPHandle hslp;</tt> +<p><tt> err = SLPOpen("en",SLP_FALSE,&hslp);</tt> +<br><tt> if(err != SLP_OK)</tt> +<br><tt> {</tt> +<br><tt> printf("Error opening +slp handle %i\n",err);</tt> +<br><tt> return err;</tt> +<br><tt> }</tt> +<p><tt> /* Register a service with SLP */</tt> +<br><tt> err = SLPReg( hslp,</tt> +<br><tt> +"service:myservice.myorg://hostname.domain.com:6672",</tt> +<br><tt> +SLP_LIFETIME_MAXIMUM,</tt> +<br><tt> +0,</tt> +<br><tt> +"(public_key=......my_pgp_key.......)",</tt> +<br><tt> +SLP_TRUE,</tt> +<br><tt> +MySLPRegReport,</tt> +<br><tt> +&callbackerr );</tt> +<p><tt> /* err may contain an error code that occurred +as the slp library */</tt> +<br><tt> /* _prepared_ to make the call. +*/</tt> +<br><tt> if(( err != SLP_OK) || (callbackerr != SLP_OK))</tt> +<br><tt> {</tt> +<br><tt> printf("Error registering +service with slp %i\n",err);</tt> +<br><tt> return err;</tt> +<br><tt> }</tt> +<p><tt> /* callbackerr may contain an error code (that +was assigned through */</tt> +<br><tt> /* the callback cookie) that occurred as slp +packets were sent on */</tt> +<br><tt> /* the wire */</tt> +<br><tt> if( callbackerr != SLP_OK)</tt> +<br><tt> {</tt> +<br><tt> printf("Error registering +service with slp %i\n",callbackerr);</tt> +<br><tt> return callbackerr;</tt> +<br><tt> }</tt> +<p><tt> /* Now that we're done using slp, close the slp +handle */</tt> +<br><tt> SLPClose(hslp);</tt> +<p><tt> /* rest of program */</tt> +<br><tt>}</tt> +<br><tt></tt> </blockquote> + +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPRegReport.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPRegReport.html new file mode 100644 index 00000000..e952b1bc --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPRegReport.html @@ -0,0 +1,75 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPRegReport Callback</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPRegReport</h2> + +<h2> + +<hr WIDTH="100%"></h2> + +<h3> +Declaration</h3> +<tt>typedef void SLPRegReport(<a href="SLPTypes.html#SLPHandle">SLPHandle</a><a href="#hslp">hslp</a>, +<a href="SLPTypes.html#SLPError">SLPError</a> +errcode, void* cookie)</tt> +<br> +<h3> +Description</h3> +The SLPRegReport callback type is used as the type for the callback function +that is passed in to the <a href="SLPReg.html">SLPReg()</a>, <a href="SLPDereg.html">SLPDeReg()</a> +and <a href="SLPDelAttrs.html">SLPDelAttrs()</a> functions. +<br> +<h3> +Parameters</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td><a NAME="hslp"></a>hslp</td> + +<td NOSAVE>The SLPHandle that was used to initiate the operation.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="errcode"></a>errcode</td> + +<td NOSAVE>An error code indicating if an error occurred during the operation.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="cookie"></a>cookie</td> + +<td NOSAVE>Pointer to the same memory that was passed into the initiating +function call.</td> +</tr> + +<caption ALIGN=BOTTOM> </caption> +</table> + +<h3> +Returns</h3> +None +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.0</td> + +<td NOSAVE>SLPRegReport() callbacks are called as specified by RFC 2614. </td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="Callbacks.html">Callbacks</a> +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPSetProperty.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPSetProperty.html new file mode 100644 index 00000000..9065c246 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPSetProperty.html @@ -0,0 +1,78 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +SLPSetProperty</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>#include <slp.h></tt> +<p><tt>void SLPSetProperty( const char* name,</tt> +<br><tt> +const char* value )</tt> +<br> +<h3> +Description</h3> +This function is supposed to allow the caller to set SLP properties, but +it is impossible to implement this function along with <a href="SLPGetProperty.html">SLPGetProperty()</a> +in a way that is even remotely thread safe. Therefore, OpenSLP +completely ignores all calls made to <tt>SLPSetProperty() </tt>so that +<a href="SLPSetProperty.html">SLPGetProperty()</a> +can be used in threaded applications. +<br> +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="name"></a><tt>name</tt></td> + +<td NOSAVE>Pointer to the name of a net.slp property to set. See +<a href="/broken">OpenSLP +Users Guide</a> for a list of supported properties</td> +</tr> + +<tr> +<td><a NAME="value"></a><tt>value</tt></td> + +<td>Pointer to the new string value.</td> +</tr> +</table> + +<h3> +Returns</h3> +None +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.8.0</td> + +<td NOSAVE>Not implemented. See Notes.</td> +</tr> +</table> + +<h3> +Notes</h3> +For some reason the SLP API writers decided to make SLPGetProperty() and +SLPSetProperty() calls impossible to implement in a thread safe manner. +For this reason OpenSLP only allows read only access to SLP properties. +Properties are read into static data structures when the process loads, +and never changed so at least SLPGetProperty() can be called from threaded +applications. +<p>Some discussions have taken place on the srvloc mailing list and it +looks like the SLP API will be revised to solve this problem. Until +this time OpenSLP will not implement SLPSetProperty(). +<h3> +See Also</h3> +<a href="SLPGetProperty.html">SLPGetProperty()</a>, <a href="/broken">Open +SLP Users Guide</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPSrvTypeCallback.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPSrvTypeCallback.html new file mode 100644 index 00000000..3a7599a0 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPSrvTypeCallback.html @@ -0,0 +1,93 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPSrvTypeCallback</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPSrvTypeCallback</h2> + +<hr WIDTH="100%"> +<h3> +<tt>Declaration</tt></h3> +<tt>typedef <a href="/SLPTypes.html#SLPBoolean">SLPBoolean</a> SLPSrvTypeCallback( +<a href="/SLPTypes.html#SLPHandle">SLPHandle</a> +<a href="#hslp">hslp</a>,</tt> +<br><tt> +const char* <a href="#srvtypes">srvtypes</a>,</tt> +<br><tt> + +<a href="/SLPTypes.html#SLPError">SLPError</a> <a href="#errcode">errcode</a>,</tt> +<br><tt> +void* <a href="#cookie">cookie</a> )</tt> +<h3> +Description</h3> +The <tt>SLPSrvTypeCallback</tt> type is the type of the callback function +passed as a parameter to the <tt><a href="SLPFindSrvTypes.html">SLPFindSrvTypes()</a></tt> +function. If the hslp parameter was opened asynchronously, the results +returned through the callback may be uncollated. If the hslp handle +parameter was opened synchronously, then the results will be collated to +remove duplicates. +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="hslp"></a><tt>hslp</tt></td> + +<td NOSAVE>The language specific <tt>SLPHandle</tt> that was passed in +to the <tt>SLPFindSrvTypes()</tt> function.</td> +</tr> + +<tr> +<td><a NAME="srvtypes"></a><tt>srvtypes</tt></td> + +<td>Pointer to a comma separated list of service types. See <a href="Syntax.html#Service Type">Syntax</a> +for more information on service type syntax. </td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="errcode"></a><tt>errcode</tt></td> + +<td NOSAVE>An error code indicating if an error occurred during the operation. +The callback should check this error code before processing the parameters. </td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="cookie"></a><tt>cookie</tt></td> + +<td NOSAVE>The same cookie that was passed as a parameter to the <tt>SLPFindSrvTypes()</tt> +call</td> +</tr> + +<caption ALIGN=BOTTOM> </caption> +</table> + +<h3> +Returns</h3> +The callback should return <tt>SLP_TRUE</tt> if more data is desired. +The callback may continue to return <tt>SLP_TRUE</tt> until it is called +with an errcode of <tt>SLP_LAST_CALL</tt>. If no more data is requested +the callback should return <tt>SLP_FALSE</tt>. +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.0</td> + +<td NOSAVE>SLPSrvTyperCallback functions are not called because SLPFindSrvTypes() +is not implemented</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="Syntax.html">Syntax</a>, +<a href="Callbacks.html">Callbacks</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPSrvURLCallback.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPSrvURLCallback.html new file mode 100644 index 00000000..4b5ebc79 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPSrvURLCallback.html @@ -0,0 +1,101 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPSrvURLCallback</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPSrvURLCallback</h2> + +<hr WIDTH="100%"> +<h3> +Declaration</h3> +<tt>typedef <a href="SLPTypes.html#SLPBoolean">SLPBoolean</a> SLPSrvURLCallback( +<a href="SLPTypes.html#SLPHandle">SLPHandle</a> +<a href="#hslp">hslp</a>,</tt> +<br><tt> +const char* <a href="#srvurl">srvurl</a>,</tt> +<br><tt> +unsigned short <a href="#lifetime">lifetime</a>,</tt> +<br><tt> + +<a href="SLPTypes.html#SLPError">SLPError</a> <a href="#errcode">errcode</a>,</tt> +<br><tt> +void* <a href="#cookie">cookie</a> )</tt> +<h3> +Description</h3> +The <tt>SLPSrvURLCallback</tt> type is the type of the callback function +parameter to <tt>SLPFindSrvs()</tt> function. If the <tt>hslp</tt> handle +parameter was opened asynchronously, the results returned through the callback +MAY be uncollated. +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="hslp"></a><tt>hslp</tt></td> + +<td NOSAVE>The language specific <tt>SLPHandle</tt> on which to register +the service.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="srvurl"></a><tt>srvurl</tt></td> + +<td>Pointer to the SLP Service URL of the requested service. See +<a href="Syntax.html">Syntax</a> +for more information about SLP Service URLs</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="lifetime"></a><tt>lifetime</tt></td> + +<td NOSAVE>The lifetime of the service in seconds</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="errcode"></a><tt>errcode</tt></td> + +<td NOSAVE>An error code indicating if an error occurred during the operation. +The callback should check this error code before processing the parameters. </td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="cookie"></a><tt>cookie</tt></td> + +<td NOSAVE>The same cookie that was passed as a parameter to the <tt>SLPFindSrvs()</tt> +call</td> +</tr> + +<caption ALIGN=BOTTOM> </caption> +</table> + +<h3> +Returns</h3> +The callback should return <tt>SLP_TRUE</tt> if more data is desired. +The callback may continue to return <tt>SLP_TRUE</tt> until it is called +with an errcode of <tt>SLP_LAST_CALL</tt>. If no more data is requested +the callback should return <tt>SLP_FALSE</tt>. +<br> +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.0</td> + +<td NOSAVE>SLPSrvURLCallback functions are called as specified by RFC 2614</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="/Syntax.html">Syntax</a>, +<a href="/Callbacks.html">Callbacks</a> +<br> +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPTypes.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPTypes.html new file mode 100644 index 00000000..4722ee7d --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPTypes.html @@ -0,0 +1,62 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLP Data Types</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLP Data Types</h2> + +<hr WIDTH="100%"> +<h3> +<a NAME="SLPURLLifetime"></a>SLPURLLifetime</h3> +An enumerated type with a range of 0 - 65535. There are two defined +values <tt>of:</tt> +<blockquote><tt>SLP_LIFETIME_DEFAULT 10800</tt> +<br><tt>SLP_LIFETIME_MAXIMUM 65535</tt></blockquote> + +<h3> +<a NAME="SLPError"></a>SLPError</h3> +An enumerated type with a range of -26 - 1. See <a href="SLPError.html">SLPError +Codes </a>for more detail. +<br> +<h3> +<a NAME="SLPBoolean"></a>SLPBoolean</h3> +A boolean value with one of the following values: +<blockquote><tt>SLP_FALSE 0</tt> +<br><tt>SLP_TRUE 1</tt></blockquote> + +<h3> +<a NAME="SLPSrvURL"></a>SLPSrvURL</h3> +Structure that is used to index the parts of a parsed Service URL that +is returned by <a href="SLPParseSrvURL.html">SLPParseSrvURL()</a>. +The structure contains the following members. +<blockquote><tt>char* s_pcSrvType</tt> +<blockquote>A pointer to a character string containing the service type +name, including naming authority. The service type name includes +the "service:" if the URL is of the service: scheme.</blockquote> +<tt>char* s_pcHost</tt> +<blockquote>A pointer to a character string containing the host identification +information.</blockquote> +<tt>int s_iPort</tt> +<blockquote>The port number, or zero if none. The port is only available +if the transport is IP</blockquote> +<tt>char* s_pcNetFamily</tt> +<blockquote>A pointer to a character string containing the network address +family identifier. Possible values are "ipx" for the IPX family, +"at" for the Appletalk family, and "" (the empty string) for IP address +family. OpenSLP only supports the IP address family.</blockquote> +<tt>char* s_pcSrvPart</tt> +<blockquote>The remainder of the URL.</blockquote> +</blockquote> + +<h3> +<a NAME="SLPHandle"></a>SLPHandle</h3> +The SLPHandle type is returned by <a href="SLPOpen.html">SLPOpen()</a> +and is a parameter to all SLP Functions. The type is opaque to the +caller. +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPUnescape.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPUnescape.html new file mode 100644 index 00000000..61045efd --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/SLPUnescape.html @@ -0,0 +1,99 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - SLPUnEscape()</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLPUnescape</h2> + +<hr WIDTH="100%"> +<h3> +<tt>Declaration</tt></h3> +<tt>#include <slp.h></tt> +<p><tt><a href="/SLPError.html">SLPError</a> SLPUnescape( const char* <a href="#escaped">escaped</a>,</tt> +<br><tt> +char** <a href="#unescaped">unescaped</a>,</tt> +<br><tt> +<a href="/SLPTypes.html#SLPBoolean">SLPBoolean</a> <a href="#ist">istag</a> +)</tt> +<h3> +Description</h3> +Process the input string to unescapes any SLP reserved characters. +If the <tt>istag</tt> parameter is SLP_TRUE then SLPUnEscape() will look +for bad tag characters. +<h3> +Parameters</h3> + +<table BORDER CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td><a NAME="escaped"></a><tt>escaped</tt></td> + +<td NOSAVE>Pointer to the string to be un-escaped</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE><a NAME="unescaped"></a><tt>unescaped</tt></td> + +<td NOSAVE>Pointer to a pointer for the dynamically allocated output string. +The memory should be freed by a call to <tt><a href="SLPFree.html">SLPFree()</a></tt> +when no longer needed.</td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td><a NAME="ist"></a>istag</td> + +<td NOSAVE>When SLP_TRUE_ the input buffer is checked for bad characters</td> +</tr> +</table> + +<h3> +Returns</h3> + +<table BORDER NOSAVE > +<tr> +<td>SLP_OK</td> + +<td>Indicates that the no error occurred during the operation.</td> +</tr> + +<tr> +<td>SLP_PARSE_ERROR</td> + +<td>The API returns this error only when no information was retrieved, +and at least one SA or DA indicated a protocol error. The data supplied +through the API may be malformed or a may have been damaged in transit.</td> +</tr> + +<tr> +<td>SLP_MEMORY_ALLOC_FAILED </td> + +<td>Out of memory error</td> +</tr> + +<tr> +<td>SLP_PARAMETER_BAD</td> + +<td>If a parameter passed into a function is bad, this error is returned.</td> +</tr> +</table> + +<h3> +Status</h3> + +<table CELLPADDING=5 NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE>OpenSLP 0.6.8</td> + +<td NOSAVE>Fully implemented as specified by RFC 2614.</td> +</tr> +</table> + +<h3> +See Also</h3> +<a href="SLPEscape.html">SLPEscape()</a>, <a href="SLPFree.html">SLPFree()</a> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Security.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Security.html new file mode 100644 index 00000000..9f58a821 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Security.html @@ -0,0 +1,87 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.76C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - Security</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h1> +Writing Secure SLP Enabled Applications +<hr WIDTH="100%"></h1> + +<h3> +Introduction</h3> +Major changes were made to the OpenSLP 0.8.x codebase to add SLPv2 message +authentication support for OpenSLP 0.9.0. Until this time, +there were no plans to ever implement SLPv2 security due to the ideas expressed +in a internal Caldera document entitled "OpenSLP and SLPv2 Authentication". +The document (<a href="openslp_security_whitepaper.html">full text +available</a>) mostly references and draws conclusions from discussion +from the srvloc@srvloc.org mailing list. The following is the +concluding paragraphs of the document. +<br> +<blockquote><i>For those that are not willing to endure the tedium of reading +the entire mailing list discussion, the conclusion was eventually +made (at least by the author) that though SLP authentication may be +appropriate in some specialized SLP deployments, it is probably not beneficial +in normal network computer environments. This conclusion +is based on the following premises:</i></blockquote> + +<ul> +<ul> +<li> +<i>Implementation of SLP authentication in the absence of public key infrastructure +standards would require enough manual configuration to invalidate all claims +SLP has to increased usability.</i></li> + +<li> +<i>Common helper protocols DNS, DHCP, IP, even ARP are currently insecure +for usability reasons. SLP fits into this category of protocols +where lack of security may be considered a feature when it allows for maximal +usability.</i></li> + +<li> +<i>Given the lack of security in the above mentioned (and other) protocols +self-established authentication of end to end communication is required +anyway for secure communication of network software entities.</i></li> + +<li> +<i>In the presence of appropriate end to end security mechanisms, +SLP related security attacks are limited to the realm of "denial of service" +or "disruptions" -- even when no authentication is implemented in SLP. +In other words there is not a risk of compromise of confidential information +that can be attributed to SLP as long as appropriate end to end security +is established.</i></li> +</ul> +<i></i> +<p><br><i>So, for the OpenSLP project, there are not any plans to implement +SLPv2 security. (This may change in the future depending on +the success of ongoing PKI standardization efforts.) There +are, however, many things that could be done to reduce opportunities for +"denial of service attacks" or other malicious SLP related disruptions. +These will be addressed in future versions of OpenSLP. +Also, in order to inform developers about the importance of writing secure +applications, plans have been made to include an SLP Security HOWTO +as part of the OpenSLP Documentation.</i></ul> +The existence of SLPv2 authentication in OpenSLP <b>does not </b>eliminate +the need to provide secure end-to-end communication for service specific +protocols (read the <a href="openslp_security_whitepaper.html">full +text</a> of the paper if you don't know what I'm talking about here). +OpenSLP security does not do any good at all if the authentication, +integrity, and/or privacy of service specific communication weak. +<br> +<h3> +Who should read this document?</h3> +If you are a developer that writes SLP enabled software, you should read +this document. If you are a system or network administrator that +is concerned with how to setup and maintain secure SLP installations, +you should read the <a href="../UsersGuide/Security.html">Security section +of the OpenSLP Users guide.</a> +<br> +<br> +<p>*** PLEASE PATIENT UNTIL I GET SOME TIME TO WRITE THE REST OF THIS DOCUMENT +*** +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Syntax.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Syntax.html new file mode 100644 index 00000000..b69667fe --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/Syntax.html @@ -0,0 +1,104 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - Syntax</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +SLP Syntaxes</h2> + +<hr WIDTH="100%"> +<h3> +<a NAME="Service Type"></a>SLP Service Type Syntax</h3> +The official definition of Service Type strings can be found in <a href="../../rfc/rfc2609.txt">RFC +2609</a>, "Service Templates and Service Schemes". If you will be +working with "well known" (IANA) service types, you should read it. +If you are developing applications for "proprietary" services then you +will probably be satisfied with the following explanation: +<blockquote><b>Service-Type = "service:"<abstract-type.naming-authority>":"<concrete-type></b></blockquote> +The abstract-type is simple (hopefully short) descriptive string that describes +the type of service. The naming-authority is the name (hopefully +unique) name of the organization that named the service. The naming-authority +is optional, but if it is omitted then IANA is assumed to be the naming +authority and IANA requires service-types to be registered (see RFC 2609). +The concrete-type is also optional. Think of a concrete-type as a +kind of sub-type of the abstract-type. For example, "printer" is +an abstract type (owned by IANA) and "printer:lpr" is a concrete type (owned +by IANA). +<h4> +Service Type Examples</h4> +"weather.nasa:wtp" - A (fictitious) weather service type owned by +NASA that uses WTP protocol +<br>"weather.nasa:swtp" - A (fictitious) weather service type owned by NASA +that uses SWTP protocol. +<br>"chat.superchat" - A chat service type owned by SuperChat +<br>"printer.samba" - A samba printer service type +<br>"ftp" - An IANA ftp service type +<br>"telnet" - An IANA telnet service type +<h4> +Comparing Service Types</h4> +Since service types are an important in determining the urls that are return +by the <tt><a href="SLPFindSrvs.html">SLPFindSrvs()</a></tt> call you should +understand how OpenSLP compares services. Suppose that three services +were registered with <tt><a href="SLPReg.html">SLPReg()</a></tt> using +a <tt>srvtype</tt> of "printer:lpr", "printer" and "printer.acme". +If a client program calls <tt><a href="SLPFindSrvs.html">SLPFindSrvs()</a></tt> +with a <tt>srvtype</tt> of "service:printer" the urls for both "printer:lpr" +and "printer" are returned ("printer.acme" is not). However, if <tt><a href="SLPFindSrvs.html">SLPFindSrvs()</a></tt> +is called with <tt>srvtype </tt>of "printer:lpr" or "printer.acme" then +the urls for "printer:lpr" or "printer.acme" would be returned. In +other words, if a concrete type is used, only services with same abstract +and concrete type are returned. If only the abstract type is used +then all services of that abstract type (and naming authority) are returned. +<h4> +A word about naming authorities</h4> +It is our opinion that developers MUST use a naming authority if an IANA +service template has not been defined that fits the type of service that +is being supplied by their application. If developers use a predefined +IANA service template they must use it correctly. +<h3> +<a NAME="Service Url"></a>SLP Service Url Syntax</h3> +URL strings passed as parameters to<tt> <a href="SLPReg.html">SLPReg()</a></tt>, +<tt><a href="SLPDereg.html">SLPDeReg()</a></tt>, +<tt><a href="SLPDelAttrs.html">SLPDelAttrs()</a></tt>, +<tt><a href="SLPFindSrvs.html">SLPFindSrvs()</a></tt>, +<tt><a href="SLPParseSrvURL.html">SLPParseSrvURL()</a></tt> +functions and returned as a result to the <tt><a href="SLPSrvURLCallback.html">SLPSrvURLCallback()</a></tt> +callback function. SLP defines a special type of URL called a Service +URL that MUST be used when calling OpenSLP API functions. If you +decide to use Service URLs extensively, you should probably read <a href="rfc/rfc2609.txt">RFC +2609</a>, but if you just want to know what they look like, the following +explanation should be good enough: +<blockquote><b><tt>SLP Service URL = "service:"<service-type>"://"<addrspec></tt></b></blockquote> +The <tt>service-type</tt> is a service type as explained above. <tt>addrspec</tt> +can be just about anything you want that fits URL syntax ( +) and can be translated as a network location. The "<tt>service:</tt>" +and "<tt>://</tt>" strings are required. +<h4> +Service URL Examples</h4> +"service:weather.nasa:wtp://weather.nasa.com:12000" +<br>"service:weather.nasa:swtp://weather.nasa.com:12001" +<br>"service:chat.superchat://chat.superchat.com;auth=ldap" +<h4> +Do I have to use the SLP Service URL syntax for my urls?</h4> +Yes. With OpenSLP you are required to use Service URLs, API functions +will return SLP_PARSE_ERROR if you do not. The reason that OpenSLP +requires Service URLs is because the SLP API designers do not allow the +service-type to be passed in as a parameter to the SLPDeReg() call. +With out the service-type, SLPDeReg() does not allow the caller to distinguish +between services of varying types that were registered with the same standard +URL. +<br> +<h3> +<a NAME="LDAPv3 Filter"></a>LDAPv3 Search Filter Syntax</h3> +An LDAP Search Filter string is passed parameter to the <a href="SLPFindSrvs.html">SLPFindSrvs()</a> +function. If you want the definitive explanation of LDAP3 search +filters you can read <a href="../../rfc/rfc2254.txt">RFC 2254</a>, "String +Representation of LDAP Search Filters", or you can read the following definition +that should be good enough for most applications. +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/index.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/index.html new file mode 100644 index 00000000..88d98f2b --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/index.html @@ -0,0 +1,96 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - Index</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<table NOSAVE > +<tr VALIGN=CENTER NOSAVE> +<td NOSAVE> +<h1> +<img SRC="smalllogo.jpg" height=106 width=317></h1> +</td> + +<td NOSAVE> +<h1> +<hr WIDTH="100%"> +Programmers Guide +<hr WIDTH="100%"> +</h1> +</td> +</tr> +</table> + +<table BORDER CELLPADDING=5 COLS=2 WIDTH="100%" NOSAVE > +<tr VALIGN=TOP NOSAVE> +<td NOSAVE> +<h3> +SLP Handle Functions</h3> +Functions used to open and close SLPHandles: +<p><b><a href="SLPOpen.html">SLPOpen()</a></b> +<br><b><a href="SLPClose.html">SLPClose()</a></b></td> + +<td> +<h3> +Parsing Functions</h3> +Useful parsing functions: +<p><b><a href="SLPParseSrvURL.html">SLPParseSrvURL()</a></b> +<br><b><a href="SLPEscape.html">SLPEscape()</a></b> +<br><b><a href="SLPUnescape.html">SLPUnescape()</a></b> +<br><b><a href="SLPFree.html">SLPFree()</a></b></td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE> +<h3> +Service Registration Functions</h3> +Functions that should be called by applications that provide a service: +<p><b><a href="SLPReg.html">SLPReg()</a></b> +<br><b><a href="SLPDereg.html">SLPDereg()</a></b> +<br><b><a href="SLPDelAttrs.html">SLPDelAttrs()</a></b></td> + +<td> +<h3> +Configuration Functions</h3> +Functions that may be called to determine the configuration of the SLP +on the local machine and on the network: +<p><b><a href="SLPGetRefreshInterval.html">SLPGetRefreshInterval()</a></b> +<br><b><a href="SLPFindScopes.html">SLPFindScopes()</a></b> +<br><b><a href="SLPGetProperty.html">SLPGetProperty()</a></b> +<br><b><a href="SLPSetProperty.html">SLPSetProperty()</a></b></td> +</tr> + +<tr VALIGN=TOP NOSAVE> +<td NOSAVE> +<h3> +Service Location Functions</h3> +Functions that may be called by applications that use services: +<p><b><a href="SLPFindSrvs.html">SLPFindSrvs()</a></b> +<br><b><a href="SLPFindSrvTypes.html">SLPFindSrvTypes()</a></b> +<br><b><a href="SLPFindAttrs.html">SLPFindAttrs()</a></b></td> + +<td NOSAVE> +<h3> +Misc Information</h3> +Quick links to useful information: +<p><b><a href="Callbacks.html">Callbacks</a></b> +<br><b><a href="Syntax.html">Syntax</a></b> +<br><b><a href="SLPError.html">Error Codes</a></b> +<br><b><a href="Divergence.html">Divergence from RFC 2614</a></b></td> +</tr> +</table> + +<p><font size=-1>Prepared by <a href="http://www.calderasystems.com">Caldera +Systems, Inc</a></font> +<br> +<br> +<br> +<br> +<br> +<br> +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/openslp_security_whitepaper.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/openslp_security_whitepaper.html new file mode 100644 index 00000000..eddaa54c --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/openslp_security_whitepaper.html @@ -0,0 +1,338 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.76C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Programmers Guide - Security Whitepaper</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h1> + +<hr WIDTH="100%"></h1> + +<h1> +OpenSLP and SLPv2 Authentication</h1> +February 6, 2001 +<p>Matthew Peterson <matt@caldera.com> +<p> +<hr WIDTH="100%"> +<h3> +Abstract</h3> +This document is summary of SLPv2 security discussions along with some +conclusions that suggest direction for future Caldera sponsored development +of the +<a href="www.openslp.org">OpenSLP</a> implementation of Service +Location Protocol. +<br> +<h3> +Introduction</h3> +Early in December 2000, it was suggested that OpenSLP be submitted for +security review by noted security expert Olaf Kirch. Olaf offered +some very useful feedback including a suggestion to implement optional +SLPv2 authentication as specified by <a href="http://www.openslp.org/doc/rfc/rfc2608.txt">RFC +2608 section 9.2.</a> Olaf was worried that in the absence +of SLPv2 authentication, users of OpenSLP might unknowingly trust +malicious services that have been setup to "masquerade" as legitimate services. +In Olaf's estimation leaving out SLP authentication opens a security hole +that is not acceptable. With respect to <i>Volution</i>'s use +of SLP to locate services Olaf wrote the following: +<blockquote><tt>"Not authenticating registration and deregistration requests +is clearly inacceptable in an environment where there's a non-zero security +awareness. If everyone is able to change the LDAP server Volution uses +to obtain its information from, then we might as well replace /bin/login +with a symlink to /bin/bash" -- Olaf Kirch</tt></blockquote> +The initial response to Olaf's security review was one of complete compliance. +Code changes were quickly made for the next release of OpenSLP (ver 0.8.1) +to resolve all security issues <i>except</i> implementation of SLPv2 authentication +which was expected to be an involved change that would take several days +to complete. After a couple days of research, it became +obvious that the addition of SLPv2 security would be much more complex +than simply writing several hundred lines of security enabling code. +The final conflict eventually boiled down to a fundamental security / usability +tradeoff that would be unresolvable even with a perfect implementation. +<br> +<h3> +Objective of SLP</h3> +SLP can be thought of as a very simple global service registry (or directory). +Software entities that provide services register with SLP so that software +entities that want to use a services can locate them. +SLP offers a very simple mapping of service types (or characteristics) +to service URLs. This means that only the <i>type or characteristics</i> +of a service need to be known in order for a user or application to locate +a service for use. The major feature SLP provides +is usability. Basically, SLP allows application developers +to write more usable and manageable software. With SLP users +no longer need to memorize network addresses, host names or other information +to configure their client applications and administrators do not have to +set up elaborate means to supply this information. +<p>In discussing security problems associated with SLP it is important +to note two things from <a href="http://www.openslp.org/doc/rfc/rfc2608.txt">section +1 of RFC 2608</a>: +<ul> +<li> +SLP is designed for enterprise networks not as a solution for the global +Internet</li> + +<li> +The goal of SLP is to provide a framework that allows developers to write +software that is user friendly and easily managed.</li> +</ul> + +<h3> +SLP Security</h3> +Imagine now that in an enterprise environment there is a malicious or overly +curious individual that would like to obtain confidential information. +SLP could be exploited to obtain information from software that was otherwise +secured by virtue of manual configuration. For example, +an OpenSource help desk application consisting of "server" and "client" +software is SLP enabled because the network administrators got tired of +helping employees set up the "client" software with location and configuration +information used to connect with the "server" software. +<p>Since the source code is readily available, a sneaky employee makes +a few modifications to the server code that allows him to obtain user names +and passwords. He recompiles the source and brings up the "rogue" +help desk server. Since the "rogue" help desk server and the real +help desk server both have similar SLP registerations, it is possible that +clients may connect to the "rogue" server instead of the real one. +When the users log in, the "rogue" server saves off a copies of user names +and passwords. The malicious employee can use these user names and +passwords later to impersonate other people. +<p>In order to prevent this type of attack, SLP is designed so that services +registrations and requests can be made with authentication information. +When properly implemented, SLP requests can be issued that will only return +registrations made by trusted services. With SLP Security +enabled developers could trust that the service information returned by +the SLP API (URLs and configuration information). They do not +have to question (as much) whether the service at the other end of the +provided URL is a rogue because SLP can guarantee that services have been +"blessed" by administrators by virtue of key information. +<br> +<h3> +SLP Security vs SLP Usability</h3> +It is a well known fact that any increase in security inevitable reduces +usability for the legitimate user. This is especially true with +SLP security -- establishment of trust is unacceptable barrier to SLP usability. +The whole reason for using SLP in the first place is to allow "plug and +play" features to be built into applications! +<p>Due to the lack of PKI standards, establishing the trust needed to ensure +that service registrations can be authenticated would require manual distribution +of key material. One solution would be to have the administrator +verify the authenticity of a single SLP host key or certificate which would +authenticate all services provided from a given host, but this would not +prevent an attacker from masquerading services if they have access to the +authenticated machine. A more secure approach is to provide +per service or per user keys at the expense of increased manual intervention +to establish authenticity of numerous keys or certificates. +Wait... even with SLP secured, there is still the possiblity of DNS, DHCP +or ARP spoofing, so you are still not secure. +<p>After a few minutes of meditation it becomes evident that in order to +be totally safe, applications need to establish the security of their own +end to end communications. Two very good examples are PGP and SSH. +Neither application makes any assumptions about the reliability of intermediate +protocols. Everything is suspect from DNS to ARP. Suppose +that a specialized application was written that used PGP encrypted messages +to communicate. SLP is chosen to locate remote users of the +same application. Now, assume that none of the SLP security +features are implemented, is the application at risk? The answer +is no because care was taken by the application developer to secure his +own end to end communication. +<br> +<h3> +IETF Workgroup (srvloc) Discussion</h3> +The idea that authentication belongs in the application itself and not +in the location protocol (or other intermediate protocols) was brought +up for discussion on the IETF Service Location workgroup mailing list with +the following post entitled "Theoretical SLP security discussion (long)": +<blockquote><tt>SLPv2 is designed to be able to authenticate agents. In +other words, SLPV2 can guarantee that SAs and DAs are trustworthy. With +a proper SLPv2 implementation and installation, UAs can be sure that replies +to SLP requests come from trustworthy agents. There is no need to wonder +if a responding agent is representing malicious services. For example, +with SLPv2 authentication, I can request a service of type "service:ldap" +and implicitly trust that the service urls I receive in return are ldap +servers that are considered trustworthy by whoever set up the SLP installations.</tt> +<p><tt>Sounds pretty nice doesn't it -- at least until you start thinking +about what is required to deliver key information (certificates) that makes +trust relationships possible. I think I'm safe in saying that without exception, +no automated delivery of key information is secure unless it requires actual +validation by a human that results in some form of real-life action (phone +call, hand delivery, etc).</tt> +<p><tt>Administration of trust relationships are completely un-addressed +by the SLPv2 and SLP API specs -- which is probably why authentication +is considered an optional feature. One might even take the position that +SLPv2 Authentication invalidates the SLP's claim to reduce administrative +workload as there is no way to deploy secure SLP without significant (manual) +administrative overhead to establish certificate or key information trust.</tt> +<p><tt>In contemplating implementation and use of SLPv2 authentication +in OpenSLP we found that there is nearly nothing in the way of standardized +certificate delivery mechanisms that might actually make SLPv2 authentication +possible. We did find bits and pieces from OpenSSL and various signing +utilities, which lead us to start questioning why we were trying to authenticate +services via SLP anyway? Why not just let services authenticate themselves?</tt> +<p><tt>An analogy from real life... I need to call an associate and relay +some confidential information. I write down his number as it was left on +my voice mail and place the phone call. BEFORE I exchange sensitive information +the individual on the other line, I authenticate their identity (recognize +their voice, etc). Trusting the information available on my voice mail +is not required (as the number may have be to an airport pay phone). Implicitly +trusting a phone number from the white pages or any other source is not +required (or expected) as long as the callers can authenticate themselves.</tt> +<p><tt>Likewise, SLP delivered information need not be trusted to be useful. +As long as the entity providing a service and the entity using the service +can authenticate each other -- separate from the mechanism used to discover +or locate one another. One problem is that many services do not have authentication +capabilities -- which is not too much of a problem because most services +don't have SLP capabilities either. In the end, the only problem is that +developers are just beginning to write secure software. If secure service +and client software were indeed available, there would not be any need +for SLP authentication.</tt> +<p><tt>Having not heard additional comment from other experts, it is my +opinion the SLP need not bear the burden of authenticating services. The +burden of authentication should be placed on the services and their clients +rather than on a protocol valued for simplicity and ease of use, administration, +and deployment.</tt> +<p><tt>Please comment. Do you agree or disagree? Why?</tt> +<br> </blockquote> +Response from ebi@cup.hp.com: +<blockquote><tt>My take on this would be that it needs to be implemented +and the people deploying it should have the option of enabling/disabling +it.</tt> +<p><tt>Because if this is not implemented, I can see a potential denial +of service attack, where a rogue SA/DA, keeps on responding to all the +discovers sent by the UA. Even though the authentication might fail when +the application tries to authenticate using other means. It can stop the +UA from finding the correct SA/DA, there by creating a denial of service +attack.</tt> +<p><tt>On the other hand managing keys does make the protocol heavy weight. +The problem of effective key management issue, needs to be solved for most +other protocols (like DHCP) as well. Until then, we need</tt> +<br><tt>to be doing the key management manually or use what openSSL uses, +and when there is an optimum key management solution, we can integrate +into that.</tt></blockquote> + +<p><br>Rebuttal from mpeterson@caldera.com: +<blockquote><tt>I do not believe that the "denial of service" attack scenario +described above is much of an issue.</tt> +<p><tt>I think that it is worth clarifying that receiving incorrect information +(service URLs of rogue services from rogue DA/SAs) is not a problem that +involves the "SLP UA portion" of a client application. The problem you +describe above involves the portions of the client application that *use* +information delivered by SLP -- the "UA portion" is only in charge of *getting* +the information not using it. In other words, the problem you describe +above is an SLP usage problem not an SLP problem.</tt> +<p><tt>Regardless of whether or not SLPv2 authentication is implemented +and configured, client applications must not expect that SLP guarantees +availability. SLP could not possibly be expected to guarantee the state +of the network or the persistent state of the registered service. Suppose +that a service registers with SLP just before a WAN outage. At least for +a certain amount of time clients would experience the same "denial of service" +symptoms you describe above. The real solution is to encourage developers +to use the entire list of service URLs. If usage (connection to or authentication +to) one service fails, the client application should try the next.</tt> +<p><tt>Denial of service scenarios like the one you describe are impossible +to prevent. The only protection against denial of service attacks is fear. +Yes, security by fear. Remember, "SLP is intended to function within networks +under cooperative administrative control." The above mentioned attack +would be easy to detect, track and resolve; which means that it would not +probably not be much of a problem in the environments SLP is written to +run in (how many rogue DHCP servers do you see on your network).</tt> +<p><tt>In private network environments, the security problems that you +need to worry about are those that allow confidential data to be compromised +(especially if it can be done in ways can not be detected.) Denial of service +attacks to not compromise data.</tt> +<p><tt>The argument from my original post is that even if SLP authentication +was implemented and configured correctly with (magically) delivered certificates, +there would still be significant service specific security risks that would +be dangerous even in private networks. Upon close inspection SLP authentication +appears to solve only those security problems that are not overly relevant +to private networks in the first place. (Please, if I'm wrong here, give +me some examples...)</tt> +<p><tt>I agree fully that SLP without authentication is in the same realm +(security wise) as DHCP. My question remains -- Is this really a problem +in private networks? If so, why? DHCP continues to be a widely deployed +and extremely useful technology. One of the most useful aspects of DHCP +(and SLP) is that there is no need for extensive configuration. Add requirements +for establishing trust (certificates, keys, etc.) and the "plug and play" +features of DHCP and SLP are gone. As this is a "theoretical discussion" +I might mention that security is not free. There is always a usability +vs. security trade off. I might also mention that sometimes *lack of* security +is a feature if the goal is usability.</tt></blockquote> + +<p><br>Response from ebi@cup.hp.com: +<blockquote><tt>Let me give you another example. If I have a workstation +on the shared lan where my manager's PC is also there. Some companies restrict +root access to people on the main network. So I cannot sniff around to +find password. If there is no security in SLP, then I can register +one of the test machines, which would be in a different network (for which +I have the root access to) as the pop server. Then I get the user name +and password of my manager's pop account (The same thing can be done for +a print spooler or a file server).</tt></blockquote> +Rebuttal from mpeterson@caldera.com: +<blockquote><tt>Again, Don't you think this is more an illustration of +the weakness of POP3 protocol and mail server/client software than it is +of SLP? I would argue that its is that POP3 needs the security boost -- +after all it is in the business of securing an end to end communication. +SLP is not designed to solve the end-to-end authentication problem ... +or is it?</tt> +<p><tt>On the other hand, you do allude to a very valid point -- that most +traditional and widely deployed "end-to-end" service specific protocols +and software are not capable of secure service authentication. (It is usually +possible authenticate the user, but client software can rarely authenticate +the server which means that there is no establishment of trust before sending +client side user credentials.)</tt> +<p><tt>Should SLP be tasked with solving this problem? The answer is definitely +YES if it can be done without completely squashing major SLP usability +features ("plug and play" features). I guess I just don't see how this +can be done.</tt></blockquote> + +<p><br>The discussion eventually involves several engineers from a number +of organizations and becomes quite lengthy. At least, the exchange +included above should give a taste of the arguments involved. For +those that are interested in reading the entire thread, it can be found +at <a href="http://www.srvloc.org/hypermail/0826.html">http://www.srvloc.org/hypermail/0826.html</a> +<br> +<h3> +Conclusions</h3> +For those that are not willing to endure the tedium of reading the entire +mailing list discussion, the conclusion was eventually made (at least +by the author) that though SLP authentication may be appropriate +in some specialized SLP deployments, it is probably not beneficial in normal +network computer environments. This conclusion is based +on the following premises: +<ul> +<li> +Implementation of SLP authentication in the absence of public key infrastructure +standards would require enough manual configuration to invalidate all claims +SLP has to increased usability.</li> + +<li> +Common helper protocols DNS, DHCP, IP, even ARP are currently insecure +for usability reasons. SLP fits into this category of protocols +where lack of security may be considered a feature when it allows for maximal +usability.</li> + +<li> +Given the lack of security in the above mentioned (and other) protocols +self-established authentication of end to end communication is required +anyway for secure communication of network software entities.</li> + +<li> +In the presence of appropriate end to end security mechanisms, SLP +related security attacks are limited to the realm of "denial of service" +or "disruptions" -- even when <i>no</i> authentication is implemented in +SLP. In other words there is not a risk of compromise of confidential +information that can be attributed to SLP as long as appropriate end to +end security is established.</li> +</ul> +So, for the OpenSLP project, there are not any plans to implement SLPv2 +security. (This may change in the future depending on the success +of ongoing PKI standardization efforts.) There are, however, +many things that could be done to reduce opportunities for "denial of service +attacks" or other malicious SLP related disruptions. These +will be addressed in future versions of OpenSLP. +Also, in order to inform developers about the importance of writing secure +applications, plans have been made to include an SLP Security HOWTO +as part of the OpenSLP Documentation. +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/smalllogo.jpg b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/smalllogo.jpg Binary files differnew file mode 100644 index 00000000..c7a03694 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/ProgrammersGuide/smalllogo.jpg diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/CommandLine.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/CommandLine.html new file mode 100644 index 00000000..d05e8204 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/CommandLine.html @@ -0,0 +1,41 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Users Guide - Command Line Options</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +Command Line Options</h2> + +<hr WIDTH="100%"> +<p>Currently the OpenSLP daemon (slpd) accepts several useful command line +options. +<br> +<h3> +Command Line</h3> +<tt>slpd [-d] [-c <i>configfile</i>] [-r <i>registrationfile</i>] [-l <i>logfile</i>] [-p +<i>pidfile</i>]</tt> +<h3> +Options</h3> +<tt>[-d]</tt> +<blockquote>Don't detach from the controlling tty.</blockquote> +<tt>[-c <i>configfile</i>]</tt> +<blockquote>Use <tt><i>configfile</i></tt> as the file slpd reads to obtain configuration +information, rather than the default, <tt>/etc/slp.conf</tt>. See <a href="SlpConf.html">Modifying +the slp.conf configuration file</a> for details.</blockquote> +<tt>[-r <i>registrationfile</i>]</tt> +<blockquote>Use <tt><i>registrationfile</i></tt> as the file that slpd reads to obtain static +registrations, rather than the default, <tt>/etc/slp.reg</tt>. See <a href="SlpReg.html">Creating +a registration file</a> for details.</blockquote> +<tt>[-l <i>logfile</i>]</tt> +<blockquote>Use <tt><i>logfile</i></tt> as the file that slpd reads to write log messages, rather than the default, <tt>/var/log/slpd.log</tt>.</blockquote> +<tt>[-p <i>pidfile</i>]</tt> +<blockquote>Use <tt><i>pidfile</i></tt> as the file that holds the slpd process id, rather than the default, <tt>/var/run/slpd.pid</tt>.</blockquote> + +<blockquote> </blockquote> + +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/FileLocations.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/FileLocations.html new file mode 100644 index 00000000..bb93e359 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/FileLocations.html @@ -0,0 +1,41 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Users Guide - What did you do to my machine?</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +What did you do to my machine?</h2> + +<hr WIDTH="100%"> +<p>Most system administrators, at least the good ones, want to know exactly +what is being done by installation scripts especially if the script was +executed with root privileges. The following is a list of file copies +and modifications that are made by the installation script: +<br> +<h3> +Daemon, Libraries and Config files</h3> +<tt><dist dir>/slpd/slpd +==> /usr/sbin/slpd</tt> +<br><tt><dist dir>/libslp/libslp.so ==> /usr/lib/libslp.so</tt> +<br><tt><dist dir>/libslp/libslp.a ==> /usr/lib/libslp.a</tt> +<br><tt><dist dir>/etc/slp.conf ==> +/etc/slp.conf</tt> +<br><tt><dist dir>/etc/slp.reg ==> +/etc/slp.reg</tt> +<br> +<h3> +Documentation</h3> +<tt><dist dir>/doc/* +==> /usr/doc/openslp-x.x.x (/usr/share/doc/openslp-doc for Debian + GNU/Linux) </tt> +<br> +<h3> +Tools, Utilities and Samples</h3> +None Yet +<br><tt></tt> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/Installation.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/Installation.html new file mode 100644 index 00000000..2a6b4bf4 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/Installation.html @@ -0,0 +1,213 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Users Guide - Installing OpenSLP on Linux</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +Installing OpenSLP on Linux</h2> + +<hr WIDTH="100%"> +<h3> +Installation</h3> +Installing the latest distribution of OpenSLP is easy. Pay attention +to the following steps and you should not have any problems. +<br> +<ul> +<li> +RPM Installation</li> + +<ul> +<li> +Download the latest RPM file from <a href="http://www.openslp.org">www.openslp.org</a>. +Select the appropriate distribution.</li> + +<li> +Become root (root is usually the only user that can install packages).</li> + +<li> +Install the package. This is typically done with:</li> + +<ul><tt>rpm -Uvh openslp-x.x.x.rpm</tt></ul> + +<li> +Make any configuration changes to the <tt>/etc/slp.conf</tt> file that +you think you need. (see <a href="SlpConf.html">Configuration</a> for details)</li> + +<li> +Set up static registrations in the <tt>/etc/slp.reg</tt> file if you need +them. (see <a href="SlpReg.html">Static Registrations</a> for details)</li> + +<li> +Start the OpenSLP daemon.</li> + +<ul><tt>/usr/sbin/slpd</tt></ul> +</ul> + +<li> +Tarball Installation</li> + +<ul> +<li> +Download the latest tarball(.tar.gz) file from <a href="http://www.openslp.org">www.openslp.org</a></li> + +<li> +Unzip and untar the file into an appropriate directory.</li> + +<ul><tt>tar -zxf openslp-x.x.x.tar.gz</tt></ul> + +<li> +Become root (root is usually the only user that can install daemons and +libraries).</li> + +<ul>su root</ul> + +<li> +Enter the extracted openslp directory build and install the OpenSLP binaries:</li> + +<ul><tt>./configure</tt></ul> + +<ul><tt>make</tt></ul> + +<ul><tt>make install</tt></ul> + +<li> +Make any configuration changes to the <tt>/etc/slp.conf</tt> file that +you think you need. (see <a href="SlpConf.html">Configuration</a> for details).</li> + +<li> +Set up static registrations in the <tt>/etc/slp.reg</tt> file if you need +them. (see <a href="SlpReg.html">Static Registrations</a> for details).</li> + +<li> +Start the OpenSLP daemon.</li> + +<ul><tt>/usr/sbin/slpd</tt></ul> +</ul> + +<li> +Make slpd start on boot:</li> + +<ul>You may want to make a few changes to your Linux initialization scripts +so that slpd will start when your machine is booted. Since it is +not always necessary to have slpd running, <b>you should probably read +about when (and why) the OpenSLP daemon has to run in the <a href="index.html">Advanced +Topics</a> section before deciding to changing your init scripts</b>.</ul> + +<li> +Remove the distribution directory from your system.</li> + +<ul>Unless you will be doing OpenSLP development work, you will probably +want to remove the distribution directory from your system after OpenSLP +is installed. The distribution directory is the one that was created +by the tar -zxf openslp-x.x.x.tar.gz command. During installation, +all of the important files were copied out of this directory to the appropriate +places on you machines file system so it can be deleted with out breaking +your installation of OpenSLP.</ul> + +<li> +Add multicast or broadcast routes if necessary.</li> + +<ul>Some operating systems (like Linux) require a route to be set so that +the host knows which interface should be used to send multicast and general +broadcast traffic. Most of the time, the default route will be sufficient. +<p><tt># route -n</tt> +<br><tt>Kernel IP routing table</tt> +<br><tt>Destination Gateway +Genmask Flags Metric Ref +Use Iface</tt> +<br><tt>192.168.100.2 0.0.0.0 +255.255.255.0 U 0 +0 0 eth0</tt> +<br><tt>127.0.0.0 0.0.0.0 +255.0.0.0 U +0 0 +0 lo</tt> +<br><tt>0.0.0.0 216.250.131.254 +0.0.0.0 UG +0 0 +0 eth</tt>0 +<p>With the routing table above all multicast and general broadcast will +be sent on eth0 (the 0.0.0.0 route is the default route.) +<p>If you do not have a default route or you have a multi-homed host, you +will have specify which interface should be used. The following +is an example of a routing table from a multihomed host: +<p><tt># route -n</tt> +<br><tt>Kernel IP routing table</tt> +<br><tt>Destination Gateway +Genmask Flags Metric Ref +Use Iface</tt> +<br><tt>192.168.131.0 0.0.0.0 +255.255.255.0 U 0 +0 0 eth1</tt> +<br><tt>216.250.131.0 0.0.0.0 +255.255.255.0 U 0 +0 0 eth0</tt> +<br><tt>127.0.0.0 0.0.0.0 +255.0.0.0 U +0 0 +0 lo</tt> +<br><tt>0.0.0.0 216.250.131.254 +0.0.0.0 UG +1 0 +0 eth0</tt> +<p>Notice the default route? This means that multicast traffic will +be sent to eth0. If I don't want multicast traffic to be sent +to eth0 I will need to add a special route. +<p><tt># route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1</tt> +<br><tt># route -n</tt> +<br><tt>Kernel IP routing table</tt> +<br><tt>Destination Gateway +Genmask Flags Metric Ref +Use Iface</tt> +<br><tt>192.168.131.0 0.0.0.0 +255.255.255.0 U 0 +0 0 eth1</tt> +<br><tt>216.250.131.0 0.0.0.0 +255.255.255.0 U 0 +0 0 eth0</tt> +<br><tt>127.0.0.0 0.0.0.0 +255.0.0.0 U +0 0 +0 lo</tt> +<br><tt>224.0.0.0 0.0.0.0 +240.0.0.0 U +0 0 +0 eth1</tt> +<br><tt>0.0.0.0 216.250.131.254 +0.0.0.0 UG +1 0 +0 eth0</tt> +<p>Now multicast will be sent on eth1 not eth0. +<p>To my knowledge, there is no way to send multicast traffic both +eth1 and eth0 (at least with Linux) without specialized routing software. +Some multihomed machines have NICs that are attached to the same network. +In this case, there is usually no need to send multicast on both NICs. +If you need specialized routing software take a look at <i>mrouted</i>. +<br> </ul> + +<li> +Testing to see if your installation of OpenSLP works.</li> + +<ul>The OpenSLP distribution contains a handy command line tool that allows +you to perform most SLP functions from the command line. The tool +is called <tt>slptool</tt> and is built and installed by the OpenSLP make +files. Look for SLP tool in /usr/bin, /usr/local/bin, or <openslp_source_dir>/slptool/. +After you have started slpd, you should be able to issue a query for SLP +service agents using the following command line. +<p><tt>$ slptool findsrvs service:service-agent</tt> +<p>The results of this command should be a list of the hosts that are running +slpd. This indicates that OpenSLP is successfully installed and working. +If you do not get any output, then OpenSLP is not installed correctly or +is not working. If this happens, please double check that you +followed build and installation instructions, and read the +<a href="http://www.openslp.org/doc/html/faq.html">FAQ</a>. +If this does not help, post to the <a href="mailto:openslp-users.lists.sourceforge.net">openslp-users</a> +mailing list with as much detail as you can provide.</ul> +</ul> + +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/Optimization.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/Optimization.html new file mode 100644 index 00000000..d38c1c0d --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/Optimization.html @@ -0,0 +1,30 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Users Guide - Tuning and Optimizing</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +Tuning and Optimizing OpenSLP</h2> + +<hr WIDTH="100%"> +<br> +<h3> +Reducing Processor and Memory Usage</h3> +<Put tips here> +<br> +<h3> +Reducing Multicast Traffic</h3> +<Put tips here> +<br> +<h3> +Speed Up Service Requests</h3> +<Put tips here> +<br> +<br> +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/Security.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/Security.html new file mode 100644 index 00000000..69e81fc3 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/Security.html @@ -0,0 +1,73 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.76C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP Users Guide - Security</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +Security</h2> + +<hr WIDTH="100%"> +<h3> +Protecting the daemon against attacks</h3> +The following measures have been taken to protect the OpenSLP daemon from +attacks: +<ul> +<li> +The OpenSLP daemon (slpd) must run as root initially in order to bind to +the well known SLP port. However, slpd will relinquish root privileges +and suid() to the daemon user (if it exists).</li> + +<li> +If slpd includes paranoid SLP message checking code . This slows +down the operation of slpd slightly but ensures that malformed or intentionally +malicious SLP messages will not cause segmentation faults in the daemon.</li> +</ul> + +<h3> +Protecting the integrity of service registrations</h3> +As of version 0.9.0, OpenSLP fully supports the SLPv2 message authentication +blocks to ensure that registrations can not be modified in transit and +that they are sent to and received from valid agents. When +properly installed and configured, OpenSLP will automatically provide this +level of security to all SLP enabled applications with out any need to +recompile or relink. Installation of secure OpenSLP is a little +involved... +<p>Currently, OpenSLP uses DSS signatures to ensure the authenticity and +integrity of certain SLP messages. In order to do this, administrators +need to: build a security enabled OpenSLP, provide (or generate) +a DSA public and private keys, and setup the /etc/slp.spi file. +The administrator also has to ensure that OpenSSL crypto libraries are +properly installed before secure OpenSLP will work. +<p>Step 1: Since we not sure how many installations will require +OpenSLP security so the security features are not currently built +in by default. To build a security into open slp OpenSLP you will +have to use --enable-security on the ./configure command line +<p>Step 2: Generate DSA public and private key files in PEM format +using the OpenSSL command line. I'll provide details on exactly +how this is done when I get more time in the mean time, you can figure +it out by reading the openssl man pages. +<p>Step 3: Copy the private DSA key PEM key file to very safe locations +on hosts that will be registering services. The public DSA key PEM +file goes on all hosts that will be registering services and on all hosts +that will be finding services. +<p>Step 4: Edit the /etc/slp.spi file to assign an SPI to the DSA keys. +Details on how to do this are documented in the comments of the slp.spi +file +<br> +<h3> +User Level Access Control</h3> +Plans have been made to provide a mechanism that will enforce user level +access control that will allow the administrator to specify the users or +groups that can register services with SLP. +<br> +<h3> +Help</h3> +If you find a security hole in OpenSLP, <i>please</i> bring it to +the attention of the <a href="mailto:matt@caldera.com">OpenSLP +maintainer</a>. Thanks. +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/SlpConf.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/SlpConf.html new file mode 100644 index 00000000..8fe1601d --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/SlpConf.html @@ -0,0 +1,130 @@ +<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + + <meta http-equiv="Content-Type" + content="text/html; charset=iso-8859-1"> + + <meta name="GENERATOR" + content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Users Guide - The slp.conf File</title> +</head> + <body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" + alink="#ff0000"> + +<h2> The slp.conf File</h2> + +<hr width="100%"> +<p>The slp.conf file contains configuration information that affects the operation +of the OpenSLP daemon (slpd) and any application that uses the OpenSLP library. +The master slp.conf file is located at <tt>/etc/slp.conf</tt>. There +is <a href="CommandLine.html">command line option</a> that forces slpd to +read a different configuration file, but the SLP library is hard coded to +read from <tt>/etc/slp.conf</tt> and can only be changed by re-compiling +the library. </p> +<p>The OpenSLP slp.conf file diverges <i>slightly</i> from the <a + href="../../rfc/rfc2614.txt">RFC 2614</a> specification for the slp configuration +file, so you should probably read <a + href="#Divergence%20from%20RFC%202614">Divergence from RFC 2614</a> even +if you are familiar with the RFC spec. <br> + </p> +<h3> File Syntax</h3> + The slp.conf file syntax is very simple. OpenSLP follows the syntax +specified in <a href="../../rfc/rfc2614.txt">RFC 2614</a> which is simply +a list of key/value pairs separated by newlines; comment lines begin with +a '#' or a ';'. A good example file is copied to <tt>/etc/slp.conf</tt> + with the OpenSLP distribution. Take a look at it or <a + href="../../rfc/rfc2614.txt">read the RFC if you need more details</a>. <br> + +<h3> Settings</h3> + The following is a list of settings that are supported by OpenSLP: +<p><b>net.slp.useScopes</b> </p> +<blockquote>This option is a comma delimited list of strings indicating the +only scopes a UA or SA is allowed when making requests or registering or +the scopes a DA must support. The default value is "DEFAULT".</blockquote> + +<p><b>net.slp.DAAddresses</b></p> + +<blockquote>Allows administrator to force UA and SA agents to use specific +DAs. If this setting is not used dynamic DA discovery will be used to +determine which DAs to use. Default is to use dynamic DA discovery.</blockquote> + <b>net.slp.isBroadcastOnly</b> +<blockquote>Force broadcasts to be used instead of multicast. This setting +is seldom necessary since OpenSLP will automatically use broadcast if multicast +is unavailable. Default is false.</blockquote> + <b>net.slp.passiveDADetection</b> +<blockquote>A boolean indicating whether passive DA detection should be used. +Default is true.</blockquote> + <b>net.slp.DAActiveDiscoveryInterval</b> +<blockquote>A 16 bit positive integer giving the number of seconds between +DA active discovery queries. Default is 900 seconds (15 minutes). +If the property is set to zero, active discovery is turned off. This +is useful when the DAs available are explicitly restricted to those obtained +from DHCP or the net.slp.DAAddresses property.</blockquote> + <b>net.slp.multicastTTL</b> +<blockquote>A positive integer that is less than or equal to 255. The +default is 255.</blockquote> + <b>net.slp.multicastMaximumWait</b> +<blockquote>An integer giving the maximum amount of time (in milliseconds) +to perform multicast requests. Default is 15000 ms or 15 secs.</blockquote> + <b>net.slp.unicastMaxi</b>mumWait +<blockquote>An integer giving the maximum amount of time (in milliseconds) +to perform unicast requests. Default is 15000 ms or 15 secs.</blockquote> + <b>net.slp.randomWaitBound</b> +<blockquote>An integer giving the maximum value for all random wait parameters. +Default is 1000 or 1 sec.</blockquote> + <b>net.slp.MTU</b> +<blockquote>A integer giving the network packet MTU in bytes. Default +is 1400 bytes.</blockquote> + <b>net.slp.interfaces</b> +<blockquote>A list of IP address of network interfaces on which the DA/SA +should listen for slp requests. By default, OpenSLP will use all interfaces.</blockquote> + <b>net.slp.securityEnabled</b> +<blockquote>Indicates whether all agents should use authentication blocks.</blockquote> + net.slp.locale +<blockquote>A RFC 1766 Language Tag [6] for the language locale. Setting +this property causes the property value to become the default locale for +SLP messages. Default is "en". This property is also used for +SA and DA configuration.</blockquote> + <b>net.slp.maxResults</b> +<blockquote>A 32 bit integer giving the maximum number of results to accumulate +and return for a synchronous request before the timeout, or the maximum number +of results to return through a callback if the request results are reported +asynchronously.</blockquote> + <b>net.slp.isDA </b> +<blockquote>A boolean indicating if the SLP server is to act as a DA. If false, +not run as a DA. Default is false.</blockquote> + <b>net.slp.DAHeartBeat</b> +<blockquote>A 32 bit integer giving the number of seconds for the DA heartbeat. +Default is 3 hours (10800 seconds). Ignored if net.slp.isDA is false.</blockquote> + net.slp.DAAttributes (currently ignored) +<blockquote>A comma-separated list of parenthesized attribute/value list pairs +that the DA must advertise in DAAdverts. The property must be in the +SLP attribute list wire format, including escapes for reserved characters. +[7]</blockquote> + +<h3> <a name="Divergance from RFC 2614"></a>Divergence from RFC 2614</h3> + OpenSLP does not support all of the settings that are specified by RFC 2614. +The reasons for not supporting some of the settings range from the implementors' +opinions that they are either not useful or very difficult to implement with +regard to their usefulness. The following is a list of options that +OpenSLP has no plans to support. +<p><b>net.slp.serializedRegURL</b> </p> +<blockquote>slpd accepts the [-r] command line parameter that specifies the +serialized registration file to use.</blockquote> + <b>net.slp.multicastTimeouts</b> +<blockquote>OpenSLP does not honor this parameter. Currently multicast +timeouts are generated internally based on the net.slp.multicastMaximumWait +parameter.</blockquote> + <b>net.slp.DADiscoveryTimeouts</b> +<blockquote>OpenSLP does not honor this parameter. Currently multicast +timeouts are generated internally based on the net.slp.multicastMaximumWait +parameter.</blockquote> + <b>net.slp.datagramTimeouts</b> +<blockquote>OpenSLP does not honor this parameter. Currently unicast +timeouts are generated internally based on the net.slp.unicastMaximumWait +parameter.</blockquote> + <br> + +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/SlpReg.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/SlpReg.html new file mode 100644 index 00000000..17d31f44 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/SlpReg.html @@ -0,0 +1,129 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP - Static Registration File</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +The Static Registration File</h2> + +<hr WIDTH="100%"> +<p>Often it will be very useful for OpenSLP users to be able to statically +register legacy services (applications that were not compiled to use the +SLP library). To accommodate this need <a href="../../rfc/rfc2614.txt">RFC +2614</a> specifies a syntax for a registration file that is read by the +OpenSLP daemon (slpd). All of the registrations from the registration +file are maintained by slpd and will remain registered as long as slpd +is alive. The default location for the registration can be changed +from <tt>/etc/slp.reg +</tt>to another location using the <a href="CommandLine.html">-r +command line option</a><tt>. slpd reads the slp.reg </tt>file on +startup and re-reads it when ever the SIGHUP signal is received. +<h3> +<tt>Syntax</tt></h3> +The registration file format is pretty easy to understand. It can +get complicated so if you have any questions after reading this please +consult <a href="../../rfc/rfc2614.txt">RFC 2614.</a> +Each registration consists of several lines with the following format: +<br> +<blockquote><b><tt>#comment</tt></b> +<br><b><tt>;comment</tt></b> +<br><b><tt>service-url,language-tag,lifetime,[service-type]<newline></tt></b> +<br><b><tt>"scopes="[scope-list]<newline></tt></b> +<br><b><tt>[attrid]"="val1<newline></tt></b> +<br><b><tt>[attrid]"="val1,val2,val3<newline></tt></b> +<br><b><tt><newline></tt></b></blockquote> + +<p><br><b><tt>service-url</tt></b> +<blockquote>(Required) The service-url which must follow the Service URL +syntax explained <a href="#Service URL Syntax">below</a>.</blockquote> +<b><tt>language-tag</tt></b> +<blockquote>(Required) The language-tag uses the (two character) language +tags as specified by <a href="../../rfc/rfc1766.txt">RFC +1766</a> ("en" "fr", "de", etc...)</blockquote> +<b><tt>lifetime</tt></b> +<blockquote>(Required) The lifetime of the registration in seconds. +Value must be between 0 and 65535. Use 65535 if you want the registration +to be maintained for the life of slpd.</blockquote> +<b><tt>service-type</tt></b> +<blockquote>(Optional) The type of service being registered. Ignored +by OpenSLP because service-url must conform to the SLP Service URL format.</blockquote> +<b><tt>scope-list</tt></b> +<blockquote>(Optional) List of comma delimited scopes to register the service +in. If omitted then service is registered in all scopes specified +by the <tt><a href="SlpConf.html">slp.conf</a></tt> +file.</blockquote> +<b><tt>attrs</tt></b> +<blockquote>(Optional) The attributes to register along with the service. +Any string but "scopes" or "SCOPES" can be used as an attrid. Note +that the '"' character has no real significance. Strings should not be +quoted!</blockquote> + +<h3> +Examples</h3> +Several examples of registration entries are provided below: +<br> +<blockquote><tt>#Register a OpenSLP testing service</tt> +<br><tt>service:test.openslp://192.168.100.1,en,65535</tt> +<br><tt>scopes=test1,test2</tt> +<br><tt>description=OpenSLP Testing Service</tt> +<br><tt>authors=mpeterson,jcarey</tt> +<p><tt>#Register ssh service</tt> +<br><tt>service:ssh.openslp://192.168.100.1,en,65535</tt> +<br><tt>#use default scopes</tt> +<br><tt>description=Secure Shell</tt> +<p><tt>#Register telnet service with no attributes</tt> +<br><tt>service:telnet.myorg://192.168.100.1,en,65535</tt> +<br><tt>#use default scopes</tt></blockquote> + +<h3> +<a NAME="Service URL Syntax"></a>Service URL Syntax</h3> +If you decide to use Service URLs extensively, you should probably +read <a href="../../rfc/rfc2609.txt">RFC 2609</a>, +but if you just want to know what they look like, the following explanation +should be good enough: +<blockquote><tt>service-url = "service:"<service-type>"://"<addrspec></tt></blockquote> +The service-type is a service type as explained <a href="#SLP Service Type Syntax">below</a>. +addrspec can be just about anything you want that fits URL syntax (see +<a href="../../rfc/rfc2396.txt">RFC 2396</a>) and can be translated as a network location. The "<tt>service:</tt>" +and "<tt>://</tt>" strings are required. + +<p><b>Service URL Examples</b> +<p><tt>service:weather.nasa:wtp://weather.nasa.com:12000</tt> +<br><tt>service:weather.nasa:swtp://weather.nasa.com:12001</tt> +<br><tt>service:chat.superchat://chat.superchat.com;auth=ldap</tt> +<br> +<h3> +<a NAME="SLP Service Type Syntax"></a>SLP Service Type Syntax</h3> +The official definition of Service Type strings can be found in +<a href="../../rfc/rfc2609.txt">RFC 2609</a>, +"Service Templates and Service Schemes". If you will be +working with "well known" (IANA) service types, you should read it. +If you are developing applications for "proprietary" services then you +will probably be satisfied with the following explanation: +<p> <tt>service-type = <abstract-type.naming-authority>":"<concrete-type></tt> +<p>The abstract-type is simple (hopefully short) descriptive string that +describes the type of service. The naming-authority is the name (hopefully +unique) name of the organization that named the service. The naming-authority +is optional, but if it is omitted then IANA is assumed to be the naming +authority and IANA requires service-types to be registered +(see <a href="../../rfc/rfc2609.txt">RFC 2609</a>). The +concrete-type is also optional. Think of a concrete-type +as a kind of sub-type of the abstract-type. For example, "printer" +is an abstract type (owned by IANA) and "printer:lpr" is a concrete type +(owned by IANA). +<p><b>Service Type Examples</b> +<p><tt>weather.nasa:wtp</tt> - A (fictitious) weather service type +owned by NASA that uses Weather Transfer protocol +<br>weather.nasa:swtp - A (fictitious) weather service type owned by NASA +that uses Simple Weather Transfer protocol. +<br><tt>chat.superchat</tt> - A chat service type owned by SuperChat +<br><tt>printer.samba</tt> - A samba printer service type +<br><tt>ftp</tt> - An IANA ftp service type +<br><tt>telnet</tt> - An IANA telnet service type +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/UserFAQ.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/UserFAQ.html new file mode 100644 index 00000000..68514749 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/UserFAQ.html @@ -0,0 +1,16 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Users Guide - User FAQ</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +OpenSLP User FAQ</h2> + +<hr WIDTH="100%"> +<p><Put faq here as it is generated on mailing lists and email> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/WhenToRunSlpd.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/WhenToRunSlpd.html new file mode 100644 index 00000000..c4e87719 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/WhenToRunSlpd.html @@ -0,0 +1,66 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Users Guide - When To Run slpd</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +When To Run slpd</h2> + +<hr WIDTH="100%"> +<p><tt>slpd</tt> provides SA (and possibly DA) functionality along with +the ability to maintain a consistent state with respect to the locations +of other SLP agents on the network. The SLP library (<tt>libslp.so</tt>) +provides UA functionality internally on a per process basis with out the +need to communicate with slpd. This means that in certain cases, the slp +daemon does not always have to be loaded on every machine. We're +not sure if this will be a valuable feature to a majority of users, but +at least it offers the additional flexibility to minimize the overhead for +SLP for those machines that will only need UA capabilities. (If you're +wondering about the meaning of DA, SA, and UA, you should probably read +<a href="../IntroductionToSLP/index.html">An +Introduction to SLP</a>). +<br> +<h3> +When is slpd needed?</h3> + +<ul> +<li> +slpd must be running on all machines that will be registering services. +In other words, slpd is required on all machines that run applications +that make calls to one of the following SLP APIs <tt>SLPReg()</tt>, +<tt>SLPDeReg()</tt>, +or <tt>SLPDelAttrs(). </tt><a href="../ProgrammersGuide/index.html">See +the OpenSLP Programmers Guide for details.</a></li> + +<li> +slpd is the process that maintains static registrations from the /etc/slp.reg +file. If you expect the registrations for this file to be available +to other machines, you must run slpd.</li> + +<li> +slpd is required for automatic DA and scope discovery to work correctly. +If you do not run slpd, then DAs and scopes can only be discovered via DHCP +or the <tt><a href="SlpConf.html">/etc/slp.conf</a></tt> file. (Note: Due +to a lack of a standard DHCP API DA discovery via DHCP is not yet supported).</li> +</ul> + +<h3> +When is slpd not needed?</h3> + +<ul> +<li> +slpd is not needed if a machine will only be requesting services. +In other words, slpd is not required on machines if a call will never +be made to <tt>SLPReg()</tt>, <tt>SLPDeReg()</tt>, or <tt>SLPDelAttrs().</tt></li> + +<li> +slpd is not needed on a machine if manual or DHCP DA or scope discovery +is sufficient.</li> +</ul> + +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/WhoShouldRead.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/WhoShouldRead.html new file mode 100644 index 00000000..e728b3a5 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/WhoShouldRead.html @@ -0,0 +1,28 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Users Guide - Who should read this guide</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<h2> +Who should read this guide</h2> + +<hr WIDTH="100%"> +<p>Often there are significant differences between the behavior of implementations +of standardized protocols. OpenSLP is no different. Every attempt +has been made to follow the specification from the IETF RFCs, but there +still may be subtle differences between OpenSLP and other SLP implementations. +To be informed, even experienced users of SLP should read this guide. +<p>Note: This guide deals with concepts that are <i>specific to using OpenSLP.</i> +If you are looking for an overview of the SLP protocol itself, you should +read "<a href="../IntroductionToSLP/index.html">An Introduction to SLP</a>" +or review the SLP RFCs (<a href="../../rfc/rfc2608.txt">2608</a>, <a href="../../rfc/rfc2609.txt">2609</a>, +<a href="../../rfc/rfc2614.txt">2614</a>). If you are a developer, +you should probably read the <a href="../ProgrammersGuide/index.html">OpenSLP +Programmers Guide.</a> +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/index.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/index.html new file mode 100644 index 00000000..79a51a8d --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/index.html @@ -0,0 +1,59 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]"> + <title>OpenSLP Users Guide</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> + +<table NOSAVE > +<tr VALIGN=CENTER NOSAVE> +<td NOSAVE> +<h1> +<img SRC="smalllogo.jpg" height=106 width=317></h1> +</td> + +<td NOSAVE> + +<h1> +<hr WIDTH="100%"> +Users Guide +<hr WIDTH="100%"> +</h1> +</td> +</tr> +</table> + +<h3> + +<hr WIDTH="100%"></h3> + +<h3> +Introduction</h3> +<b><a href="WhoShouldRead.html">Who should read this guide?</a></b> +<h3> +Installation</h3> +<b><a href="Installation.html">Installing OpenSLP on Linux</a></b> +<br><b><a href="FileLocations.html">What did you do to my machine?</a></b> +<h3> +Configuration</h3> +<b><a href="CommandLine.html">Command line options</a></b> +<br><b><a href="SlpConf.html">Modifying the slp.conf configuration file</a></b> +<br><b><a href="SlpReg.html">Creating a static registration file</a></b> +<h3> +Advanced Topics</h3> +<b><a href="WhenToRunSlpd.html">When to run slpd</a></b> +<br><b><a href="Optimization.html">Tuning and optimizing OpenSLP</a></b> +<br><b><a href="Security.html">Security</a></b> +<h3> +Frequently Asked Questions</h3> +<b><a href="UserFAQ.html">FAQ sorted by topic</a></b> +<p> +<hr WIDTH="100%"> +<br><font size=-2>Prepared by: <a href="http://www.calderasystems.com">Caldera +Systems Inc</a></font> +<br> +<br> +</body> +</html> diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/smalllogo.jpg b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/smalllogo.jpg Binary files differnew file mode 100644 index 00000000..c7a03694 --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/UsersGuide/smalllogo.jpg diff --git a/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/faq.html b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/faq.html new file mode 100644 index 00000000..348d8b8a --- /dev/null +++ b/debian/openslp-dfsg/openslp-dfsg-1.2.1/doc/html/faq.html @@ -0,0 +1,232 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> + <title>OpenSLP FAQ</title> +</head> +<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> + +<h2> +OpenSLP - Frequently Asked Questions</h2> + +<hr WIDTH="100%"> +<p><tt>A really compresensive FAQ is not yet available for OpenSLP so please +send</tt> +<br><tt>your questions to the OpenSLP mailing lists:</tt> +<p><tt> openslp-devel@lists.sourceforge.net</tt> +<br><tt> openslp-users@lists.sourceforge.net</tt> +<p><tt><b>Q:</b> Where is the configure script to build OpenSLP?</tt> +<br><tt><b>A:</b> Did you read section 3 of the README? You need +to run autogen.sh to</tt> +<br><tt> generate the configure script.</tt> +<p><tt><b>Q:</b> How do I build OpenSLP on Windows?</tt> +<br><tt><b>A:</b> The MSVC project files used by the developers who ported +OpenSLP to win32</tt> +<br><tt> available in the source directories. If you +do not use MSVC and you are a</tt> +<br><tt> Windows developer, then you will be used to trying +to get MSVC makes to</tt> +<br><tt> work with your tools</tt> +<p><tt><b>Q:</b> Will OpenSLP work on my operating system</tt> +<br><tt><b>A:</b> Yes, the OpenSLP code has proven to be very portable. +It currently works</tt> +<br><tt> many operating systems including: Linux, BSD, Solaris, +Tru64, HPUX, UnixWare,</tt> +<br><tt> OSR5, and Win32</tt> +<p><tt><b>Q:</b> I am having trouble discovering attributes using FindAttr() +and "slptool</tt> +<br><tt> findattrs". The functions seem to execute properly, +and the services URL's</tt> +<br><tt> can be discovered, but no attributes are returned. +I am registering</tt> +<br><tt> services in slp.reg files. I don't think it is my +syntax in the slp.reg</tt> +<br><tt> file, because the example registrations in that file +do not return</tt> +<br><tt> attributes either. Can anyone help?</tt> +<br><tt><b>A:</b> If you just want to use slptool to see if things are +working, you need to</tt> +<br><tt> do the following:</tt> +<p><tt> Contents of the slp.reg:</tt> +<br><tt> ------------------------</tt> +<br><tt> service:myservice1.x://myhost.caldera.com,en,65535</tt> +<br><tt> owner=Matt Peterson</tt> +<br><tt> email=mpeterson@caldera.com</tt> +<p><tt> service:myservice1.x://yourhost.yourdomain.com,en,65535</tt> +<br><tt> owner=Kim Jackson</tt> +<br><tt> email=bjackson@yourhost.yourdomain.com</tt> +<br> +<p><tt> IMPORTANT: Restart slpd and check the /var/log/slpd.log +to ensure that</tt> +<br><tt> there were no errors during parsing of the .reg file</tt> +<p><tt> Use slptool to find attributes</tt> +<br><tt> ------------------------------</tt> +<br><tt> $ slptool findsrvs service:myservice1.x</tt> +<br><tt> service:myservice1.x://myhost.caldera.com.com,65535</tt> +<br><tt> service:myservice1.x://yourhost.yourdomain.com,65535</tt> +<p><tt> $ slptool findattrs service:myservice1.x://myhost.mydomain.com</tt> +<br><tt> (owner=Matt Peterson),(email=mpeterson@caldera.com)</tt> +<p><tt> $ slptool findattrs service:myservice1.x://yourhost.caldera.com</tt> +<br><tt> (owner=Kim Jackson),(email=bjackson@yourhost.yourdomain.com)</tt> +<p><tt> Note that you need to supply the service-url as returned +by findsrvs</tt> +<p><tt><b>Q:</b> I have a multi-homed machine and OpenSLP is not working.</tt> +<br><tt><b>A:</b> Please read the updated installation guide</tt> +<br><tt> <a href="http://www.openslp.org/doc/html/UsersGuide/Installation.html">http://www.openslp.org/doc/html/UsersGuide/Installation.html.</a></tt> +<br><tt> There are special instructions for users of multi-homed +machines.</tt><tt></tt> +<p><tt><b>Q:</b> In our development lab, the multicast SLP requests work +just fine.</tt> +<br><tt> However, in our SVT lab, the multicasts requests never +work. We always</tt> +<br><tt> have to edit the slp.conf file and turn on broadcast. +Have any others seen</tt> +<br><tt> this? Do you recall what the solution was? +We have spent a great deal of</tt> +<br><tt> time trying to figure this one out without success.</tt> +<br><tt><b>A: </b>Yes, others have seen this behavior -- I know I have. +I should put this in</tt> +<br><tt> the FAQ because I get a lot of questions. The +following is a list of the</tt> +<br><tt> most common problems along with trouble shooting and +resolution info:</tt><tt></tt> +<p><tt> No multicast route</tt> +<br><tt> -------------------</tt> +<br><tt> A very common problem with some OS installations (especially +Linux) is</tt> +<br><tt> that there is no multicast or default route set up. +On systems with BSD</tt> +<br><tt> derived TCP/IP stacks (nearly all OSes), broadcast +and multicast traffic</tt> +<br><tt> are delivered using the unicast routing table. +If the unicast routing</tt> +<br><tt> table does not have either a default route or an explicit +multicast route,</tt> +<br><tt> then the kernel does not know where to send the SLP +datagram and returns</tt> +<br><tt> an error 101 - network unreachable error which translates +into a SLPError</tt> +<br><tt> -23 SLP_NETWORK_ERROR. A quick test is to try to ping +SLP multicast:</tt><tt></tt> +<p><tt> $ ping 239.255.255.253</tt><tt></tt> +<p><tt> If ping returns an error that the network was unreachable, +you will need</tt> +<br><tt> to set up a default route or a multicast route.</tt> +<br><tt> </tt> +<br><tt> Note you may not get any responses to the ping. +This may not indicate</tt> +<br><tt> a problem. The only thing to be concerned about +is if there is an error</tt> +<br><tt> actually sending the ping.</tt> +<br><tt> </tt> +<br><tt> Please read the installation instructions for more +information on how</tt> +<br><tt> to install a multicast route:</tt><tt></tt> +<p><tt> http://www.openslp.org/doc/html/UsersGuide/Installation.html</tt><tt></tt> +<p><tt> </tt> +<br><tt> The "smart switch /stupid router" problem</tt> +<br><tt> ------------------------------------------</tt> +<br><tt> The smart switch / stupid router (or no router) problem +is something that</tt> +<br><tt> happens on switched ethernet networks only. +If you do not have a</tt> +<br><tt> switched ethernet network, then you do not have this +problem. If you do</tt> +<br><tt> have a switched ethernet network, then you may have +this problem if you</tt> +<br><tt> are using newer switching hardware. The reason +is that ethernet</tt> +<br><tt> switching hardware is smart enough to monitor IGMP +traffic and only</tt> +<br><tt> forward multicast ethernet frames to those ports that +are connected to a</tt> +<br><tt> host that has maintained the appropriate IGMP conversations +with the</tt> +<br><tt> router.</tt><tt></tt> +<p><tt> At a very high level, IGMP works like this. First, +the host joins the</tt> +<br><tt> multicast group by sending the router an IGMP message. +The router</tt> +<br><tt> responds periodically with request to the host to +see if the host is</tt> +<br><tt> still interested in multicast traffic. Since +IGMP conversations are</tt> +<br><tt> handled transparently by the kernel level IP stack +implementations, most</tt> +<br><tt> developers and users do not even realize anything +is happening.</tt><tt></tt> +<p><tt> However, "smart" ethernet switches do realize something +is happening!</tt> +<br><tt> If they do not see the IGMP messages being sent from +the router to a host</tt> +<br><tt> that is plugged into a given port of the switch, then +they will will not</tt> +<br><tt> forward multicast ethernet frames to that port. +This is good and bad.</tt> +<br><tt> It is good because it makes multicast extremely efficient +in terms of</tt> +<br><tt> physical network usage. However, it also makes +it so multicast will not</tt> +<br><tt> work at all if a router does not exist (or does not +support IGMP) to</tt> +<br><tt> maintain it's end of the IGMP conversation.</tt><tt></tt> +<p><tt> Trouble Shooting:</tt><tt></tt> +<p><tt> Monitor IGMP traffic! Make sure that periodic +IGMP traffic is happening</tt> +<br><tt> on your network. IGMP traffic can be monitored +on Linux (and many other</tt> +<br><tt> OSes) with the following command:</tt> +<br><tt> </tt> +<br><tt> # tcpdump igmp</tt><tt></tt> +<p><tt> Issue this command before starting slpd. You +will notice that several</tt> +<br><tt> IGMP "report" messages are sent. The important +thing to look for a IGMP</tt> +<br><tt> "query" message from the router. If you do not +see the IGMP query</tt> +<br><tt> message from the router then you will soon find that +you will no longer</tt> +<br><tt> see any "report" messages either.</tt><tt></tt> +<p><tt> Another good test is to try to ping the multicast address +and see where</tt> +<br><tt> it is visable.</tt> +<br><tt> </tt> +<br><tt> $ ping 239.255.255.253</tt><tt></tt> +<p><tt> Finally, the best advice is to read the normally untouched +section of</tt> +<br><tt> your ethernet switch manual that describes how the +switch handles</tt> +<br><tt> multicast. Stupid/inexpensive switches treat +multicast frames exactly</tt> +<br><tt> like broadcast frames which means that they are forwarded +to every port</tt> +<br><tt> of the switch. Smart/Expensive switches often +allow this behavior to be</tt> +<br><tt> configured. If you are on a network without +a router, then it is</tt> +<br><tt> possible that you might need to "dumb down" your switch.</tt><tt></tt> +<p><tt> Broken NIC driver</tt> +<br><tt> ------------------</tt> +<br><tt> Some NICs do not support multicast operation, so the +driver does the</tt> +<br><tt> work by placing the NIC into permiscuous mode +(accept everything) then</tt> +<br><tt> the driver filters out what is not needed. The +problem with this is</tt> +<br><tt> that sometimes on a very busy ethernet, the NIC buffers +may not be able</tt> +<br><tt> to keep up with all the traffic and some frames will +be dropped. This</tt> +<br><tt> is normally not a problem since SLP is designed to +work on unreliable</tt> +<br><tt> physical networks, but if enough frames are dropped, +OpenSLP may not</tt> +<br><tt> be able to find DAs or other services. This +would result in erratic</tt> +<br><tt> behavior.</tt> +<br><tt></tt> +<br><tt></tt> +<br> +</body> +</html> |
