An introduction to SPLAY

SPLAY eases the development and deployment of distributed applications on any testbed: dedicated shared environments such as PlanetLab, emulated environments such as ModelNet clusters, or even non dedicated networks such as networks of idle workstations.

Applications written for SPLAY are easy to read, easy to develop and very lightweight.

Easy to read as the code produced is highly similar in size and structure to the pseudo-code usually found in research papers. Easy to develop as a large set of libraries and components are provided, and Lua-based implementations relieve the need for manual memory management or system-related coding, while being as effective and fast as C-based implementations. Lightweight, finally, as a complete implementation of the well-known Chord protocol consists of just 59 lines including bootstrapping code! Similarly, an implementation of Pastry, a more complex DHT, takes no more than 265 lines including support for fault tolerance: orders of magnitude less than typical Java implementations of the same protocol. A Pastry node takes less than 1MB of memory, 500KB of which are used by the SPLAY infrastructure itself.

A unique characteristic of SPLAY is its emphasis on security: applications written and deployed with SPLAY cannot harm or overload the host testbed. This is of particular importance for non-dedicated environments, and when the users may write ill-behaved or malicious code, such as during lab sessions in universities. All operations that access the hosting node are sandboxed, and the administrator who deploys SPLAY on the testbed defines the resources he is willing to provide for SPLAY users.

SPLAY provides users comprehensive node selection tools for choosing a proper set of nodes for executing their applications on, based on several criteria (geographical positioning, load, memory, etc.), and to monitor the behavior of the execution. Furthermore, SPLAY allows to control the behavior of the testbed itself: it can for instance reproduce churn conditions, either from traces of real systems or from synthetic descriptions. SPLAY also provides a simple and efficient way to monitor the application, to retrieve experimental results, and tools to simplify bootstraping and membership management.

SPLAY provides two main interfaces: a command-line and a web-based interface. You can directly deploy a sample application on the PlanetLab testbed using our PlanetLab demo or any application on the SPLAYground emulated testbed.

The architecture

SPLAY is composed of three main components: a controller, a set of lightweight daemons running on the nodes of the testbed, and a set of applications instances hosted by the daemons. The controller gives order to the daemons to instantiates the application, and to apply dynamics-related operations (starting, stopping, monitoring an application, as well as churn management). The daemons run permanently on the testbed and create sandboxed execution environments for applications:

Splay controllers instructs daemons to instantiate applications.

A typical usage is illustrated below: one node of the testbed is hosting a SPLAY daemon, which instantiates peers of two overlays: a BitTorrent node participating to a cooperative content distribution overlay, and a Chord node part of a DHT service. Both peers are isolated from the host and have no direct access to its resources (memory, network, processing): they operate under the limits that where specified by the testbed administrator. Peers are also isolated from one another and experiments of a user cannot interfere with experiments from others.

A Splay daemon on a host of the testbed has instantiated a BitTorrent peer and a Chord peer.

The controller

The SPLAY controller is composed of several independent modules that can be distributed and replicated over multiple machines for scalability and robustness. All these modules communicate through a common database (for instance, MySQL or PostgreSQL). The ctl modules manage the distant daemons, log allows centralized monitoring and logging of the distributed application messages, jobs manages the application deployments in a multiple-users, multiple-experimentations manner, etc.

A Splay controller is composed of modules communicating through a shared database.

The libraries

A extensive set of libraries have been developed or adapted for SPLAY applications. These libraries include, but are not limited to, the following:

  • network programming including full-fledge UDP, TCP and fault-tolerant remote procedure calls (RPCs);
  • concurrent programming, events, threads and triggers;
  • a virtual file system isolated from the host file system;
  • logging facilities, cryptography, common data structures, and much more!
Some of the libraries proposed by Splay.

If anything about SPLAY and its technologies remains unclear, do not hesitate to ask us for more information at