Distributed Computing

Abstract

This article covers the means of cross-process and cross-machine interaction of applications developed with .NET framework. This snippet provides you with an in-depth understanding of the remoting capabilities that are built into .NET framework. It’ll present some scenarios in which .NET remoting can be employed, and includes a historical background on the progress and development of various remoting frameworks. This will get you started with your first remoting application by creating and configuring its corresponding server and client modules by using HTTP, TCP, and IPC channels. At the end, you’ll be able to design and develop remotable components under a CLR context.

Why Remote?

Remoting was typically used for accessing a server’s resources at the beginning of the client/server era. Every file server or database is an implementation of some tactics that allow code to be executed remotely. Nowadays, the building of distributed applications makes it easy to distribute business logic among diverse machines to improve performance, maintainability and scalability. There are couple of other distributed architecture implementations introduced and used frequently, such as Web Services, COM ,COM+, DCOM, RMI, CORBA and EJB. The following explains the need for remoting technology and its advantages over other technology.

Cross-platform Communication

You’ll typically encounter a heterogeneous combination of different platforms such as Windows, LAMP, Mac programming languages, C++, PHP, Cold Fusion, and frameworks. Those include .NET, or JAVA in a larger or mid-size enterprise. So, integration of these technologies could be a daunting task for system architects. Remoting technology like .NET Remoting, CORBA and SOAP are an absolute necessity in large-scale enterprise application integration, in order to build scalable applications.

Centralized business logic

One of the key scenarios for implementing remoting technology is the concentration of business logic on a central server. That considerably simplifies the maintainability and operability of large scale applications, because we have to update one single server rather a number of users separately. When a centralized architecture shares different applications, it reduces programming labor.

Remoting Architecture

.NET remoting is a process of programs or components interacting across certain application domains. The communication between application domains can happen inside the same process, between processes on a single system, or between processes on different machines. It provides a faster method of communication between .NET applications on both the client and server side. All in all, .NET remoting is a perfect paradigm which is only on a LAN (intranet), not on internet. .NET framework provides a foundation for distributed computing- it replaces DCOM technology.

Remoting implementations typically distinguish between mobile objects and remote objects. Mobile objects provide the ability to execute methods on remote servers, passing parameters and receiving return values. Remote objects will always be located in a server, and only a reference to it passes around other machines.

Want to learn more?? The InfoSec Institute Reverse Engineering course teaches you everything from reverse engineering malware to discovering vulnerabilities in binaries. These skills are required in order to properly secure an organization from today's ever evolving threats. In this 5 day hands-on course, you will gain the necessary binary analysis skills to discover the true nature of any Windows binary. You will learn how to recognize the high level language constructs (such as branching statements, looping functions and network socket code) critical to performing a thorough and professional reverse engineering analysis of a binary. Some features of this course include:

  • CREA Certification
  • 5 days of Intensive Hands-On Labs
  • Hostile Code & Malware analysis, including: Worms, Viruses, Trojans, Rootkits and Bots
  • Binary obfuscation schemes, used by: Hackers, Trojan writers and copy protection algorithms
  • Learn the methodologies, tools, and manual reversing techniques used real world situations in our reversing lab.

The following figure depictes a simplified view of remoting technology. Whenever a client application holds a reference to a remote object, it’s represented by a TransparentProxy object, which masquerades as the destination object. This proxy will allow all target object instance methods to be called upon it. Whenever a method call is placed to a proxy, it’s converted into a message that’ll pass through various layers.

remoting

Remoting characteristics

It’s a flexible and extensible framework that allows for different transfer mechanisms, such as HTTP and TCP, encoding (binary and SOAP), and security settings such as SSL and IIS security.

We can use it anywhere, such as in console applications, Windows applications, COM components or Windows services applications. .NET remoting enables us to work with stateful objects.

When we use remote objects, .NET automatically keeps track of where they originated. So, a client can ask one server to create an object and safely pass the parameters to another server.

Remoting in Action

Remoting classes can be found in the namespace System.Runtime.Remoting and its core classes can be found in mscorlib.dll. When using remote objects, both client and server must have access to the same interface definitions and serializable objects that are passed by value. That means at least three assemblies are needed for any .NET remoting project.

  • General Assembly (Class library project): A shared assembly which contains the interface and serializable object.
  • Server Assembly (Console application): iThe server side implementation of MarshalByRefObjects.
  • Client Assembly (Console application): The general assembly methods implementations.

