Need to investigate how this will interact with causality tracking.

At this point, dumping all state and reloading will do. Fancy stuff like Merkle trees comes later.

Assuming things will be at fixed locations in argv works okay for now, but it'd be more convenient to have an actual config.

With a subscription, the client thread ends up blocking in the store code, and hence there's no way for us to detect that a client has disconnected. This means that when there are no more elements for that stream (as often in tests), then that thread will wait infinitely, never getting any data, nor realising that the socket is no more.

Chainreaction suggests use of a standard consistent hash ring for discovery and mapping locations, so a new node may join a chain in the middle or as a head node.

Rather than invalidating iterators, we can just render the whole point moot for now. This will require randomizing space names in tests, mind.

Currently everything is in-memory only.

Currently, we require that an event is completely acked before returning to the publisher, or require that a connection go into consumer mode entirely. This limits both throughput and flexibility.

Etcd/consul/ZK would do.

See ChainReaction paper.

See ChainReaction paper. This boils down to a sequence number per message.

Bit of a wild idea, this one. But having trees rooted at the head node could be good when having a discovery system that doesn't give us serializability. We'd need to figure out how chain nodes could re-organise themselves.

If a head / middle node loses the connection to it's down stream peer, we basically halt and catch fire. All further requests fail with a Protocol Error, as the connection is now closed.

Eg: Merkle trees, or other summary mechanism.

This is to allow an eventually async protocol