Introduction to Remoting
Introduction to Remoting
What is .NET Remoting?
.NET Remoting provides a way for application in different machines/domains to communicate with each other. Remoting provides a powerful yet an easy way to communicate with object in different app domains. Any object which executes outside the app domain can be considered as Remote. It is a generic system for different applications to use to communicate with one another. .NET objects are exposed to remote processes, thus allowing interprocess communication
Remote objects are accessed via Channels, Channels can be thought of as Transport mechanism to pass messages to and from remote objects. All the method calls along with the parameters are passed to the remote object thru the channel viz. HTTP or TCP. The applications can be located on the same computer, different computers on the same network, or even computers across separate networks.
.Net Remoting components
To allow an application located in different application domain or process to communicate with another one using .Net remoting technique, you have to just build the following:
· A remotable object. Which is an object that contain some properties and methods located in one application domain and you need to call its methods or properties from another application domain or process.
· A host application. This is the host of the remotable object. It is also called the server application. The main task of this host is to listen to requests for the hosted remotable object.
· A client application. This is the application which makes requests for the remotable object.
Types of Remotable Objects
There are 3 types of remotable objects that you can configure and choose from depending on the requirements of your application.
· Single Call: The remotable object is intended to be called from one client / one instance at a time.
· Singleton Call: Several clients / several instances of the remotable object can be utilized
· Activation: Richer than Singleton in the regard of other aspects.
.NET Remoting versus Distributed COM
In the past interprocess communication between applications was handled through Distributed COM, or DCOM. DCOM works well and the performance is adequate when applications exist on computers of similar type on the same network. However, DCOM has its drawbacks in the Internet connected world. DCOM relies on a proprietary binary protocol that not all object models support, which hinders interoperability across platforms. In addition, have you tried to get DCOM to work through a firewall? DCOM wants to communicate over a range of ports that are typically blocked by firewalls. There are a ways to get it to work, but they either decrease the effectiveness of the firewall (why bother to even have the firewall if you open up a ton of ports on it), or require you to get a firewall that allows support for binary traffic over port 80.
.NET Remoting eliminates the difficulties of DCOM by supporting different transport protocol formats and communication protocols. This allows .NET Remoting to be adaptable to the network environment in which it is being used.
.NET Remoting versus Web Services
Unless you have been living in a cave, or are way behind in your reading, you have probably read something about Web services. When you read the description of .NET Remoting it may remind you a lot of what you’re read about Web services. That is because Web services fall under the umbrella of .NET Remoting, but have a simplified programming model and are intended for a wide target audience.
Web services involve allowing applications to exchange messages in a way that is platform, object model, and programming language independent. Web services are stateless and know nothing about the client that is making the request. The clients communicate by transferring messages back and forth in a specific format known as the Simple Object Access Protocol, or SOAP. (Want to get some funny looks in the hallway? Stand around in the hallway near the marketing department with your colleagues and discuss the benefits of using SOAP).
The following list outlines some of the major differences between .NET Remoting and Web services that will help you to decide when to use one or the other:
- ASP.NET based Web services can only be accessed over HTTP. .NET Remoting can be used across any protocol.
- Web services work in a stateless environment where each request results in a new object created to service the request. .NET Remoting supports state management options and can correlate multiple calls from the same client and support callbacks.
- Web services serialize objects through XML contained in the SOAP messages and can thus only handle items that can be fully expressed in XML. .NET Remoting relies on the existence of the common language runtime assemblies that contain information about data types. This limits the information that must be passed about an object and allows objects to be passed by value or by reference.
- Web services support interoperability across platforms and are good for heterogeneous environments. .NET Remoting requires the clients be built using .NET, or another framework that supports .NET Remoting, which means a homogeneous environment.
Channels are the transport media used to send / receive messages between applications across remoting boundaries (these boundaries can be between application domains, processes, or computers). A channel is an object that takes a stream of data, packages it according to a specific network protocol, and then sends the package to the other side. Channels can be categorized as channels which can send messages, channels which can receive messages, or channels which can perform both sending and receiving like the two .NET channels “HTTPChannel” and “TCPChannel”.
Create a Remotable Object
A remotable object is nothing more than an object that inherits from MarshalByRefObject. The following sample demonstrates a simple class to expose the omnipresent hello world. This object exposes a single method HelloWorld that will return a string. The only values that can be returned from methods are the classes in the .NET Framework that are serializable such as string and DataSet. In addition, if you need to return a user-defined object then the object needs to be marked as serializable.
Create a new C# class library project. Add a class called SampleObject and put in the following code. Add a reference to System.Runtime.Remoting in the project, otherwise the TcpChannel will not be found. Compile the class to make sure you have everything correct.
/// Sample object to demonstrate the use of .NET Remoting.
public class SampleObject : MarshalByRefObject
/// Return a hello message
/// <returns>Hello world message</returns>
public string HelloWorld()
return "Hello World!";
Create a Server to Expose the Remotable Object
We need to create a server object that will act as a listener to accept remote object requests. For this example we will use the TCP/IP channel. We first create an instance of the channel and then register it for use by clients at a specific port. The service can be registered as WellKnownObjectMode.SingleCall, which results in a new instance of the object for each client, or as WellKnownObjectMode.Singleton, which results in one instance of the object used for all clients.
It is not necessary to create the server listener if you are planning to use IIS. For obvious reasons, IIS only supports the use of the HttpChannel. Create a virtual directory for your application and then put code to register your service in the Application_Start event.
For our example, we’ll go ahead and create a server listener in case you don’t have IIS. Since the service needs to be bound to an available port, for our example I chose 8080, which is a port that I know to be unused on my computer. You may need to choose a different port depending upon what ports you have available. To see a list of the used ports on your computer open a command prompt and issue the command “netstat –a”. It may produce a long listing so make sure the command prompt buffer sizes are set to allow scrolling. Compile the class to make sure you have everything correct.
Create a new C# console application project. Add a class called SampleServer and paste in the following code. Add a reference to System.Runtime.Remoting in the project, otherwise the TcpChannel will not be found. In addition, add a reference to the project containing the SampleObject, otherwise the code will not compile because it won’t know how to find a reference to SampleObject.
/// Sample server to demonstrate the use of .NET Remoting.
public class SampleServer
public static int Main(string  args)
// Create an instance of a channel
TcpChannel channel = new TcpChannel(8080);
// Register as an available service with the name HelloWorld
System.Console.WriteLine("Press the enter key to exit...");
Create a Client To Use the Remotable Object
Now that we have our remotable object and a server object to listen for requests, let’s create a client to use it. Our client will be very simple. It will connect to the server, create an instance of the object using the server, and then execute the HelloWorld method.
Create a new C# console application project. Add a class called SampleClient and paste in the following code. Add a reference to System.Runtime.Remoting in the project, otherwise the TcpChannel will not be found. In addition, add a reference to the project containing the SampleObject, otherwise the code will not compile because it won’t know how to find a reference to SampleObject. Compile the class to make sure you have everything correct.
/// Sample client to demonstrate the use of .NET Remoting.
public class SampleClient
public static int Main(string  args)
// Create a channel for communicating w/ the remote object
// Notice no port is specified on the client
TcpChannel chan = new TcpChannel();
// Create an instance of the remote object
SampleObject obj = (SampleObject) Activator.GetObject(
// Use the object
if( obj.Equals(null) )
System.Console.WriteLine("Error: unable to locate server");
The .NET remoting infrastructure needs specific information to work successfully and smoothly. That information is what we call configurations. You can choose one of the available two ways to configure your remotable types depending on your own preferences. The first way is by calling configuration methods directly from your server and client code, and this is what we call programmatic configuration. The second way is by creating an XML configuration file (.config file). To configure your remotable type properly whether by programmatic configuration or through a configuration file you have to provide the following information:
- The activation type of your remotable object.
- The name or address of the metadata that describes the remotable type.
- The kind of the registered channel and the port number.
- The URL that uniquely identifies the remotable type.
Test the Remoting Sample
Once you have created the projects and successfully compiled each of them you are ready to try it out. Assuming you chose a free TCP/IP port for the service, start the server executable. After the server successfully starts it will result in a console window being displayed with the message “Press the enter key to exit”. The server is listening so you are now ready to run the client. Executing the client should result in “Hello World!” being displayed in a separate console window. The client window will then close while the server remains open and available.
If you have multiple computers available to you on a network you could execute the server on one machine and the client on another just to prove to yourself that it really is remoting. In order to run on separate machines you would need to change the reference to localhost in the sample client to point to the appropriate location.
No comments yet.