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