Virtual Network Neighbourhood

Introduction

Can we think of a computing environment without sharing resources over a network? We might use FTP to transfer files from one machine to another machine or use Grid Computing to share processor time. Then our options of sharing resources with different platforms are very limited. The reasons for this big list of incompatibilities are different platforms use different architectures (x86, SPARC), protocols (NFS, CIFS), different byte orders (Little endian, Big endian) to list a few major restrictions.

The next question that we need to think is how to overcome this problem. Getting all the systems to use single processor architecture is not a viable option. The same with the byte order, but for the byte order we have a universally accepted Network Byte Order. Lastly the biggest hurdle, the protocol used to share the resource. One option is to use a common protocol among all environments. Once again this is not a good solution. The reasons being
1) Each type of resource needs to be shared differently
2) The semantics of one protocol doesn’t suit other environments.

Like a language translator can help us when we go a new country without knowing the native language, in the world of computer networks a “Protocol Translator” can rescue us from this situation. The Protocol translation is not a new concept it already exists in a different form at the lower levels of the protocol stack in the form of Gateways. If we could implement similar thing at the top of the protocol stack (Application Layer in OSI reference model) we can seamlessly share any kind of resource with any kind of computing environment.

Requirements of the Protocol Translator

Now that we have seen that a protocol translator can help us get out of this situation, we have to chalk out the requirements of this protocol translator.

i) Thin
ii) Handle different authentication protocols
iii) Serve multiple clients at the same time
iv) Stable

Requirement 1: Thin
The first point that we have to take into account is that to serve a single request from the client we will have to perform translation at least twice. Once from the incoming request to the target protocol and back again. But if the source protocol supports complex operations in a single request then we might have to perform multiple transactions with the destination protocol to achieve the required result. Hence we will have to keep the protocol translator as “Thin” as possible. If the protocol translator becomes “Thicker” then the response time takes a beating.

Requirement 2: Handle Different Authentication protocols
Every resource sharing protocol has its own system of authentication. Protocol translator should handle all these different Authentication protocols. Even after supporting all the different authentication systems we still have a problem. The authentication information given by the source protocol may not be suitable to use at the destination and vice versa. A good example is, CIFS (windows network neighbourhood) uses Challenge response authentication, but NFS (UNIX file sharing system) uses password authentication. In such a situation we have two viable solutions. First and the easiest way ignore the authentication which is not a good idea. The second is authenticating separately. That is we use the challenge response and authenticate the CIFS client and then when resource access is made we authenticate the translator with a predefined username and password with the NFS server. This is our best bet to ensure security.

Requirement 3: Serve multiple clients at the same time
The protocol translator must be able to serve multiple clients with different source and destination protocols at a given point. This way we can ensure transparency. For this requirement we can have a “Multithreaded” solution. A multithreaded solution will be light when compared to a “Multi process” solution. The reason being creating a process is costly (in terms of system resource) when compared to a thread.

Requirement 4: Stable
When we handle multiple protocols simultaneously we will have to be careful to mange the system resources used by the protocol translator. If the resources are not managed properly the translator might crash in the worst case or the response time will take a beating.