Research: (how) can we abstract out a RAFT-style leader election from the rest of the protocol?

[jimkberry]

Even if RAFT turns out not to be a very good agreement protocol for Apian (I don't know that - but am getting suspicious) the election mechanism is very straightforward and seems like it would be useful as a plug-in for other agreement models. Sort of the way the state synchronizer is for getting a new member's game state -up-to-date.

Need to have a look at how to do it without the rest of RAFT.

[jimkberry]

Here's an Apian-oriented view of how RAFT handles leader election. It appears that with only minor changes - mostly involving RAFT's double use of AppendEntries messages for both commit and heartbeat - it can be used by Apian.

[jimkberry]

[jimkberry]

Interesting - it seem like in order to do this a non-RAFT agreement group (or maybe even raft as well) needs: a) To use ApianCommands as heartbeats (like "empty" RAFT AppendEntries messages) b) To have a separate "hearbeat-only" message for the leader to send out if no commands have been sent recently

This is fine as far as it goes, but an ApianCommand in and of itself doesn't carry all of the data (no "ElectionTerm #") that a RAFT heartbeat needs to carry.

Note: Apian is going to consider "ElectionTerm" a Raft-election-only piece of data, and I'm not going to try to re-use some other pre-existing message property (epoch, for instance) for it.

I'm also not super-inclined to add an "ElectionTerm" property to an otherwise generic ApianCommand message.

[jimkberry]

While I've all-along assumed that different GroupManager implementations would have their own message types in order to do whatever it is they do that's different from other implementations, it now seems to me that an ApianCommand is a sort-of special case "generic" message that also needs to be able to carry GroupManager-specific data. I see a couple ways to go about this:

1. Subclass ApianCommand and add the SerDes in the GroupManager code. The new dynamic deserializer table supports this easily as long as the MessageType ID is overridden. It might be cleaner to add an optional "GroupType" to the generic ApianCommand definition to driver the deserializer.
2. Add an optional SerializedGroupData string property to ApianWrappedCoreMessage - which would work pretty much the same wat that the new SerializedCoreMessage property works.

[jimkberry]

I was wrong about 1) above - only the GroupMessage SerDes table is dynamic - and the more I look at it the less I like it. I've implmented a better plan - where a groupmanager can define a deserializer for message that only it cares about, and will be used preferentially for messages destined for it.

So, for instance, a particular GroupMgr can subclass ApianCommand, and define a deser for it, and that will be used for messages sent to it.

[jimkberry]

I'm gonna close this, and continue the work under issue #21