nsensfel / ataxia Goto Github PK

The ID parameter for ataxia_{client,server}:add_at and ataxia_{client,server}:reserve_at is not on the same side of the permissions.

• Cache -> DB: get read-only copy, get read-write copy, get write permissions (no data transfer required).
• DB -> Caches: data reply, evict order.
• Cache state: pretty much MSI (do not have, read-only, read-write).
• DB state: list of clients that might have it in read-only, FIFO of clients requesting write permission.
• Write-through.

Write permissions are time-gated: after a set period of time, you lose the permission and any attempt to update the value from the DB will result in a failed request.

Ataxia might be able to use a variation of Chord as a way to manage the server nodes. However, I'll have to see how to manage backups & data migration to ensure that we can't get any inconsistencies.

Current Issues:

• The "Client -> Node0 -> ... -> NodeN -> Client" system is awkward with RPCs, and having updates go through so many hoops is going to take a considerable bandwidth. Can we replace it with a Node ! owner(database(), key()) -> (hit | {miss, node()}) and Node ! ataxia_client:function() -> ({hit, result()} | {miss, node()}) system while keeping Chord's properties?

Solved Issues:

• Given K the number of redundancies, for any database, there are K backup databases with no node being responsible for the same key on more than one of these DBs. Using the K next nodes should work.