Provides the fundamental abstractions and standard implementation classes for Jini extensible remote invocation (Jini ERI).

Jini ERI is an implementation of the Java(TM) Remote Method Invocation (Java RMI) programming model that supports the following features:

- The remote object export model defined in the {@link net.jini.export} package
- The invocation constraint and remote method control model defined in the {@link net.jini.core.constraint} package
- The trust model defined in the {@link net.jini.security} package
- Customization of client-side and server-side remote invocation behavior in a variety of ways, including customization of the content and format of the data communicated for remote invocations and pre- and post-invocation processing
- Use of a variety of communication transports, including transports that are not connection-based and transports that are not IP-based
- Use of dynamic proxy classes for client-side proxies, so that build-time generation of stub classes is not required
- Optional use of distributed garbage collection
- Control of all customizable features per exported remote object

In addition, Jini ERI supports full Java RMI dynamic class loading semantics.

This package includes the standard class for exporting remote objects with Jini ERI, the interfaces that define the Jini ERI architectural elements, standard implementation classes for some of those interfaces, and a standard trust verifier class.

## Programming Model

In general, applications are not expected to program directly to Jini ERI APIs for exporting remote objects; instead, applications should program to the {@link net.jini.export.Exporter} interface, and exporters should normally be obtained from a {@link net.jini.config.Configuration}. The application developer should document the requirements that a given configurable exporter must satisfy, so that the application deployer can provide an exporter that meets those requirements. See the `net.jini.config` package documentation for examples of configurable exporting.

Server-side remote method authorization checks should generally be implemented by the exporter, not by the remote object implementation, so that the authorization policy can be customized by the application deployer.

Clients should program to the {@link net.jini.core.constraint.RemoteMethodControl} interface for setting invocation constraints on proxies and generally should not make assumptions about how proxies are implemented.

## Protocol Stack

The Jini ERI architecture has a protocol stack with three layers as shown in the following table, with interfaces representing the abstractions of each layer on the client side and the server side as shown:

Layer | Client-side abstractions | Server-side abstractions
--- | --- | ---
Invocation layer | {@link java.lang.reflect.InvocationHandler} | {@link net.jini.jeri.InvocationDispatcher}
Object identification layer | {@link net.jini.jeri.ObjectEndpoint} | {@link net.jini.jeri.RequestDispatcher}
Transport layer | {@link net.jini.jeri.Endpoint}, {@link net.jini.jeri.OutboundRequestIterator}, {@link net.jini.jeri.OutboundRequest} | {@link net.jini.jeri.ServerCapabilities}, {@link net.jini.jeri.ServerEndpoint}, {@link net.jini.jeri.InboundRequest}

The client-side and server-side implementations of each layer are chosen for a particular remote object as part of exporting the remote object. The design is intended to allow plugging in different implementations of one layer without affecting the implementations of the other layers.

The client side abstractions correspond to the structure of the client-side proxy for a remote object exported with Jini ERI, with the invocation layer implementation containing the object identification layer implementation and that, in turn, containing the transport layer implementation.

Which invocation constraints are supported for remote invocations to a particular remote object exported with Jini ERI is partially dependent on the particular implementations of these layers used for the remote object (most especially the transport layer implementation).

## Exporter

An `Exporter` exports a remote object and returns a proxy for making remote invocations on the exported remote object. The standard Jini ERI exporter class is {@link net.jini.jeri.BasicJeriExporter}, which is suitable for most applications. `BasicJeriExporter` by itself exports non-activatable remote objects; to export an activatable remote object with Jini ERI, an {@link net.jini.activation.ActivationExporter} can be used with a `BasicJeriExporter` as its underlying exporter.

A `BasicJeriExporter` is constructed with the information for controlling the client-side and server-side implementations of all layers of the Jini ERI protocol stack for the remote object to be exported:

- An {@link net.jini.jeri.InvocationLayerFactory}, which is used to produce the proxy (containing an invocation handler) for the client-side invocation layer and the `InvocationDispatcher` for the server-side invocation layer
- An object identifier (a {@link net.jini.id.Uuid}) and flags for enabling DGC and controlling virtual machine liveness, which are used to construct a {@link net.jini.jeri.BasicObjectEndpoint} for the client-side object identification layer and to configure the `RequestDispatcher` for the server-side object identification layer
- A `ServerEndpoint`, used for the server-side transport layer and used to produce the `Endpoint` for the client-side transport layer

