Remoting Lifetime and Leases
Remoting implements a lease based lifetime management. There is no reference counting since doing so for remote objects is not trivial and for cases where networks can be faulty its bound to cause more issues. Thus clients need to make sure they keep a lease active on the serve else it might be disconnected unexpectedly. The server can use TrackingServices to simulate a ref counting style pattern by keeping track of when objects are being marshalled out. The client would also need to invoke a explicit Disconnect call to notify the server that its done with the reference. It is important to note however that leasing is also required for a x-appdomain case not just for a x-proc case. x-appdomain clients need to be aware that the server may have been disconnected and need to take appropriate care to make sure it does the appropriate leasing.
Managing Leases:
1. Infinite: Server can make sure it lives forever (forever meaning till the lifetime of the appdomain, once the appdomain is unloaded all remoting objects in it would be collected as well). This can be done by implementing InitializeLifetimeService and returning "null". Be very careful when doing this. This would mean all instances live for the lifetime of the appdomain, if the object is holding on to expensive resources there would be trouble. This is mostly useful in a case where there is a singleton object (like a class factory) which should be available always to serve requests.
2. Server manages its own lease: Server itself can register a sponsor and provide a ref counting mechanism as discussed above to manage its lease. This takes the burden of lease management off of the clients.
3. Client Sponsor: If there are potentially numerous clients and the server isnt in a position to track all of them, each client can register a sponsor(client sponsors should inherit from MBR) with the server. Note: to enable this the server should set typefilterlevel=full on its sinks else the register call will be rejected since passing MBR objects from the client to server isnt allowed, additionally the client would need to register a listening channel to get renewal callbacks from the server when the object lease is about to expire. Also another potential issue is that since the sponsor is a MBR as well, it has its lifetime as well and might need to be sponsored.
4. HeartBeat: the leasing system supports a renewOnCall feature which will bump up the lease of an object by n seconds (default is 2 minutes) each time a call is made to it. Thus if a client keeps "pinging" the server at regular intervals while it holds a reference to it the server lease will keep getting extended. This however could cause network overhead.
5. WKO: clients need not worry about leasing for wellknown objects. As the name suggests by definition server activated (or wellknown objects) will never expire. Though a particular singleton could be collected, a new one will be available if a new calls comes in. For singlecall objects there is a new object per call received.
So there are various ways you could manage leases. It is important to be aware of object lifetime, especially in a x-appdomain scenario. Depending on your application needs you can choose the leasing method which is best fits your needs. More information on leases can be found on msdn.