DJ.1. Introduction
Entities that wish to start participating in a distributed a system of Jini technology-enabled services and/or devices, known as a djinn, must first obtain references to one or more Jini lookup services. The protocols that govern the acquisition of these references are known as the discovery protocols. Once these references have been obtained, a number of steps must be taken for entities to start communicating usefully with services in a djinn; these steps are described by the join protocol.
DJ.1.1. Terminology
A host is a single hardware device that may be connected to one or more networks. An individual host may house one or more Java virtual machines [1] (JVM).
[1] *As used in this document, the terms “Java virtual machine” or “JVM” mean a virtual machine for the Java platform.
Throughout this document we make reference to a discovering entity, a joining entity, or simply an entity.
A discovering entity is simply one or more cooperating objects in the Java programming language on the same host that are about to start, or are in the process of, obtaining references to Jini lookup services.
A joining entity comprises one or more cooperating objects in the Java programming language on the same host that have just received a reference to the lookup service and are in the process of obtaining services from, and possibly exporting them to, a djinn.
An entity may be a discovering entity, a joining entity, or an entity that is already a member of a djinn; the intended meaning should be clear from the context.
A group is a logical name by which a group of djinns is identified.
Since all participants in a djinn are collections of one or more objects in the Java programming language, this document will not make a distinction between an entity that is a dedicated device using Jini technology or something running in a JVM that is hosted on a legacy system. Such distinctions will be made only when necessary.
DJ.1.2. Host Requirements
Hosts that wish to participate in a djinn must have the following properties:
A functioning JVM, with access to all packages needed to run software written to the Jini specifications
A properly configured network protocol stack
The properties required of the network protocol stack will vary depending on the network protocol(s) being used. Throughout this document we will assume that IP is being used, and highlight areas that might apply differently to other networking protocols.
DJ.1.2.1. Protocol Stack Requirements for IP Networks
Hosts that make use of IP for networking must have the following properties:
An IP address. IP addresses may be statically assigned to some hosts, but we expect that many hosts will have addresses assigned to them dynamically. Dynamic IP addresses are obtained by hosts through use of DHCP.
Support for unicast TCP and multicast UDP. The former is used by sub-systems using Jini technology such as Java Remote Method Invocation (RMI); both are used during discovery.
Provision of some mechanism (for example, a simple HTTP server) that facilitates the downloading of Java RMI stubs and other necessary code by remote parties. This mechanism does not have to be provided by the host itself, but the code must be made available by some cooperating party.
DJ.1.3. Protocol Overview
There are three related discovery protocols, each designed with different purposes:
The multicast request protocol is employed by entities that wish to discover nearby lookup services. This is the protocol used by services that are starting up and need to locate whatever djinns happen to be close. It can also be used to support browsing of local lookup services.
The multicast announcement protocol is provided to allow lookup services to advertise their existence. This protocol is useful in two situations. When a new lookup service is started, it might need to announce its availability to potential clients. Also, if a network failure occurs and clients lose track of a lookup service, this protocol can be used to make them aware of its availability after network service has been restored.
The unicast discovery protocol makes it possible for an entity to communicate with a specific lookup service. This is useful for dealing with non-local djinns and for using services in specific djinns over a long period of time.
The discovery protocols require support for multicast or restricted-scope broadcast, along with support for reliable unicast delivery, in the transport layer. The discovery protocols make use of the Java platform’s object serialization to exchange information in a platform-independent manner.
DJ.1.4. Discovery in Brief
This section provides a brief overview of the operation of the discovery protocols. For a detailed description suitable for use by implementors, see Section DJ.2 “The Discovery Protocols”.
DJ.1.4.1. Groups
A group is an arbitrary string that acts as a name. Each lookup service has a set of zero or more groups associated with it. Entities using the multicast request protocol specify a set of groups they want to communicate with, and lookup services advertise the groups they are associated with using the multicast announcement protocol. This allows for flexibility in configuring entities: instead of maintaining a set of URLs for specific lookup services to contact, and that need to be changed if any of these services moves, an entity can maintain a set of group names.
Although group names are arbitrary strings, it is recommended that DNS-style names (for example, “eng.sun.com”) be used to avoid name conflicts. One group name, represented by the empty string, is predefined as the public group. Unless otherwise configured, lookup services should default to being members of the public group, and discovering entities should attempt to find lookup services in the public group.
DJ.1.4.2. The Multicast Request Protocol
The multicast request protocol, shown in Figure AR.1.1, proceeds as follows:
The entity that wishes to discover a djinn establishes a TCP-based server that accepts references to the lookup service. This server is an instance of the multicast response service.
Lookup services listen for multicast requests for references to lookup services for the groups they manage. These listening entities are instances of the multicast request service. This is not an RMI-based service; the protocol is described in Section DJ.2 “The Discovery Protocols”.
The discovering entity performs a multicast that requests references to lookup services; it provides a set of groups in which it is interested, and enough information to allow listeners to connect to its multicast response server.
Each multicast request server that receives the multicast will, if it is a member of a group for which it receives a request, connect to the multicast response server described in the request, and use the unicast discovery protocol to pass an instance of the lookup service’s implementation of net.jini.core.lookup.ServiceRegistrar.
At this point, the discovering entity has one or more remote references to lookup services.
Figure DJ.1.1. The Multicast Request Protocol
DJ.1.4.3. The Multicast Announcement Protocol
The multicast announcement protocol follows these steps:
Interested entities on the network listen for multicast announcements of the existence of lookup services. If an announcement of interest arrives at such an entity, it uses the unicast discovery protocol to contact the given lookup service.
Lookup services prepare to take part in the unicast discovery protocol (see below) and send multicast announcements of their existence at regular intervals.
DJ.1.4.4. The Unicast Discovery Protocol
The unicast discovery protocol works as follows:
The lookup service listens for incoming connections and, when a connection is made by a client, decodes the request and, if the request is correct, responds with a marshalled object that implements the net.jini.core.lookup.ServiceRegistrar interface.
An entity that wishes to contact a particular lookup service uses known host and port information to establish a connection to that service. It sends a discovery request and listens for a marshalled object as above in response.