`BasicJeriExporter` implies use of a particular implementation of the object identification layer: `BasicObjectEndpoint` as the `ObjectEndpoint` implementation on the client side and an internal `RequestDispatcher` implementation on the server side. The object identifier and flags of a `BasicJeriExporter` control features of this standard object identification layer implementation. The nature of the object identification layer is such that the need to use a different implementation should be rare. In order to use a different implementation of the object identification layer, a deployer needs to use a custom Jini ERI exporter class, which should support specifying an `InvocationLayerFactory` and `ServerEndpoint` for controlling the invocation and transport layer implementations.

For a given remote object exported with Jini ERI, the client-side and server-side counterparts at each layer of the protocol stack must be compatible in order for remote invocations to succeed. At the transport layer, obtaining the client-side `Endpoint` from the supplied server-side `ServerEndpoint` ensures compatibility. At the object identification layer, `BasicJeriExporter` always uses compatible `ObjectEndpoint` and `RequestDispatcher` implementations. At the invocation layer, the `InvocationLayerFactory` abstraction is used to facilitate generation of compatible `InvocationHandler` and `InvocationDispatcher` pairs.

The proxy returned by a `BasicJeriExporter` (a Jini ERI proxy) is an instance of a dynamic proxy class with the following typical structure:

- {@link java.lang.reflect.Proxy}
  - {@link java.lang.reflect.InvocationHandler}
    - {@link net.jini.jeri.BasicObjectEndpoint}
      - {@link net.jini.jeri.Endpoint}
      - object identifier ({@link net.jini.id.Uuid})
    - client {@link net.jini.core.constraint.MethodConstraints}
    - server {@link net.jini.core.constraint.MethodConstraints}

The proxy object is ultimately created by the `InvocationLayerFactory` supplied to the exporter. The proxy class typically implements all of the remote interfaces of the remote object's implementation class, plus `RemoteMethodControl` and any extra interfaces chosen by the factory. The server constraints in the invocation handler are set by the factory, which typically allows specifying them with a constructor argument. The client constraints are initially `null` and can be set using {@link net.jini.core.constraint.RemoteMethodControl#setConstraints RemoteMethodControl.setConstraints} on the proxy.

