The sockets API  provides the basic building block for developing today’s distributed applications. Sockets have a number of shortcomings, mainly due to the characteristics of the networks that provide the transport services offered through the sockets API:
- Applications using sockets have to be aware of where remote applications are. If application instance A wants to communicate to application instance B by opening a socket, it has to provide the address of the interface (IP address) of the host where application B is (or a synonym of this address, the hostname). If the interface crashes or application B moves to another host, the socket connection will fail. Moreover, if A wants to communicate again with B, A has to find out where B is now before being able to open a new socket to it. Shouldn’t the network be the one working out these details?
- The API does not provide a means to specify the characteristics of the communication. Other than choosing a reliable (TCP) or unreliable (UDP) transport protocol, the application using sockets cannot ask for a certain quality of service in terms of bandwidth, delay or jitter.
- Applications don’t know what application is requesting the communication. Going back to the example of application instance A trying to open a socket to application instance B, when application instance B has to decide if it accepts the incoming request it only knows that some application has requested a communication with it through a certain network interface (IP address or hostname). So B doesn’t know who is calling, only from where.
In previous posts [2,3,4] we’ve talked about RINA, a clean slate network architecture that solves many of the shortcomings of the current TCP/IP networks. Today we’ll see how it is the API that provides for developing distributed applications, compared to sockets.
Before starting, let’s refresh a couple of important concepts:
- In RINA, all application processes (any process or thread of a process running in a system) have a name, which is independent of where they are.
- This name can name a single application process or a group of them (therefore it is possible to reference a group of application processes with a single name).
- A single system (computing system, for example a router or a host) can belong to one or more networks (called DIFs). Networks are just specialized distributed applications that provide communication services to application processes, and therefore also have a name.
Let’s take the same scenario as before, application process A and application process B, which are executing in system A and system B respectively. This scenario is now depicted in Figure 1.
First of all, an application process can decide if it wants to be available to remote application processes. To do so, it must register with one or more of the networks available at its system. This is similar to binding a socket to a certain interface, but more general: when registering, the application process specifies through which networks (not interfaces of the system) it will be available, and it does so by specifying the network name. In the example, let’s imagine that application process B registers to network “foo”.
Requesting a communication service (aka flow)
Now application process A wants to communicate to application process B. It doesn’t know where it is and through which of the networks where system A belongs it will be available. Therefore it calls the operating system and issues a flowAllocateRequest, providing as parameters:
- the destination application process name (i.e B)
- QoS parameters (if any)
- its application process name (i.e. A)
The operating system in system A will find out that B is available through the network “foo”, and forward the request to allocate a flow to B. When the request arrives at system B, the OS at system B knows that application process B is registered to network “foo”, therefore the OS at system B calls application process B and tells it that A wants to connect to him. If application process B accepts, the network “foo” sets up the flow (allocates the resources required to provide the communication service) and application process A is notified.
Reading and writing data to/from the flow
This is similar to the sockets API, except for a detail: the OS calls the application process every time new data is available in the flow. Therefore application processes don’t have to poll the flow to see if new data is available.
Ending the communication
When either application process A or application process B invoke the “releaseResoruces” primitive, the resources allocated to the communication flow are released and the flow is terminated.
Summary of benefits of the RINA API compared to the sockets API
- Communication is requested by application name, therefore applications requesting a communications flow don’t have to know where the remote applications are. If an application moves the communication flow is not interrupted.
- Applications can define the characteristics of the requested flow, in terms of QoS parameters.
- Called applications know what application is calling them, therefore can take a more informed decision when accepting or denying the communication request.
- The interface is the same for one to one and many to many communications.
- The network stack calls the application process every time there is data ready to be read on a communication flow.
If you’re interested in knowing more about RINA, you can browse the following websites: http://csr.bu.edu/rina/, http://www.pouzinsociety.org/ or just send me an email.