This chapter looks at internal structures of Jini. This is heavily based on the 1.0 implementation by Sun, and may not be valid for any future implementations either by Sun or other vendors.
Jini uses many threads in its internal workings. The knowledge of these is not important to using Jini, but some may find it valuable to know what is going on under the hood.
A multicast request is made by creating a new LookupDiscovery
object with a non-empty set of groups, or by calling setGroups().
This must broadcast the service, looking for service locators.
This is done using a thread of type Requestor.
This creates a MulticastSocket, sets its time-to-live
field and sends out a number (currently eight) of announcements
A class ResponseListener is used to handle replies.
This runs as its own thread. It listens on a socket for responses
and adds them to a list of service locators. If a new locator is
found, then it calls each DiscoveryListener.
(The implementation is slightly more complex due to timing issues -
see the source code.)
Both of these run as daemon threads. That means they run as background threads. A user thread is needed to keep the application alive: an application will terminate if there are only daemon threads alive.
A LeaseRenewalManager uses a thread of class
RenewThread. This thread looks after all
aspects of renewal.