Subject: Re: SA daemon

From: James Kempf <[email-masked]>
Date: Tue, 8 May 2001 08:59:42 -0700 (PDT)

Sean,

I presume when you say that you tried to register with slptool and the
OpenSLP libraries on Solaris, you mean  that you were running slptool
with OpenSLP libraries on Solaris directly with the Solaris SLP daemon
running. 

The Solaris SLP daemon also centralizes DA discovery for the UA, so DA discovery 
is handled on the daemon and not in client processes. This allows the daemon to 
do passive discovery for UAs in addtion to SAs. In order for a UA client to 
obtain a list of DAs, it sends a SrvRqst to the daemon with a particular
service type and scope. The DAs are handled in the service store
on the SA daemon as an internal scope and type.

I suppose we could look into standardizing the intra-machine protocol if
there was enough interest, but without a major customer requesting the
change, it is unlikely that any change will be made in Solaris SLP at
this point.

		jak

>Date: Tue, 8 May 2001 11:28:49 -0400 (EDT)
>From: Sean Kelley <[email-masked]>
>To: [email-masked]
>Subject: SA daemon
>
>
>	Both the OpenSLP and the Sun SLP have a
>SA daemon process which runs on each machine. The
>local processes which desire to advertise services
>connect to the SA daemon and register services. 
>
>	I don't believe that the mechanism allowing
>the local processes to register with the SA daemon
>is specified in a RFC, but it appears to be implemented 
>in both the OpenSLP and Sun SLP through the SA daemon 
>supporting SvrReg, SvrDeReg, SvrAck on connections 
>from the local host. This is a logical approach since
>only one process can bind to the SRVLOC port.
>
>	My question is interoperability. I have
>tried using the 'slptool' which is in the OpenSLP 
>distribution to register services with the Sun
>SA daemon. The 'slptool' is compiled against the
>OpenSLP libraries. While the two connect, I
>receive an error -13 (SLP_INVALID_UPDATE). Should
>I hold out hope for the two implementations to
>interoperate? Are there plans to make the protocol 
>between local processes and SA daemons a standard?
>
>	Sincerely,
>
>	Sean
>	
>
>Sean M. Kelley                  Solers, Inc. 
>[email-masked]          1611 N. Kent St. Ste. 600
>[email-masked]               Arlington, VA 22209
>(703)526-0001                   #include <std_disclaimer.h>
>

---

From: Matt Peterson <[email-masked]>
Date: Tue, 08 May 2001 10:46:32 -0600

Hi,

> on the SA daemon as an internal scope and type.

This is nearly how OpenSLP works also.
 
> change, it is unlikely that any change will be made in Solaris SLP at

I have not looked at the Solaris SLP daemon, but it sounds like it uses
normal SLPv2 messages for "IPC".  Is this right?

OpenSLP also uses normal SLPv2 messages for "IPC" between slpd (the SLP
daemon) and process that are compiled against libslp.so.  "IPC" messages
are sent to port 427 of the loopback address which is being listened on
by slpd.

For registration libslp.so simply builds a SrvReg message and sends it
to port 427 of the loopback device and waits for the SrvAck.

OpenSLP's libslp.so should be completely compatible with any SA SLP
Daemon that listens on loopback port 427.  I'm surprised to see that the
-13 is returned.  It suggests that there is either a bug in OpenSLP's
libslp.so or Sun's daemon.

Sean, it looks like you have a couple options... Run OpenSLP's slpd on
Solaris (it is reported to work well),  or recompile slptool against the
Sun's libslp.so

-- 
Matthew Peterson
Sr. Software Engineer
Caldera Systems, Inc
[email-masked]