This article has been excerpted from book "The Complete Visual C# Programmer's Guide" from the Authors of C# Corner.

Unexpected loss of remote connections has been a fact of life since the advent of network communications. Countless lines of code have been written to make endpoints aware of a dropped connection and to recover-either with a reconnection or a graceful shutdown.

DCOM uses a "ping" mechanism. The client pings the server at regular intervals. If the server doesn't receive notification from the client in a specified time, it determines the client has disconnected, for whatever reason, and is free to clean up resources held for the client. How does the .NET Remoting Framework handle a dropped connection?

In the client's application domain, the answer is easy. Once the remote connection disappears, a call on a method or property causes an exception to be thrown. Catch the exception and handle it in some prescribed manner. The exception may be a System.Net.WebException or a System.Runtime.Remoting.RemotingException.

What happens with client-activated remote objects on the server? How does the server detect that the client is no longer alive? The .NET Remoting solution is a form of lease management called Leasing Distributed Garbage Collector (LDGC). Leases implement the System.Runtime.Remoting.Lifetime.ILease interface, which contains three configurable properties:

The default lease values can be changed while the ILease.CurrentState is set to System.Runtime.Remoting.Lifetime.LeaseState.Initial. Once the object has been marshaled, the lease's current state is set to active. Any attempt to alter the properties, once the lease is active, will cause an exception to be thrown. When the lease expires, the CurrentLeaseState property is internally set to expired and the remote object will be "garbage collected" at some point.

Leases can be renewed in three ways:

The server can change the default leasing values on all remote objects by setting the properties on System.Runtime.Remoting.Lifetime.LifetimeServices. Individual remote objects can also set ILease properties by overriding MarshalByRefObject.InitializeLiftetimeService() as shown in Listing 25.6.

Listing 25.6: SimpleObject.cs


public
override object InitializeLifetimeService()
{
ILease lease = null;
lease = (ILease)base.InitializeLifetimeService();

if( lease != null)
{
lease.InitialLeaseTime = TimeSpan.FromSeconds(5);
lease.RenewOnCallTime = TimeSpan.FromSeconds(5);
lease.SponsorshipTimeout = TimeSpan.FromSeconds(5);
}
return( lease);
}


Leasing and lease management do not apply to server-activated SingleCall-mode remote objects. Remember that they are created and then offered up to the GC on every method call. Microsoft's

Introduction to .NET Remoting Framework, updated July 2001 in the MSDN library, states that server-activated "Singleton objects are also subject to lifetime management." This seems reasonable, and in fact, InitializeLifetimeService() is called in Singleton mode but not in SingleCall mode.

Leasing configuration, as with much in .NET Remoting, also can be accomplished using a configuration file, which we'll look at later in the coming articles.

Conclusion

Hope this article would have helped you in understanding Remote Object Lifetime. See other articles on the website on .NET and C#.

visual C-sharp.jpg The Complete Visual C# Programmer's Guide covers most of the major components that make up C# and the .net environment. The book is geared toward the intermediate programmer, but contains enough material to satisfy the advanced developer.