csw / crdt-flix Goto Github PK

For each scenario where a server-side Optimized OR-Set could deliver the wrong semantics, we should come up with a testing protocol to exercise that situation (by injecting failed writes with retries, partitions, maybe duplicate messages, etc.).

For instance, to show non-idempotent add():

• client A: add(e)
  • operation succeeds, A sees simulated network error, prepares to retry
• client B: observes 'e', removes it with remove(e)
• client A: retries add(e)
• result: 'e' is in the set after being removed

Test protocol:

• every element should be added exactly once
  • disjoint per-client sets of elements to add
• every element added should be removed by one specific other client
  • disjoint sets to remove as well
  • removal should be attempted exactly once
• For instance: add 10*client ID + random n; remove if element % 10 == client ID

Like the existing one, but providing get/add/remove operations instead of read/update.

Extend the current client code to take parameters for: CRDT module, # of operations, and # of clients, spawn the appropriate number of clients, run tests as they do now, and report the final size of the CRDT on the server.

This should work for the OR-Set and orswot modules.

This will let us demonstrate space complexity problems by # of operations (for OR-Set) and # of clients (for optimized OR-Set).

In order to decide how to implement the fault injection module and to design test protocols, it is necessary to have a very simple sketch of our over all architecture

Start by simulating network errors, randomly choosing whether to actually perform the operation or not (to simulate a network error before or after the request is transmitted), and retrying after a delay.

Also: partitions, maybe duplicate messages?