You are here: Project > Projects > Orbweb > Overview > 
25.4.2014 : 10:15 : +0200



Cohesion Orbweb is an effort to create a substrate for Peer-to-Peer Desktop Grid Computing based on open standards. Orbweb leverages the industrial-strength Opens external link in new windoweXtensible Messaging and Presence Protocol (XMPP) to tackle domain-specific challenges, including high scalability, support for volatility, NAT/Firewall traversal and protocol efficiency. Note, that the subsequent paragraphs give only an overview. Please have a look on our upcoming Opens internal link in current windowpublications for more detailed information about Orbweb. 


Orbweb belongs to the class of unstructured hybrid or hierarchical P2P networks. Hybrid approaches are characterized by the fact that part of the network functionality is delegated to a comparatively small number of superpeers. While data-centric applications use superpeers for resource index caching, their responsibility within Orbweb is membership management. This allows for rapid view updates that are essential for achieving good efficiency in P2P Grid Computing applications.

Figure 1: Orbweb architecture.

Figure 1 shows the protocol and service stack of Orbweb. XMPP servers as the basic communication technology. It provides a group abstraction (Multi-User Chats, Opens external link in new windowXEP-45) and allows for uni- and groupcasting. However, as XMPP was not explicitely designed for High-Performance Grid Computing, Orbweb contributes a number of additional services and optimizations to further improve the applicability of Orbweb within this new domain. These optimizations are:

  • An enhanced communication subsystem that dynamically creates direct P2P connections to those peers with which many messages have been exchanged recently. Such End-to-End (E2E) sessions are created based on online traffic analysis in a way that respects limited client capabilities. Thanks to this modification Orbweb takes considerable parts of the relay load off the XMPP server. The resulting network structure is visualized in Figure 2.

Figure 2: Orbweb network structure.

  • An extended MUC component (X-MUC) allows for creating arbitrary topologies among the members of a room. Thus, we can provide highly scalable groups by employing partial membership views of configurable size. A key feature of X-MUC is the ability to create complex view managers through view manager composition.






Figure 3: Elementary view managers provided by Orbweb.

  • Orbweb provides a topology-aware decentralized groupcast implementation based on the Opens external link in new windowBimodal Multicast protocol and a custom view manager. Topology-awareness means that the delivery strategy for groupcast messages takes the physical network setup into account.
  • Orbweb uses Opens external link in new windowFast Infoset, a binary encoding of XML, to create a denser wire format for exchanging XMPP stanzas.


The performance of Orbweb has been evaluated extensively. Figure 4 shows the server-side resource usage in a volatile group of increasing size. Despite an extremely high churn rate of roughly 330 joins/leaves per second for a 5K host setup, Orbweb's tree-based view manager exhibits a very low resource usage of roughly 1.51 ms/cycle. In contrast the view-complete view manager, i.e. each node knows about all other nodes, exposes linearly growing resource usage finally leading to server-side memory shortage for group sizes beyond 640 nodes.

Figure 5 shows that the server-side resource usage for a groupcast operation using our optimized (ta-pbcast) groupcast implementation is constant with respect to the size of the group. With 5 ms/groupcast for a 1K group an up to date server supports message rates of several hundred groupcasts per second as opposed to several tens of groupcasts for the original groupcast implementation.

Figure 4: Server-side resource usage per Join/Leave cycle

Figure 5: Server-side resource usage per groupcast operation

Topology Visualization

Orbweb comes with a test suite (see Figure 6) that can be used to experiment with the different view managers. The tool allows for adding (❶),and removing peers (❷)  unicasting and groupcasting messages (❸), the selection of view managers (❹), and the visualization of the group topology (❺). The latter leverages the sophisticated graph visualization library Opens external link in new windowyfiles. Note, that an edge does not model a connection but a contact, i.e. that one peer has another peer in its view (❻). The test suite is Opens internal link in current windowavailable for download.

Figure 6: Orbweb test client.


Traffic Analysis

XMPP and its extensions employ a large number of different stanza types. When developing complex protocols network traffic data provided by domain independent analysis tools is insufficient to gain a precise understanding of the actual packet flow produced by the protocol implementation. Hence, Orbweb provides a packet analysis tool that is implemented as a plugin for and thus tightly integrates with the Openfire XMPP server. Figure 7 shows a screenshot of the tool: It provides counters for incoming, outgoing, and the overall number and the transmission rate for presence, IQ (including namespace and action), and message stanzas (❶). To get a quick overview of the share a stanza type contributes to the overall traffic, a stacked chart visualization is provided (❷, ❸).


Figure 7: The Orbweb traffic analyzer records and visualizes the overall number and the throughput rates for incoming and outgoing XMPP stanzas broken down into stanza types. The visualization is based on the Opens external link in new windowGoogle Chart API and embedded into the Openfire administration console.

Network Component Visualization

Orbweb automatically identifies network segments (created by Firewalls and NAT devices) among the set of participating peers to minimize the number of messages that have to be relayed by the XMPP server. As knowledge about the network topology is of prime importance for debugging and evaluation purposes, Orbweb provides a tree map visualization of the identified components (see Figure 8). In conjunction with the traffic analyzer the component visualization can provide valuable insight into the reasons of pathological traffic patterns.


Figure 8: A snapshot of the components within a 120-node group visualized as a tree map just after creation. As indicated by the labels, there are 54 components of size 1, 9 of size 2, 3 of size 3, 2 of size 4 and 5, and 1 of size 6 and 15. The visualization is based on Opens external link in new windowAdobe FlexTM and embedded into the Openfire administration console.