RAMP Architecture

The architecture of the RAMP middleware consists of two main layers (see figure below):

• the Service Layer, supports high-level features for peer-to-peer service offering and discovery;
• the Core Layer, providing low-level primitives for end-to-end communication (unicast and broadcast communication abstractions).

RAMP architecture.

Service Manager allows the registration and advertising of local services (registerService method). It actively listens to a well-known port to receive broadcast packets looking for remote services. Once received a discovery request, it looks for the requested service in the local repository: if locally available, Service Manager sends a response specifying the port and protocol that the discovered service exploits.

Discovery supports the retrieval of the available remote services, exploiting the sendBroadcast method to inquiry neighboor nodes (findServices method).

E2EComm offers multi-hop unicast and TTL-bound broadcast primitives (receive, sendUnicast, and sendBroadcast methods); see RAMP API for additional details.

Dispatcher performs communication operations between nodes at single-hop distance. Whenever Dispatcher sends a packet to a remote node, it opens a new socket over the single-hop link, via either TCP or UDP. Dispatcher exploits different sockets to send different packets, with one packet entirely via the same socket. In this way, the concurrent transmission of different packets (possibly of large size for TCP) can achieve good performance
Dispatcher manages unicast packets as follows:

1. if the local node is the destination, it sends the packet to the localhost at destPort;
2. otherwise, it sends the packet to the Dispatcher of the following node specified in dest.

Dispatcher manages broadcast packets as follows:

1. if the local node is not the sender (first hop), it decrements TTL and sends the packet to the local-host at destPort;
2. if TTL>0, it gathers the set of neighbors from Heartbeater (see the following) and then sends the packet to any neighbor, except for nodes in the same subnet of the sender.

The Heartbeater sub-component works to keep track of the set of single-hop RAMP neighbors. To discover these nodes, Heartbeater periodically sends a heartbeater request via UDP to 255.255.255.255 (every 60s). Any RAMP-enabled node in the same subnet replies with a heartbeater response to the sender.

Finally, RAMP exploits a listener-based architecture (PacketForwardingListener class) to permit an easy modification of packet header/payload at any traversing node. In particular, to the purpose of enabling the flexible introduction of any application-layer operation on RAMP transmitted packets at runtime, we have implemented the Dispatcher according to a listener-based architecture, which permits to efficiently and easily modify exchanged packets at any traversing node. Dispatcher permits to add and register listeners interested in monitoring incoming packets (see figure below). In this manner developers can implement and deploy additional listener-based components to support novel features, by extending RAMP capabilities without any modification of the basic Dispatcher.


Activity flow in RAMP Dispatcher.