The objective of Grph is to provide researchers and engineers a suitable graph library for graph algorithms experimentation and network simulation. Grph is primarily a software library, but it also comes with a set of executable files for user interaction and graph format conversion; as such, it can be used autonomously. Performance and accessibility are the primary targets of the Grph library. It allows manipulating large graphs (millions of nodes). Its model considers mixed graphs composed of directed and undirected simple- and hyper-edges. Grph comes with a collection of base graph algorithms which are regularly augmented.
Grph includes bridges to other graph libraries such as JUNG, JGraphT, CORESE (a software developed by the WIMMICS team INRIA-I3S), LAD (Christine Solnon, LIRIS), Nauty (Brendan D. McKay), as well as specific algorithms developed by Matthieu Latapy and Jean-Lou Guillaume (LIP6), etc.
BigGrph is a distributed graph library. It supports shared-nothing clusters and comes with facilities for Torque and OAR clusters. BigGrph aims at helping the Research in distributed graph algorithmics. For this reason it proposes several programming paradigms: in addition to BSP and Map/Reduce, BigGrph supports asynchronous message passing, centralised, systolic, and mobile-agent based programming models.
BigGrph can be used from within the researcher’s IDE. To allow this, it features automatic deployment of executable code, transparent retrieving of remote standard outputs/exceptions, and remote debugging.
The use of various optimization techniques (adequate data structures, parallelism, compact data encoding, etc) results in excellent overall performance. It loads and computes data faster than Giraph and GraphX, while requiring less memory.
DRMSim relies on a discrete-event simulation engine. It proposes a general routing model which accommodates any network configuration. Aside to this, it includes specific models for GLP, and K-chordal network topologies, as well as implementations of routing protocols, including a routing protocol proposed in [NRS09] and lightweight versions of BGP. More features will be further incorporated into the simulator. In particular, they address the challenge of simulation of larger networks (order of 10k nodes), the next step is to propose new routing algorithms, including state-of-the-art ones, to enhance the code, and to go further with distributed simulation campaigns.
DRMSim is developped in cooperation with Alcatel-Lucent Bell Labs (Antwerpen, Belgium) and the LaBRI (Laboratoire Bordelais de Recherche en Informatique, Bordeaux, France).
Sage is a free open-source mathematics software system licensed under the GPL. It combines the power of many existing open-source packages into a common Python-based interface. Initially created by William Stein (Professor of mathematics at Washington University), it is currently developed by large worldwide community.
COATI contributes the development of Sage with the addition of various graph algorithms and is also involved in the reviewing process of various patches.
Octojus is a decentralized Object-Oriented Java RPC middleware based on Jacaboo, from which it inherits the deployment and bootstrapping facilities.
Octojus is not a remote method invocation mechanics like RMI is, it is not a sophisticated message-passing framework like MPI, nor it is a grid-computing middleware like Hadoop. Its programming model can be seen as an object-oriented version of the Remote Procedure Calls (RPCs). More precisely, Octojus defines the concept of executable object. An executable object is a serializable Java object featuring a specific procedure, and it can embed data. Such an executable object can be sent to a remote node where it will be executed. If the execution request is declared “synchronous” by the client, the submission is blocked until the result of the execution is available.
At a higher abstraction level, Octojus provides a framework for the development of systolic algorithms, a batch scheduler, as well as an implementation of Map/Reduce. The latter in used in the BigGrph graph computing platform.
In addition to this, Octojus features a system for obtaining dynamic information on nodes belonging to the cluster. This information can be used to load-balancing purposes. Octojus self-benefits from this to provide GUI for the real-time monitoring of the clusters and running distributed applications.
Interaction can be achieved via the use of an efficient stream-oriented communication scheme dedicated to node-to-node communication, and via the use of Octojus RPC facilities.
Alongside with data aspect of distributed data structures, LDJO comes with mechanisms for processing them in a parallel way, namely Map/Reduce and Bulk Synchronous Parallel (BSP).
The primary objective for developing LDJO was to give the BigGrph project an effective middleware for the loading, the manipulation and decentralized processing of large graph topologies.
Jacaboo’s design makes it suited to the experimentation of distributed applications. It is started from a specific node called the initiator node. This specific node is allowed to be out of the computational cluster. For instance, the initiator node may be the workstation of the developer, who can hence execute his distributed code from inside his favourite IDE. The initiator node simply needs to be given the names of the computational nodes it will contact, as well as the permission to access them through SSH. If these requirements are met, then Jacaboo is able to start the distributed application by executing the following workflow:
- it automatically discovers the application binaries by scanning the application classpath;
- it deploys the binaries found in an incremental way, dealing with shared filesystems (NFS, SSHfs, Samba, etc);
- it deploys a compliant Java virtual machine on cluster nodes, if needed;
- it bootstraps the application by running a local main() on every cluster node;
This process is fully automatized and transparent to the programmer/user.
Jacaboo-based applications have the following properties:
- the standard outputs (stdout and stderr) of their remote components are forwarded back to the initiator node, which facilitates tracing/logging;
- exceptions on remote components are forwarded back to the initiator node in the form of exception, which allow the caller to deal with them using standard try/catch blocks;
- killing any process on any node results in the entire shutdown of the application on the entire cluster.
The primary motivation for developing Jacaboo is to have an efficient and comprehensive deployment infrastructure for the BigGrph distributed graph library.