Overview

The OpenClovis IOC component provides efficient transport for communication between Clovis Objects. The IOC layer works either on top of UDP or on TIPC. In case of IOC over UDP only Unreliable communication mode is supported and in case of IOC over TIPC both Reliable and Unreliable modes are supported. To enable all the functionalities of IOC, IOC needs broadcast enabled environment and all the nodes should be directly connected.

Applications wanting to communicate over IOC need to open communication ports with IOC and then using these communication ports the applications can send and receive data.

IOC has the capability to determine routes to reach any clovis objects in the system, that are residing on blades and the blades may or may not be connected to each other directly. If the nodes have more than one links(physical connections to other nodes) then the IOC select the appropriate link depending on the priority of the links. Once a link is selected the ARP module gives the link level address to send the message out.

Blocking and Non-blocking Receive: IOC supports Blocking and Non-blocking receive. In case of blocking receive it blocks the receiver thread inside the receive call waiting for a message to arrive or till the receive times out. IOC provides Non-blocking receive, which returns immediately and the application might have to poll on the communication port to figure out the data availability.

Non-blocking Send: IOC send hands over the message underlying transport and return immediately.

Priorites: IOC supports sending of messages of different priority. If a message sent is a high priority message and there are lower priority messages already in the queue, which are yet to be sent then the higher priority message is sent first. On the receive side also the higher priority message is delivered first.

Routing: The IOC also provides Routing services. That is, the IOC has a routing engine to enable it to select the a path to reach the destination IOC address for a packet. Only one route per destination is supported in current IOC. The route entries can be added at the boot time statically, if broadcast ie enabled then the route is learnt. In this release only direct routes are supported.

Heartbeating: IOC provides link level heartbeating support. If any of the link goes down then the IOC takes care of the on going communication and switchs to the other link. Whenever a send request to the failed node comes, an error is returned to the caller.

Neighbor Discovery: IOC supports a mechanism of automatical identifying all the ASP nodes present in the system and immediately establishes links with them for communicating with the clovis object on that nodes.

Port Unreachable errors: If a sender is trying to reach an object of a node which does not exist then IOC of the receiving node sends an IOC port unreachable message to the sending end.

Fragmentation and Reassembly: IOC supports send and receive of any size of messages. The fragmentation and reassembly is implemented in IOC which takes care of messages of any size.

Physical Addressing: Every ASP component that wants to communicate with other component in the network has to have a physical address. The Physical address is composed of the Node address, which is unique for each node in the system, and commponent port number, which is unique in a node.

Transparent Addressing

IOC supports transparent addressing. An application can register a logical address and its physical address with the IOC. A sender which wants to reach this application can use the logical address to communicate instead of the physical address. If the receiver moves to a new a new location the sender is not affected. Two types of communications are possible with logical addresses:

Session based: In this case, on issuing a send to a logical address, the IOC determines the physical address of that logical address and then sends the message to it. The subsequent sends to the same logical address will goto the same physical location. If the receiver moves somewhere else then the error is returned to the sending application.
Session Less: Here each send to a logical address trigers the logical to physical address lookup, if the receiver moves to a new location the next call transparently goes to the new location and no error is returned to the user.

Multicast Addressing: IOC supports multicating facility. This means that the clovis objects which are interested in joining a group have to register their physical address with IOC. The group will be having a multicast address. The messages received on that multicast address will be sent to all the clovis objects which have registered for that group.

Interaction with other components

The IOC depends on Buffer Manager (BM) for efficient message handling. Besides BM, it also depends on the Clovis Operating System Abstraction Layer (OSAL) for the following operations:

Task creation
Interprocess synchronization IOC also depends on Clovis Utilities like Heap, Containers, and Timer.