]> Threads LookupDiscovery threads LeaseRenewalManager threads 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. This is a simple class. The constructors perform some simple sanity checking on their parameters. The method getRegistrar() attempts a socket connection to the host on port 4160 for a period of 1 minute, after which it times out if no connection has been made. If it can connect, it reads an object from the socket and coerces it to a ServiceRegistrar which it returns. 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. ©right;