The `BasicObjectEndpoint` is constructed with the object identifier in the exporter and the `Endpoint`, which is obtained from the `ServerEndpoint` by invoking its {@link net.jini.jeri.ServerEndpoint#enumerateListenEndpoints enumerateListenEndpoints} method.

## Invocation Layer

The invocation layer deals with the concepts of methods, arguments, return values, and exceptions; marshalling and unmarshalling objects; and remote invocation semantics generally. The invocation layer drives the remote invocation process on the client side.

On the client side, when a remote method is invoked on a Jini ERI proxy, it reflectively dispatches the method invocation to the contained invocation handler. The invocation handler for a Jini ERI proxy typically performs the following steps to carry out its role in processing a remote call:

- Compute the complete, absolute constraints for the remote call by combining {@link net.jini.core.constraint.InvocationConstraints} for the invoked method from both the client and server {@link net.jini.core.constraint.MethodConstraints} and converting relative time constraints to absolute time constraints.
- Invoke the `ObjectEndpoint`'s {@link net.jini.jeri.ObjectEndpoint#newCall newCall} method, passing the computed constraints, to obtain an `OutboundRequestIterator` to use to make attempts to communicate the remote call.
- Obtain an `OutboundRequest` from the iterator to represent an attempt to communicate the remote call.
- Enforce the constraints that the `OutboundRequest` indicates must be implemented by the invocation layer.
- Create a marshal output stream (see {@link net.jini.io.MarshalOutputStream}) on top of the request output stream of the `OutboundRequest`.
- Marshal an encoding of which remote method is being invoked.
- Marshal the arguments.
- Invoke the `ObjectEndpoint`'s {@link net.jini.jeri.ObjectEndpoint#executeCall executeCall} method to execute the remote call and wait for the response.
- Create a marshal input stream (see {@link net.jini.io.MarshalInputStream}) on top of the response input stream of the `OutboundRequest`.
- Unmarshal the result of the remote call and return the return value or throw the exception as appropriate.
- If a communication failure occurs and the remote call can be safely retried without violating at most once semantics, then if the iterator's {@link net.jini.jeri.OutboundRequestIterator#hasNext hasNext} method returns `true`, obtain another `OutboundRequest` from the iterator and make another attempt to communicate the remote call.

On the server side, when the `RequestDispatcher` receives a remote call request for a particular remote object, it dispatches that request to the `InvocationDispatcher` that the remote object was exported with, passing the remote object, an `InboundRequest` for performing I/O on the request, and a collection of server context elements. An invocation dispatcher typically performs the following steps to carry out its role in processing a remote call:

- Create a marshal input stream on top of the request input stream of the `InboundRequest`.
- Unmarshal and decode which remote method is being invoked.
- Verify that the server constraints for that method are satisfied by the transport layer, and enforce the constraints that the `InboundRequest` indicates must be implemented by the invocation layer.
- Perform any authorization checks.
- Unmarshal the arguments.
- Reflectively invoke the method on the remote object implementation with those arguments.
- Create a marshal output stream on top of the response output stream of the `InboundRequest`.
- Marshal the return value or exception that resulted from invoking the method.

Authorization checks are made before any arguments are unmarshalled in order to avoid denial of service attacks that could be mounted using serialization mechanisms or dynamically loaded classes.

If the {@link net.jini.core.constraint.Integrity#YES Integrity.YES} constraint is being enforced for a remote call, the marshal input streams created on both sides enforce code integrity using {@link net.jini.security.Security#verifyCodebaseIntegrity Security.verifyCodebaseIntegrity}.

{@link net.jini.jeri.BasicInvocationHandler} and {@link net.jini.jeri.BasicInvocationDispatcher} are standard invocation handler and invocation dispatcher classes that are suitable for most applications. Both `BasicInvocationHandler` and `BasicInvocationDispatcher` are designed to be extensible so that subclasses can augment or replace how many of the above steps are performed. For example, a subclass could perform additional authorization checks based on the actual arguments; marshal or unmarshal data in an alternate context; perform pre- or post-processing on the arguments, return value, or exception; or cooperate with a corresponding subclass to marshal and unmarshal additional implicit data with a remote call.

As described above, the `InvocationLayerFactory` interface is an abstraction for an object that produces the client-side and server-side implementations of the invocation layer for a remote object at export time. An `InvocationLayerFactory` must produce compatible client-side and server-side invocation layer implementations. {@link net.jini.jeri.BasicILFactory} is a standard implementation of `InvocationLayerFactory` that produces a proxy with a `BasicInvocationHandler` and an invocation dispatcher that is a `BasicInvocationDispatcher`. A `BasicILFactory` is sufficient when no customizations of `BasicInvocationHandler` and `BasicInvocationDispatcher` are desired. Custom invocation handler and invocation dispatcher implementations (such as subclasses of `BasicInvocationHandler` and `BasicInvocationDispatcher`) can be used by passing a custom `InvocationLayerFactory` to the exporter. {@link net.jini.jeri.AbstractILFactory} is a convenience class for writing such custom `InvocationLayerFactory` implementations.

The authorization mechanism provided by `BasicInvocationDispatcher` uses the standard {@link java.security.Permission} model. A permission class can be specified to the `BasicILFactory` constructor and is passed to the `BasicInvocationDispatcher` constructor at export time. The permission class is typically a simple subclass of {@link net.jini.security.AccessPermission}. The invocation dispatcher constructs an instance of the specified permission class based on the remote method being invoked. For each incoming remote call, the client subject must be granted the permission for that remote method or the remote call will be refused.

## Object Identification Layer

The object identification layer identifies distinct remote objects that are exported to a given transport endpoint and implements behavior that is specific to individual exported remote objects (but not to the remote invocation semantics of those objects), such as distributed garbage collection.

Typically, an `ObjectEndpoint` contains an object identifier for the remote object as well as the `Endpoint` for communicating requests to the remote object, and a `RequestDispatcher` contains a table mapping object identifiers to exported remote objects.

On the client side, an `ObjectEndpoint` typically prepends the object identifier to the remote call request data for reading by the corresponding `RequestDispatcher`. The `executeCall` method typically reads from the beginning of the response an indication from the `RequestDispatcher` of whether or not the identified object was found, and if it was not, returns a {@link java.rmi.NoSuchObjectException} for the remote invocation to throw.

On the server side, when the transport layer receives a request, it dispatches that request to the `RequestDispatcher` for the communication endpoint that the request was received on, passing an `InboundRequest` for performing I/O on the request. The `RequestDispatcher` typically reads the object identifier from the beginning of the request data and looks for a remote object with that identifier in its table of exported objects. If such an object is found, the associated `InvocationDispatcher` is invoked with the remote object, the `InboundRequest`, and a server context collection populated by the `InboundRequest`. If no such object is found, an indication is written to the response output stream for reading by the corresponding `ObjectEndpoint`.

The invocation dispatcher is invoked inside an invocation of {@link net.jini.export.ServerContext#doWithServerContext ServerContext.doWithServerContext} with an unmodifiable view of the server context collection described above, so that the context is available to the remote object implementation.

`BasicJeriExporter` uses `BasicObjectEndpoint` instances for the client-side object identification layer implementation and instances of an internal `RequestDispatcher` class for the server-side object identification layer implementation. This object identification layer implementation supports distributed garbage collection, as described below.

## Transport Layer

The transport layer communicates requests and responses over the network. The transport layer drives the dispatching of remote call requests on the server side, and thus it controls the server-side threading model.

The transport layer provides abstractions for request/response-based communication, where a request and its corresponding response are each a binary sequence of bytes. While the transport communication is represented to higher layers as discrete requests and responses, connection-oriented communication will be a common implementation technique. The {@link net.jini.jeri.connection} package provides support for implementing connection-based transport layer providers.

An `OutboundRequest` represents a request being sent, providing an {@link java.io.OutputStream} for writing the request and an {@link java.io.InputStream} for reading the response. An `InboundRequest` represents a request being received, providing an `InputStream` for reading the request and an `OutputStream` for writing the response.

The `ServerEndpoint` interface is the server-side transport layer abstraction for one or more communication endpoints on the local host to listen for and receive requests on. The individual communication endpoints are represented as {@link net.jini.jeri.ServerEndpoint.ListenEndpoint ListenEndpoint} instances during an invocation of the {@link net.jini.jeri.ServerEndpoint#enumerateListenEndpoints ServerEndpoint.enumerateListenEndpoints} method. A `ServerEndpoint` contains the network location for receiving remote call requests. For example, a TCP-based `ServerEndpoint` typically contains the TCP port to bind to. A `ServerEndpoint` that supports authentication typically contains the {@link javax.security.auth.Subject} to use for server authentication. The subject is normally obtained from the current thread when the server endpoint is constructed.

The `Endpoint` interface is the client-side transport layer abstraction for a remote communication endpoint to sent requests to. An `Endpoint` contains the network location for the remote object. For example, a TCP-based `Endpoint` typically contains the remote host address and TCP port to connect to.

The `enumerateListenEndpoints` method is invoked on a `ServerEndpoint` by an exporter at export time to start or reuse listen operations on the communication endpoints represented by the `ServerEndpoint`. The exporter's {@link net.jini.jeri.ServerEndpoint.ListenContext ListenContext}, which is passed to `enumerateListenEndpoints`, starts new listen operations when necessary by passing a `RequestDispatcher` to the `ListenEndpoint` instances that are enumerated. The `enumerateListenEndpoints` invocation returns an `Endpoint` that corresponds to the listen operations started or chosen by the exporter, and that `Endpoint` is used in the Jini ERI proxy produced by the export. When a request is received for any active listen operation, an `InboundRequest` is created to communicate that request and is passed to the `RequestDispatcher` associated with the listen operation.

When the {@link net.jini.jeri.Endpoint#newRequest Endpoint.newRequest} method is invoked to send a new request, it returns an `OutboundRequestIterator`, which may be able to produce one or more `OutboundRequest` instances for attempting to send the request. `OutboundRequestIterator` is designed to allow an `Endpoint` implementation to offer multiple communication mechanism alternatives to try or to otherwise signal to higher layers that a request should be retried.

The {@link net.jini.jeri.tcp} package provides transport over TCP/IP. The {@link net.jini.jeri.http} package provides HTTP transport over TCP/IP, for use through firewalls. The {@link net.jini.jeri.ssl} package provides two TLS/SSL-based transports: TLS/SSL transport over TCP/IP, and HTTPS (HTTP over TLS/SSL) transport over TCP/IP, for use through firewalls. The {@link net.jini.jeri.kerberos} package provides Kerberos-based transport over TCP/IP.

## Invocation Constraints

As described above, a Jini ERI proxy is typically an instance of `RemoteMethodControl` and contains client and server `MethodConstraints` for controlling the `InvocationConstraints` that apply to each remote method. When a remote method is invoked on the proxy, the invocation handler combines the `InvocationConstraints` for that method from the client and the server `MethodConstraints` and converts relative time constraints to absolute time constraints, to form the `InvocationConstraints` to use for the remote call. If any of the requirements cannot be satisfied, the remote invocation throws an {@link net.jini.io.UnsupportedConstraintException}.

The server `MethodConstraints` are specified at export time, via the `InvocationLayerFactory` supplied to the exporter, and are stored in the invocation dispatcher on the server side and in the invocation handler on the client side. The `ServerCapabilities` interface represents the server-side transport layer implementation to the invocation dispatcher for the purpose of verifying, at export time, that the entire implementation of the protocol stack supports the server constraints that that remote object is being exported with. (Otherwise, constraint misconfigurations could go undetected on the server side.) `ServerEndpoint` extends `ServerCapabilities` so that an invocation dispatcher does not need to be programmed to the `ServerEndpoint` API explicitly. At export time, the `ServerEndpoint` is passed to the `InvocationLayerFactory` as a `ServerCapabilities`, and the `InvocationDispatcher` created by the factory invokes {@link net.jini.jeri.ServerCapabilities#checkConstraints ServerCapabilities.checkConstraints} with all possible `InvocationConstraints` in the server `MethodConstraints`.

The initial client `MethodConstraints` of a Jini ERI proxy, upon return from an exporter, are `null`. Client `MethodConstraints` can be set for a Jini ERI proxy by invoking `RemoteMethodControl.setConstraints` on the proxy to obtain a new copy of the proxy with the specified client `MethodConstraints`.

Most constraints are fully implemented by the transport layer, but there is limited support for constraints being implemented by higher layers. For any given constraint, there must be a clear delineation of which aspects (if any) must be implemented by the transport layer. Most of the constraints in the {@link net.jini.core.constraint} package must be fully implemented by the transport layer; the one exception is {@link net.jini.core.constraint.Integrity}, for which the transport layer is responsible for the data integrity aspect and the invocation layer is responsible for the code integrity aspect.

On both sides, the transport layer is first given the opportunity to implement the constraints in force for a given remote call. The transport layer returns to the invocation layer any constraints that must be at least partially implemented by higher layers: on the client side, as the return value of {@link net.jini.jeri.OutboundRequest#getUnfulfilledConstraints OutboundRequest.getUnfulfilledConstraints}, which is invoked by the invocation handler before marshalling the remote call, and on the server side, as the return value of {@link net.jini.jeri.InboundRequest#checkConstraints InboundRequest.checkConstraints}, which is invoked by the invocation dispatcher before unmarshalling the remote call.

## Proxy Trust

On the client side, secure proxies need to be trusted to correctly carry out remote calls. In order to verify that a proxy can be trusted, a client passes it to {@link net.jini.security.Security#verifyObjectTrust Security.verifyObjectTrust}, which uses locally configured {@link net.jini.security.TrustVerifier} instances to determine if the proxy and (in recursive trust verification operations) its constituent objects can be trusted.

{@link net.jini.jeri.BasicJeriTrustVerifier} can be used as a trust verifier for a Jini ERI proxy that uses `BasicInvocationHandler` and `BasicObjectEndpoint`, whose dynamic proxy class is defined by a locally trusted class loader, and whose server constraints and `Endpoint` are themselves trusted. {@link net.jini.constraint.ConstraintTrustVerifier} can be used as a trust verifier for instances of many standard constraint classes. The `Endpoint` needs to be trusted to correctly carry out communication with all of the constraints that it supports; {@link net.jini.jeri.ssl.SslTrustVerifier} can be used as a trust verifier for {@link net.jini.jeri.ssl.SslEndpoint} and {@link net.jini.jeri.ssl.HttpsEndpoint} instances, and {@link net.jini.jeri.kerberos.KerberosTrustVerifier} can be used as a trust verifier for {@link net.jini.jeri.kerberos.KerberosEndpoint} instances.

Typically, the dynamic proxy class for a Jini ERI proxy received from a remote party will be defined by a class loader that is not directly trusted by `BasicJeriTrustVerifier` (or any other local trust verifier), so the proxy cannot be trusted directly by clients. If a Jini ERI proxy satisfies all of `BasicJeriTrustVerifier`'s conditions for trust except the condition regarding its dynamic proxy class's loader, then (on the assumption that the parent of that loader will be locally trusted) {@link net.jini.security.proxytrust.ProxyTrustVerifier} can be used as a trust verifier for the proxy, with the proxy itself serving as the bootstrap proxy in `ProxyTrustVerifier`'s algorithm. In order to support this intention, {@link net.jini.jeri.ProxyTrustILFactory} can be used to cause the proxy to be an instance of {@link net.jini.security.proxytrust.ProxyTrust} (in addition to `RemoteMethodControl` and the remote object's remote interfaces) so that it qualifies as a bootstrap proxy, and then the remote object would implement {@link net.jini.security.proxytrust.ServerProxyTrust#getProxyVerifier ServerProxyTrust.getProxyVerifier} to return a verifier for the proxy.

If a Jini ERI proxy that could be trusted by clients (perhaps by `ProxyTrustVerifier` as described previously) is contained within a proxy that will not be trusted directly by clients, then `ProxyTrustVerifier` can be used as a trust verifier for the outer proxy, with the contained Jini ERI proxy serving as the bootstrap proxy. The outer proxy would need to be implemented to conform to the requirements of the algorithm specified by `ProxyTrustVerifier`, such as by having a `getProxyTrustIterator` method that returns an iterator that produces the Jini ERI proxy. `ProxyTrustILFactory` can be used to cause the Jini ERI proxy to be an instance of `ProxyTrust`, and then the remote object would implement `ServerProxyTrust.getProxyVerifier` to return a verifier for the outer proxy.

If a Jini ERI proxy contains custom component objects (such as a custom invocation handler or custom `Endpoint`) that will not be trusted directly by clients, then {@link net.jini.security.proxytrust.ProxyTrustExporter} can be used to combine that proxy with a trustable bootstrap proxy, such that the client can use `ProxyTrustVerifier` to verify that the aggregate proxy can be trusted. The remote object would then implement `ServerProxyTrust.getProxyVerifier` to return a verifier for the aggregate proxy. `ProxyTrustExporter` can be used similarly if a Jini ERI proxy containing custom component objects is contained within another proxy that will not be trusted directly by clients.

## Distributed Garbage Collection

`BasicJeriExporter` supports exporting remote objects that participate in distributed garbage collection (DGC).

DGC uses a two-stage reference counting algorithm to maintain referential integrity across virtual machines, for remote objects exported with DGC enabled:

- A client-side DGC implementation (called the DGC client) tracks the existence and reachability of live remote references (`BasicObjectEndpoint` instances that participate in DGC) for a `BasicObjectEndpoint` class in a given virtual machine. When the number of live remote references to a given remote object transitions from zero to greater than zero, a dirty call is sent to the server-side DGC implementation associated with the remote object, indicating that the remote object is referenced by the client. When the number transitions from greater than zero back to zero, a clean call is sent, indicating that the remote object is no longer referenced by the client.
- A server-side DGC implementation tracks the number of DGC clients that are known to have live remote references to an exported remote object (according to dirty and clean calls received). When that number is greater than zero, the implementation strongly references the exported remote object, preventing it from being garbage collected. When that number is zero, the implementation only weakly references the exported remote object, so that it can be garbage collected (if it is not otherwise strongly reachable locally). If the remote object is garbage collected, it becomes effectively unexported.

Because a reference counting algorithm is used, collection of unreachable cycles of remote references is not supported.

If a remote object that is an instance of {@link java.rmi.server.Unreferenced} is exported with DGC enabled, then whenever the number of DGC clients that are known to have live remote references to the remote object transitions from greater than zero to zero, the remote object's {@link java.rmi.server.Unreferenced#unreferenced unreferenced} method is invoked (before the server-side implementation's strong reference is dropped).

The referential integrity of the live remote references tracked by a given DGC client to a given server-side DGC implementation is leased for finite durations of time. The lease duration is chosen by the server-side implementation and conveyed in dirty call responses. The DGC client is responsible for renewing its lease with the server (with successive dirty calls) as long as it has live remote references for that server. If the server-side DGC implementation detects a lease expiration, it no longer considers the DGC client to have live remote references to any of its exported remote objects. This leasing model is designed to allow server-side cleanup and garbage collection in the event of client failure, at the expense of possible loss of referential integrity in the event of communication failure.

See the {@link net.jini.jeri.BasicObjectEndpoint} and {@link net.jini.jeri.BasicJeriExporter} specifications for more information about client-side and server-side DGC processing. @since 2.0 @version 3.0