Skip to main content

Mesh DB

About

Mesh DB (or MDB) is a mesh network dedicated database with accompanying tooling and API. MDB is aimed at making it easier for mesh communities to share network related data, assisting the formation of inter-community data exchange, with the hope of bringing mesh technology closer to fulfill it's global potential.

Note: this project is currently archived.

MDB project facade image

MDB is Eclipse based and leverages frameworks such as EMF, Teneo, Hibernate & Apache GoGo Shell, MDB is being used in the Arig mesh community.

Goals

MDB is designed to handle the following tasks: - Mesh Oriented Database: mesh network oriented database suitable for a wide range of network scenarios. - Database Tooling: build advanced data manipulation tools. - Community Data API: provide a web-service API specification for data-exchange & application portability.

Features

  • Protocol agnostic network representation model.
  • Web-service API via Apache CXF
  • Apache GoGo command line interface.
  • Gis-enabled operations, e.g 'node selection by geo-bounds' or 'distance based neighbor selection'.
  • ORM based persistence layer - Hibernate, H2.

Installation

For production environment installation MDB is available as in Debian archive format:

$ git clone git://git.426.lv/mdb/deb-pkg-project -b dist
$ sudo dpkg -i mdb_0.1.0-1.amd64.deb

Once the package is installed, and after the daemon autostart has been enabled in /etc/default/mdb, the DB deamon can be launched with:

$ sudo /etc/init.d/mdb start

After which the shell interface will be available through:

$ telnet 127.0.0.1 42426

Or through the web interface available at

http://127.0.0.1:8080

MDB Shell

MDB includes an Apache GoGo based OSGi shell to help carry out DB operations:

MDB OSGi Shell

Though execution of hand-written SQL queries is still possible through the DB web interface, shell interaction & scripting greatly helps speed up regular DB interaction. The CLI includes advance features such as command auto completion, object id suggestion, name spaces, possible integration into web pages and more. The CLI essentially fills the gap of manual DB interaction, supplementing the automated aggregation features of Meshtool.

The MDB shell implementation borrows the notion of an index from Git, as a general purpose staging area for DB bound changes. The standard workflow would include adding or loading objects into the index, performing object manipulation, followed by a DB commit.

Tab completion offers many ways in which administration become easier – consider the following examples:

Index Blob ID

When multiple objects are present in the the index, it is necessary to indicate to which a manipulation directive is targxeted:

osgi> mdb:mn:add                                                // mesh node addition
mesh-node: <null id>, <null name>
osgi> mdb:mn:adddevice bid=0
device: <null id>, <null name>
osgi> mdb:dv:addinterface bid=1 type=wireless
interface: 96b8f1d6-73a0-427d-9005-4d660f255413, <null ip>
osgi> mdb:idx:status                                                  // index status
objects:
   MeshNode:
      bid=0: mesh-node: <null id>, <null name>
   Device:
      bid=1: device: <null id>, <null name>
   NetworkInterface:
      bid=2: interface: 96b8f1d6-73a0-427d-9005-4d660f255413, <null ip>
