See javadoc for package org.nebulostore.appcore.addressing.


Each module is an area of responsibility; modules do not directly translate into objects/threads/processes.

Some modules need to store internal state.

Modules are event-driven.

  • Dispatcher - delivers internal messages between modules
  • Network? - abstracts transport layer; handles all communication between nebulostore peers
  • Authentication? - identifies users (is this user really userA?)
  • Authorization? - manages access control to locally-stored resources (can userA modify directory dirId?)
  • Encryptor? - handles encryption: broadcast, simple asymmetric, symmetric
  • Decryptor? - handles decryption
  • Broker - manages replication contracts; negotiates new replication agreements (actively and reply to proposals by others);
  • Cache? - stores read-only copies of remote objects; returns references to the locally-stored objects
  • ApiFacade - translates nebulostore API requests to nebulostore actions (should it be divided into some sub-modules?)
  • Replicator? - handles remote requests for objects that are stored locally (input: objectId, authUser)


Threading model

NebuloStore is a single, multi-threaded process.
Two jobs are always running - those representing Dispatcher and Network modules. Dispatcher needs to monitor the event queue and Network needs to (at least) listen for incoming connections.
Other tasks (such as API calls or incoming data requests) are handled by single threads spawned and stored by Dispatcher. One thread is created per task and the context of a task is stored as thread's local data. Threads that are waiting for network or user response are notified by Dispatcher when the response arrives. All network messages that are received are handled via the Dispatcher's event queue.


Last modified 5 years ago Last modified on 10/14/13 19:38:27

Attachments (5)

Download all attachments as: .zip