jSLP Modularity

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.

SA only configurations

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.

UA only configurations

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 ServiceLocationException.NOT_IMPLEMENTED.

Configurations without the SLPDaemon

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 ch.ethz.iks.slp.impl.SLPDaemonImpl 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.