Divergence from RFC 2614
OpenSLP Programmer's Guide » Misc. Information » Divergence from RFC 2614

SLP Service URLs are required

SLP Service URL syntax is required for all functions that accept URL strings. The following is a list of affected functions:

  • SLPReg
  • SLPDeReg
  • SLPDelAttrs
  • SLPFindAttrs
  • SLPParseSrvURL
  • SLPSrvURLCallback

The decision to require SLP Service URL syntax was made based on in part the following scenario:

Suppose that two calls were made to SLPReg with srvurl and srvtype of "192.168.100.2","http" and also "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 an attempt to standardize, OpenSLP expects valid Service URLS.

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.

Scopelist may be the empty string ("")

In the calls where a scope list is accepted as a parameter, RFC 2614 says that this parameter may not be the empty string or a NULL pointer value. 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.

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

This extension by no means mandates the use of NULL or empty scope strings. Programmers who want complete implementations of SLP applications may indeed use the API to acquire knowledge about existing scopes on the network, and then present a scoping choice (if more than one is available) to the user.

The SLPSetProperty is ignored

The SLPSetProperty and SLPGetProperty calls are impossible to 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 by the library and freed by the caller. The SLPSetProperty call would still access the data store in such a way that mutexes would be required to ensure that SLPSetProperty and SLPGetProperty were never using 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.

NULL and empty string are acceptable parameters

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 and 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 would do just as well. This is why the vast majority of C APIs use NULL, and not the empty string, to indicate an ignored parameter or default value.

Incremental registrations and de-registrations

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 bad idea. Without a doubt, it is best to instruct SLP developers to minimize whenever possible, the number of calls that ultimately generate SrvReg and SrvDereg messages. If dynamic data is to be represented, it is best to 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 them very often.

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 the OpenSLP API and agent implementations.

The work around for this behavior involves the following:

  • Design application usage of SLP such that SLP is not used to store great quantities of data
  • Design application usage of SLP such that SLP is not used to store dynamic data
  • If the need does arise to add or remove an attribute from an existing registration simply re-register the service with new attributes as a "fresh" registration.

Addition of a very simple attribute parsing function

The following function is included, without explicit documentation, with the OpenSLP library, and has proven to be very useful:

<>
/*=========================================================================*/

SLPEXP SLPError SLPAPI SLPParseAttrs(
       const char * pcAttrList,
       const char * pcAttrId,
       char **      ppcAttrVal );

/* Used to get individual attribute values from an attribute string that   */
/* is passed to the SLPAttrCallback                                        */
/*                                                                         */
/* pcAttrList (IN) A character buffer containing a comma separated, null   */
/*                terminated list of attribute id/value assignments, in    */
/*                SLP wire format; i.e. "(attr-id=attr-value-list)"        */
/*                                                                         */
/* pcAttrId (IN)   The string indicating which attribute value to return.  */
/*                MUST not be null.  MUST not be the empty string ("").    */
/*                                                                         */
/* ppcAttrVal (OUT) A pointer to a pointer to the buffer to receive        */
/*                 attribute value.  The memory should be freed by a call  */
/*                 to SLPFree() when no longer needed.                     */
/*                                                                         */
/* Returns: Returns SLP_PARSE_ERROR if an attribute of the specified id    */
/*          was not found otherwise SLP_OK                                 */
/*=========================================================================*/
</>

Some .conf properties are ignored

See the OpenSLP Users Guide for more details.