commit pending operations:
   0: ADD: MeshNode
   1: ADD: Device
   2: ADD: WiFiInterface
                 ┌────────────────────── (tab-pressed-here, cycle possible blob id's)
osgi> mdb:ni:set *
96b8f1d6-73a0-427d-9005-4d660f255413
bid=2

osgi> mdb:ni:set 
osgi> mdb:ni:set bid=2 ip=10.9.81.75                                // ip set command
osgi> mdb:idx:status
objects:
   MeshNode:
      bid=0: mesh-node: <null id>, <null name>
   Device:
      bid=1: device: <null id>, <null name>
   NetworkInterface:
      bid=2: interface: 96b8f1d6-73a0-427d-9005-4d660f255413, 10.9.81.75
...
osgi>

MDB Object ID

Another concept implemented is the shell context - consider the following shell session for example, assuming we are working with a newly installed DB:

osgi> mdb:mn:add
00:10:16,893 DEBUG MdbShellIndex - added entity MeshNode to index, op: ADD
mesh-node: <null id>, <null name>
osgi> mdb:mn:add
00:10:17,592 DEBUG MdbShellIndex - added entity MeshNode to index, op: ADD
mesh-node: <null id>, <null name>
osgi> mdb:mn:set bid=0 latlon=32.0,34.0
osgi> mdb:mn:set bid=1 latlon=0.0,0.0
osgi> mdb:idx:status
objects:
   MeshNode:
      bid=1: mesh-node: <null id>, <null name>
      bid=0: mesh-node: <null id>, <null name>
commit pending operations:
   0: ADD: MeshNode
   1: ADD: MeshNode

osgi> mdb:idx:commit                                     // commit pending operations
00:10:20,426 MdbShellIndex - processed: index op: ADD, MeshNode, eid:e53b61ad-cf80...
00:10:20,430 MdbShellIndex - processed: index op: ADD, MeshNode, eid:f62c6d15-f746...
osgi> mdb:geo:setGeoBoundFilter -1.0,1.0,-1.0,1.0
osgi> mdb:status
engaded mdb:
   url: jdbc:h2:mem:mdb/
filters: 
   geo-bound: south lat:-1.00000, north lat: 1.00000, west lon:-1.00000, east lon: 1.00000

                  ┌──────────────────── (tab-pressed-here, cycle possible object ids) 
osgi> mdb:mn:load * f62c6d15-f746-4a31-89d6-8e90d3ab1938
00:10:21,834 DEBUG MdbShellIndex - added entity MeshNode to index, op: NOP
mesh-node: f62c6d15-f746-4a31-89d6-8e90d3ab1938, <null name>
osgi>

The above tab-press triggers a node search within the MDB, but only within the active shell-context, which includes a geo-bounds filter – thus only one of the above mesh nodes is returned when suggesting node id's to load, the one inside the active filter. Other filters might also be added, including name filters, netmask filters and others.

Entity Attribute

When setting entity attributes, MDB shell can offer suggestions based on the Entity type being manipulated, derived from the command namespace:

osgi> mdb:version
mdb shell v0.0.0.qualifier, mdb version: 0.1
osgi> mdb:mn:add
20:17:43,442 DEBUG MdbShellIndex - added entity MeshNode to index, op: ADD
mesh-node: <null id>, <null name>
osgi> mdb:idx:status
objects:
   MeshNode:
      bid=0: mesh-node: <null id>, <null name>
commit pending operations:
   0: ADD: MeshNode
                       ┌──────── (tab-pressed-here, cycle possible Entity attributes)
osgi> mdb:mn:set bid=0 * 
firstupdate=
lastupdate=
latlon=
name=

osgi> mdb:mn:set bid=0 
osgi> mdb:mn:set bid=0 name=bb-32.03_34.50-node_01
osgi> mdb:idx:status
objects:
   MeshNode:
      bid=0: mesh-node: <null id>, bb-32.03_34.50-node_01
commit pending operations:
   0: ADD: MeshNode
osgi>

MDB Web Interface

Using the build-in H2 web interface is also possible, through which SQL queries may be executed:

MDB H2 web interface

Design

Network Model

MDB's network model is designed with flexibility in mind, so that various network configurations using different mesh protocols may be described by it.

MDB domain class diagram

Network interfaces subclasses currently include Ethernet & Wireless but other types may be added in the future.

MDB API

The MDB data API is currently divided into three parts:

MDB domain class diagram

  • MDBTopology.java - deals with API calls which should usually be invoked automatically, e.g by a daemon constantly updating the network topology view.
  • MDB.java - deals with API calls which should normally be invoked by network admins, i.e manually.
  • MDBGeo.java - deals with geo-aware API calls.

These will form the basis of a web-service API as a way to publish & share network configuration data.

Development

Source Code Layout

MDB is comprised of the following Eclipse plugin projects:

org.taproot.mdb           -  model
org.taproot.mdb.h2        -  H2 database engine dependencies
org.taproot.mdb.ui        -  GUI parts such as the network model editor
org.taproot.mdb.doc       -  documentation
org.taproot.mdb.edit      -  model item providers
org.taproot.mdb.shell     -  OSGi shell
org.taproot.mdb.tests     -  test plugin
meta/org.taproot.mdb.meta -  meta tasks, eg. PDE build & Test Automation

MDB makes use of source code generation which are annotated with @generated. Generated code may be either checked-out with git as regular code or generated locally. This can be achieved invoking the mdb.genmodel EMF genmodel.

The EMF code generation process is based on JET - MDB specific JET templates are located here.

See the EMF website for more information on this.

Testing

Unit Tests are provided in the form of a dedicated test plugin. Running the tests is possible by creating a JUnit plugin test launch configuration & selecting MDBAllTests as the test suite to run.