General Assembly (Interface Definition)

First, create a C# base class library project where you have to define the interface ICustManager, which will be implemented by the server. In this interface, you’ll define a single method. getCust(), that returns a customer object to the caller:

namespace Rem_GeneralLib
{
public interface ICustManager
{
Customer getCust(int id);
}
}

Now, you need to define a customer that will hold the customer data. This class must be serialized because its object needs to be passed as a copy. Here, we’re declaring the name and address, and calculating the present age:

using System;

namespace Rem_GeneralLib
{
[Serializable]
public class Customer
{
public string Name;
public int Age;
public string Address;
public DateTime dt;

public Customer()
{
Console.WriteLine("Customer Object Created......");
}

public int getAge()
{
Console.WriteLine("-----Customer Data-----");
Console.WriteLine(Name);
Console.WriteLine(dt.ToShortDateString());
Console.WriteLine(Address);

TimeSpan ts=DateTime.Today.Subtract(dt);
return ts.Days / 365;
}
}
}

Finally, compile this class library project and its corresponding Rem_GeneralLib.dll file. It’ll be in the bin folder, which will be referenced in the remoting server project.

Remoting Server Implementation

The remoting server application will be a console base application. On the server, you need to provide an implementation of ICustManager that’ll allow you to load a customer from a fictitious database. This implementation will only fill the customer object with static data.

To implement the server application, first add the references from Rem_GeneralLib.dll and System.Runtime.Remoting.dll. Now add these following lines to the declaration:

using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;

After, you’ll have to implement ICustManager in an object derived from MarshalByRefObject. The method getCust() will just return a dummy customer object. Finally, register an HTTP channel which listens on port 7861. This channel is registered in the remoting system, which will allow incoming requests to be forwarded to the corresponding object.

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;

using Rem_GeneralLib;

namespace Rem_Server
{
public class CustomerManager: MarshalByRefObject, ICustManager
{
public CustomerManager()
{
Console.WriteLine("Customer Manager Object Created......");
}

public Customer getCust(int id)
{
Customer cst = new Customer();
cst.Name = "Ajay Yadav";
cst.dt = new DateTime(1982,10,9);
cst.Address = "India";
return cst;
}
}

class RemServer
{
static void Main(string[] args)
{

The class CustomerManager is registered as a WellKnownServiceType, which allows the client to remotely call its methods. The URL will be “RemotingServer.” Object mode is set to singleton, to ensure that only one instance will exist at any given time.

Service Consuming (Client Implementation)

The remoting client will connect the server and ask for a customer object. For the client, you also need to add references of System.Runtime.Remoting.dll, and compile the Gen_Remoting.dll file again.

Register the channel, you don’t need to specify the port number because client side ports are assigned automatically. Create a proxy class that’ll support IcustManager, which is passed in the activator class as a parameter. Enter the URL of the server. Finally, call the customer class method in order to populate the customer class data.

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;

using Rem_GeneralLib;

namespace Remoting_Client
{
class ClientStartup
{
static void Main(string[] args)
{
HttpChannel chn = new HttpChannel();
ChannelServices.RegisterChannel(chn,false);

ICustManager mgr = (ICustManager)Activator.GetObject(
typeof(ICustManager),
"http://localhost:7861/RemotingServer");
Console.WriteLine("Connecting to Server.....nn");

Customer cust = mgr.getCust(101);
int age = cust.getAge();

Console.WriteLine(age);
Console.ReadLine();
}
}
}

After finishing the coding, compile the client project. Remember, first run the server project console application which will listen on port 7861, then start the client console application which will produce the following output.

Note: System firewall echoes an alert because initially, it won’t allow any communication on port 7861 for security reasons. So allow an ad-hoc communication on port 7861.

Notice in the server console, it’ll notify you that all of CustomerManager constructor is called, right after the displayed output in the client project:

We can also confirm whether the socket is created on port 7861 or not by entering the netstat command.

Summary

This article is an introduction to .NET remoting, a distributed computing technology. We now know about the various aspects in which .NET remoting fits in and is applied. We dug deeper into remoting concepts, and their advantages in detail. We also learned an example of remoting technology by creating three assemblies which encapsulated general assembly, the server program and the client application.