Biocodr edited this page Nov 19, 2014 · 4 revisions

In order to improve the stability and performance of the Hive2Hive library, some optimizations have been built-in.


Some operations in the User Management and File Management might take quite some time du to:

  • Key Pair Generation
  • Network Latency

For this reason, all operations are executed in an asynchronous manner such that they can be run in parallel. Furthermore, each operation is compound using process components of the Hive2Hive Process Framework. This allows to fine-tune the concurrency of process-internal steps even more.

User Profile Concurrency

The User Profile is used by most User Management and File Management operations. Since these operations may be executed concurrently, race-conditions may appear between these operations.

As a solution, for each User Client, a local manager fetches the user profile from the DHT and distributes it to the requesting processes. These processes can request two different access requests: read/write and read-only. These requests are governed in two different queues by this local manager:

  • Qw - Queue for user profile read/write requests.
  • Qr - Queue for user profile read-only requests.

Of course, processes that solely require read-only access can be serverd in parallel. Processes that require read-write access have to be treated one after another. Write requests have a higher priority, because they involve a fetch of the most up-to-date user profile from the DHT. This updated profile can then also be distributed to the lower priority read-only requesters. As soon as all processes have finished their operations on the user profile, the manager puts it back to the DHT.

Since this user profile manager is per-User Client, this optimization does not solve concurrency issues that come from multiple user client requests.


Oftentimes, some data objects have to be fetched from the DHT for more than only one operation. Instead of getting and putting such objects multiple times, they get cached locally instead.

User Encryption Public Key Caching

Since a user's User Encryption Public Key is never changed and used a lot by other users, these other user's User Clients cache this key for some time. On every usage of the key, the lifespan of this cache is extended for a little longer.

This cache is stored locally on the user client's disk such that it can be re-used once it reconnects to the network.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.