The MCPO service is one of the services intended to be used on top of ariba (originally as part of the SpoVNet architecture). It realizes a group communication service for applications (and potentially also other services) wishing to send data to more than one receiver with a single transmission.
How MCPO embeds in the overall architecture is shown in the figure to the right. It resides between application and ariba, optionally using the CLIO module for Cross-layer information, if available.
As the main intention of the service is to provide group communication capabilities to applications (without e.g. IP Multicast support), MCPO builds and maintains a hierarchy of clusters, holding a small number of peers each (very similar to the well-known application-layer multicast approach NICE). This operation is of course transparent to the specific application, all that is seen by upper layers is the interface MCPO is accessed through (MCPO API). In its current implementation MCPO will disseminate a sent packet to all peers in the hierarchy, so every member is reachable via one initial transmission request. In future enhancements we will give the possibility to specify (sub-)groups in order to further distinguish sets of peers in one application context. This is useful e.g. for different groups in a game (partitioned by the virtual playground) or for different channels in media transmission scenarios.
The picture to the left shows an exemplary MCPO hierarchy structure and four data dissemination steps. An arbitrary peer sends its data to all peers in the lowest layer cluster it resides in (a). Cluster leaders forward the data to all clusters they are part of except the one the data came from, until all nodes have been reaches (b-d). This picture gives an impression how MCPO disseminates data in the hierarchy. In the following we will explain how application and service programmers can use MCPO and how the basic protocol API is accessed.
MCPO can be used through the provided protocol API. It consists of a part that is used to interoperate with the application (ReceiverInterface?), constructors forservice creation and some methods for e.g. data dissemination. The ReceiverInterface? has to be implemented by the application to indicate two events: If a data packet arrives for the application that has to be handled and to indicate that the MCPO service is ready for service provision (the latter normally arising only once shortly after starting up).
The MCPo constructor looks like this:
It takes five arguments, being a pointer to the ReceiverInterface? mentioned above (normally the application itself), a pointer to the ariba module to be used, another pointer to the node instance and two optional parameters, the clioNode and a boolean indicating the usage of a visualization. The use of visualization is quite specific to an external visualization tool that has been used in a demonstration of the system and is therefore highly special (and not of importance to the normal user). CLIO is a module that is able to provide important cross-layer information to the MCPO service. These infos are needed for service maintenance, but MCPO is able to gain them autonomously, if needed. So this pointer may be NULL (and in fact out of the box is).
To send data to all members in MCPO, the method sendToAll is used. As the name indicates, there is no further differentiation in subgroups in the current version of MCPO right now (but planned for future releases). To extent this functionality, one will already find the methods joinGroup, leaveGroup and sendToGroup in the code, but those do nothing of interest at the moment. Therfore the MCPO usage is quite simple and limited to the steps: Implementing the ReceiverInterface?, creating the service class and (after having received the serviceIsReady indication) sending data to the service. Thus, MCPO realizes easy-to-use group communication at the application layer.