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 is Eclipse based and leverages frameworks such as EMF, Teneo, Hibernate & Apache GoGo Shell, MDB is being used in the Arig mesh community.
- license: GPLv3
- source code: https://git.426.lv/?p=eclipse/mdb
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:
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:
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.
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:
- 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.