C# Remoting and Distributed Computing

Abstract

Remoting is an infrastructure that allows the developer to use remote objects. Remote objects are objects that are based (or instantiated) outside of the caller’s Application Domain. This example shows you how to use both remote object access mechanisms (pass by value and pass by reference). It also shows you the power of remoting for distributed computing with a simple yet powerful implementation of a Task Server.

The Task Server can take any object that implements the simple ITask interface, and run it within its own Application Domain. What’s more, it can accept tasks from multiple clients at one time.

This tutorial requires that you have had exposure to C#. It does not require that you have used C# Remoting.

At the end of the tutorial you will be able to:
- Set up a client / server object relationship
- Pass an object by value
- Pass an object by reference
- Understand the concepts of remote task distribution

Remote Objects

Remote objects are either passed by reference or passed as an entire object.

In the first instance, the object’s reference is passed from App Domain ‘A’ to App Domain ‘B’, but the object method calls are marshalled between ‘A’ and ‘B’. The object lives and operated on App Domain ‘A’, but appears to App Domain ‘B’ to be a locally instantiated object.

In the second instance, the entire object and it’s dependencies (known as the Object Graph or Web) is serialized into byte-form and literally delivered from App Domain ‘A’ to App Domain ‘B’. The object is then unserialized and brought to life on App Domain ‘B’. The object now lives and operates locally on App Domain ‘B’.

Two areas need to be attended to, namely the server Application Domain (i.e. the object host) and the client (i.e. the object client).

Setting up the Object Host, known as the Server

The first step to be taken when setting up the server is to create a Channel through which your object will communicate. This can be either a TCP/IP channel or an HTTP channel. TCP channels are faster and recommended for networks that have limited firewall restrictions on packets traversing through networks. HTTP channels, however, are far more flexible and are recommended for environments where remoting is done over broad networks such as the Internet.

We will be using a TCP/IP channel, and will run the client and the server on the same machine, under two different application domains. Thus, to create my channel on port 8065 on my local TCP/IP stack I type the following code:

TcpChannel myChannel = new TcpChannel(8065);

The next step is to register the channel with .NET’s Channel Services. This will make the channel publicly accessable outside of the server’s app domain. To do this I type:

ChannelServices.RegisterChannel(myChannel);

The last step is to tell the .NET remoting infrastructure about the object that we want to make public. We need to give the object type and location, a name by which clients will locate the object and the way in which the remoting infrastructure must handle calls made to the object. To get the object type I do the following (rather unconventional, but makes more sense to me):

Type objectType = new MyCoolObject().GetType()

To register the object with the .NET remoting infrastructure I type the following:

RemotingConfiguration.RegisterWellKnownServiceType(
objectType, “MyCoolObject”,
WellKnownObjectMode.Singleton);

There are two ways an object call can be handled: Singleton and SingleCall. Singleton implies that the object is created on the first client method call and kept alive until the client breaks the connection or the object exits naturally. SingleCall implies that the object is created on every client method call, is alive for the duration of the method call and then exits once the method finishes. The client connection does not end with a SingleCall, only the object is destroyed.

Setting up the client for the remote object

The first requirement on the client side is that the compiled class for the remote object is available locally. This is used by the .NET remoting infrastructure proxy to intercept and marshal messages being passed to and from the remote object.

A channel needs to be created once again, and then registered with the infrastructure so that it can become useable:

TcpChannel myChannel = new TcpChannel();
ChannelServices.RegisterChannel(myChannel);

Note that we don’t specify a port address when we create the channel. This is specified in the following step, when we ask the server to give us a reference to the remote object that we are after. The code:
Continues…