.NET Remoting is one of several modern ways developers can implement distributed computing. It is especially useful for tightly-coupled, distributed computing on Windows platforms, and will eventually replace DCOM. (For non-Windows or hybrid platforms you can choose CORBA, Java RMI, and Web Services/SOAP.) What is .NET Remoting? How does it work? When is it the best solution for distributed computing?

.NET Remoting is provided by the Common Language Runtime (CLR)--the central run-time component of the Microsoft.NET platform. The CLR program runs .NET programs, much like the Java Virtual Machine does for Java programs. The CLR hosts "assemblies" (software programs and libraries) written in VB.NET, ASP.NET, C#, etc., and compiled to run on the CLR. CLR object libraries let programs allocate memory, handle mouse events, interface with the video display, and communicate over the Internet. Assemblies can connect over the network using the .NET communications standard called "Remoting."

Remoting makes distributed computing on Windows nearly transparent. To communicate with an object within an assembly on a remote system, the developer first instantiates locally a proxy interface to the remote assembly. Local code calls a method of the proxy; the .NET platform calls the corresponding method on the remote server and returns the results (see figure). The Remoting facility manages the details of object allocation, command invocation, data exchange, data typing, and garbage collection. Once communication has been established by the client, Remoting allows the server to invoke callbacks on the client. Using Remoting, .NET developers can maintain their focus on presentation, event handling, and business logic.

The TCP "channel" is the default substrate network protocol for .NET Remoting. The default TCP channel is fast but not secure--it is not encrypted; furthermore the Remoting server must be directly visible and have its ports open--ready for client access and communication. For easier travel through firewalls or for other reasons, implementers can choose the HTTP channel, or implement their own channels to replace these defaults. Proxies and channels make .NET Remoting easy to use.

Instead of the explicit deallocation of memory, the CLR recycles its memory allocations using garbage collection. Objects still in use are not collected, while apparent "garbage" is marked and deleted. While not problematic within a single CLR, a Remoting invocation must respect the client's allocation until the object is no longer needed. Therefore the Remoting server issues its objects a "lease" (initially 5 minutes; additionally 2 minutes) and checks these leases periodically to see which objects can be deleted. In comparison, the DCOM proxy sends repeated "ping" packets to ensure the server does not delete objects that it still needs; with leases, this "chatty" behavior is no longer necessary.

Servers can keep objects pre-allocated so that clients can "activate" them more efficiently. One pre-allocation strategy is "singleton"--when the server starts, it instantiates one object for all clients to use. Client proxies attach to the singleton, call its methods, and retrieve results. Of course, the singleton must manage its own critical sections. Another pre-allocation strategy is "single-call"--a client attaches to a pre-allocated, stateless, server object, calls one of its methods, and gets a result. Single call objects can be pre-allocated and pooled, waiting for clients to attach. Leases and allocations improve the efficiency of .NET Remoting.

.NET Remoting has some disadvantages. Remoting depends on a fast, reliable connection (developers must handle long delays and dropped connections as a special case). The default Remoting channels are not secure. Remoting has no inherent authentication method (no built-in passwords). Server firewall and ports must remain open for clients to access. Shared code must be available between client and server (server objects must share their interface definitions). The CLR must be running on both the client and server (homogeneous environment), and the client must instantiate communication.

When these disadvantages are not onerous, then .NET makes a good choice. Developers must otherwise consider using Web Services: stateless XML-over-HTTP transactions using SOAP. Slightly sacrificing transaction speed and development time, Web Services can function over slow or faulty connections, can be encrypted easily with SSL/https, and can allow communication between clients and servers in a heterogeneous computing environment.

Want to learn more? I enjoy Jesse Liberty's plain-spoken .NET explanations (several O'Reilly titles). You can also download a free CLR from Microsoft--it includes a command-line C# compiler--and try .NET Remoting yourself.