jSLP can be used to build custom configurations for SLP peers. It is possible to use UA or SA functionalities only and leave out some classes to reduce the file footprint.
If the configuration has to support SA functionalities only, the
ch.ethz.iks.slp.impl.LocatorImpl class is not required. Since the core has only dynamic dependencies to this class,
it can be omitted without any further modifications. Calls of
ch.ethz.iks.slp.ServiceLocationManager.getLocator will throw a ServiceLocationException of type
ServiceLocationException.NOT_IMPLEMENTED. Depending on the setup, the
ch.ethz.iks.slp.impl.SLPDaemonImpl class is also not required, see section below.
Configurations that only serve as a SLP client can omit the
ch.ethz.iks.slp.impl.AdvertiserImpl class and the
ch.ethz.iks.slp.impl.SLPDaemon class without further
implications. Calls of
ch.ethz.iks.slp.ServiceLocationManager.getAdvertiser will throw a ServiceLocationException of type
jSLP is able to run on different VMs on the same machine. Every separated instance of jSLP checks, if a SLP daemon is running on port 427 on the machine. If this is
the case, no new instance of SLPDaemon is created. Therefore, if it can be assured that another process has already started a deamon, the class
does not have to be provided by subsequent instances on different VMs. The same applies for the situation where a OpenSLP slpd is running on the machine.
The daemon is required for SA functionalities only. It contains a service registry for the case where no DA of the designated scope is available within the network and answers requests that arrive by multicast. It should thus be assured that the instance running the daemon does not terminate prior to other existing SA-enabled instances running on different VMs.