Skip to content
Tim Kuijsten edited this page Aug 9, 2016 · 37 revisions

On startup the master forks each db process and sends it a set of perspective configurations. Each perspective configuration consists of import- and export hooks, filters and hide parameters.

The master process receives and initiates new connections. The first packet on a connection should be an auth request. If an auth request is accepted, the connection is passed to the corresponding db process.

A db process receives authenticated connections accompanied with a perspective name from the master process (it's parent). The local offset is determined and a data request is sent to the other side. At the same time a data request is expected from the peer. If both parties exchanged one data request, data can be sent in both or only one direction.

flow chart

Properties

  • simple, easy to parse and bounds check "auth" packet (max 1024 bytes)
  • require the auth packet as the first packet on a new connection
  • accept exactly one auth packet per connection
  • disconnect if credentials are invalid or protocol is violated
  • require only three states per connection, "unauthenticated", "authenticated" and "transfer"

auth request

Total request must be JSON stringified and be less than 1024 bytes. Fields:

  • username {String}
  • password {String}
  • db {String}

data request

  • start {Boolean|String} indicates whether or not there is an interest in data:
    • false sending side has no interest in data itself
    • true sending side is interested in data from the start
    • string version sending side last version
  • JSON stringified < 512 bytes

If start is false the receiver must not send any more data. If start is true the receiver must start sending a series of BSON data starting at the beginning. If start is a version string the receiver must start sending a series of BSON data starting right after this version.

open data channel

  • perspective {String}
  • includePrevHead {Bool}
  • connection {fd}

As soon as an auth request is received and validated, the connection will be either disconnected or forwarded from the master process to the appropriate database. New versions will be submitted on the data channel, optionally the previous head can be included with the new.

open version channel

  • connection {fd}

The master process is able to open up a version channel. A version channel facilitates version requests. A version request is an asynchronous lookup of the latest version of an arbitrary id.

version request

  • id: {mixed}

A version request consists of an optional id. The database is expected to return the latest version of the requested id, or in case id is null, the latest version that is written in the DAG. All operations must be run on the _local database.

flow chart

Clone this wiki locally