.NET Remoting Architecture

The .NET remoting infrastructure is an abstract approach to interprocess communication. Much of the system functions without drawing attention to itself. For example, objects that can be passed by value, or copied, are automatically passed between applications in different application domains or on different computers. You only need to mark your custom classes as serializable to make this work.

The real strength of the remoting system, however, resides in its ability to enable communication between objects in different application domains or processes using different transportation protocols, serialization formats, object lifetime schemes, and modes of object creation. In addition, remoting makes it possible to intervene in almost any stage of the communication process, for any reason.

Whether you have implemented a number of distributed applications or are simply interested in moving components to other computers to increase the scalability of your program, it is easiest to understand the remoting system as a generic system of interprocess communication with some default implementations that easily handle most scenarios. The following discussion begins with the basics of interprocess communication using remoting.

Copies vs. References

Cross-process communication requires a server object whose functionality is provided to callers outside its process, a client that makes calls on the server object, and a transportation mechanism to ferry the calls from one end to the other. The addresses of server methods are logical and function properly in one process, but do not function in a different client process. To alleviate this problem, a client can call a server object by making a copy of the object in its entirety and moving it to the client process, where the copy's methods can be invoked directly.

Many objects, however, cannot or should not be copied and moved to some other process for execution. Extremely large objects with many methods can be poor choices for copying, or passing by value, to other processes. Usually, a client needs only the information returned by one or a few methods on the server object. Copying the entire server object, including what could be vast amounts of internal information or executable structures unrelated to the client's needs, would be a waste of bandwidth as well as of client memory and processing time. In addition, many objects expose public functionality, but require private data for internal execution. Copying these objects could enable unauthorized clients to examine internal data, creating the potential for security problems. Finally, some objects use data that cannot be copied in any understandable way. A FileInfo object, for example, contains a reference to an operating system file, which has a unique address in the server process's memory. You can copy this address, but it will never make sense in another process.

In these situations, the server process should pass to the client process a reference to the server object, rather than a copy of the object. Clients can use this reference to call the server object. These calls do not execute in the client process. Instead, the remoting system collects all information about the call and sends it to the server process, where it is interpreted, the correct server object is located, and the call made to the server object on the client object's behalf. The result of the call is then sent back to the client process to be returned to the client. Bandwidth is used for only the critical information — the call, call arguments, and any return values or exceptions.

Remoting Architecture Simplified

Using object references to communicate between server objects and clients is the heart of remoting. The remoting architecture, however, provides the programmer with an even simpler procedure. If you configure the client properly, you need only create a new instance of the remote object using new (or the instance creation function from your managed programming language). Your client receives a reference to the server object, and you can then call its methods as though the object were in your process rather than running on a separate computer. The remoting system uses proxy objects ** to create the impression that the server object is in the client's process. Proxies are stand-in objects that present themselves as some other object. When your client creates an instance of the remote type, the remoting infrastructure creates a proxy object that looks exactly like the remote type to your client. Your client calls a method on that proxy, and the remoting system receives the call, routes it to the server process, invokes the server object, and returns the return value to the client proxy, which returns the result to the client.

Remote calls must be conveyed in some way between the client and the server process. If you were building a remoting system yourself, you might start by learning network programming and a wide array of protocols and serialization format specifications. In the .NET remoting system, the combination of underlying technologies required to open a network connection and use a particular protocol to send the bytes to the receiving application are represented as a transport channel.

A channel is a type that takes a stream of data, creates a package according to a particular network protocol, and sends the package to another computer. Some channels can only receive information, others can only send information, and still others, such as the default TcpChannel and HttpChannel classes, can be used in either direction.

Although the server process knows everything about each unique type, the client knows only that it wants a reference to an object in another application domain, perhaps on another computer. From the world outside the server application domain, a URL locates the object. The URLs that represent unique types to the outside world are activation URLs, which ensure that your remote call is made to the proper type. For more details, see Activation URLs.

Complete Remoting System Design

Suppose you have an application running on one computer, and you want to use the functionality exposed by a type that is stored on another computer. The following illustration shows the general remoting process.

Remoting process

If both sides of the relationship are configured properly, a client merely creates a new instance of the server class. The remoting system creates a proxy object that represents the class and returns to the client object a reference to the proxy. When a client calls a method, the remoting infrastructure handles the call, checks the type information, and sends the call over the channel to the server process. A listening channel picks up the request and forwards it to the server remoting system, which locates (or creates, if necessary) and calls the requested object. The process is then reversed, as the server remoting system bundles the response into a message that the server channel sends to the client channel. Finally, the client remoting system returns the result of the call to the client object through the proxy.

Very little actual code is required to make this work, but some thought should be given to the design and the configuration of the relationship. The code can be absolutely correct and yet fail because a URL or port number is incorrect. For more information, see Configuration.

Though this high-level overview of the remoting process is fairly straightforward, the lower-level details can be quite complex. More in-depth discussion of the major elements of remoting is provided in other topics, as listed below.

See Also

.NET Remoting Overview | Boundaries: Processes and Application Domains | Remotable and Non-Remotable Objects | Object Activation and Lifetimes | Channels | Security | Configuration