Create a method for reliable message-delivery over the network. We will call this message-broadcast.
:: Context
[nearcasting]
Currently, we have a message nearcasting capability. This messaging fits within a single process. It is simple to achieve consensus here:
We have multiple messaging nodes, working within a single thread. We call these cogs.
We have a thing-that-can-distribute-message-sequences. We call this the orb.
Cogs send aspiring-messages to the orb.
The orb pushes canonical-messages to cogs.
In practice, all aspiring messages become canonical messages unless there is a process crash. We do not have to think hard about whose message gets to come first, because messaging happens within a simple cooperative-multitasking context.
[broadcasting]
Consensus over broadcast is harder.
We have multiple nodes, running in different threads on different hosts. We do not yet have a name for these. For the moment, I will call them Plants.
We have a thing that receives aspiring messages and which emits canonical messages. We do not yet have a name for this thing. For the moment, I will call it a Consensus Engine.
Plants send aspiring-messages into the Consensus Engine.
The Consensus Engine orders aspiring-messages into a canonical order, and sends them back to Plants.
[new] There is a tidy method for doing late-starts on Plants. When a Plant is late-started, it connects to the Consensus Engine, consumes all of the messages for the day until it is caught up, and then continues to run as though it has been running all day.
[new] If parts of the Consensus Engine collapse, the rest of the Consensus Engine seamlessly picks up the slack so that the whole is not interrupted.
:: Structuring the work
It would be foolhardy to head into this without first having a protocol-buffer technique worked out. Hence, get issue #124 clear before going deep on this.
We should be careful to think about these concepts independently of one another,
A carrier layer. This will be a layer for carrying messages over a network. This could be done in protocol buffers, but it could equally be one by redis.
A message layer. This is to do with a schema of messages as understood by the application layer.
The lingo of 'carrier layer' and 'message layer' is ad hoc, and not drawn from an external resource.
The first one is about ordered delivery of bytes. The second one is about ordered delivery of messages which are composed of the bytes. The reason this is important: it should not be necessary for the consensus engine to understand the messaging schema. At this point, something like apache kafka may be viable as a consensus engine. I would not want to "just use kafka" though. I would want to have a clear understanding of the options, and possibly to be able to switch in different types of consensus engine depending on the throughput, latency and redundancy demands of different domains.
:: Goal
Create a method for reliable message-delivery over the network. We will call this message-broadcast.
:: Context
[nearcasting]
Currently, we have a message nearcasting capability. This messaging fits within a single process. It is simple to achieve consensus here:
We have multiple messaging nodes, working within a single thread. We call these cogs.
We have a thing-that-can-distribute-message-sequences. We call this the orb.
Cogs send aspiring-messages to the orb.
The orb pushes canonical-messages to cogs.
In practice, all aspiring messages become canonical messages unless there is a process crash. We do not have to think hard about whose message gets to come first, because messaging happens within a simple cooperative-multitasking context.
[broadcasting]
Consensus over broadcast is harder.
We have multiple nodes, running in different threads on different hosts. We do not yet have a name for these. For the moment, I will call them Plants.
We have a thing that receives aspiring messages and which emits canonical messages. We do not yet have a name for this thing. For the moment, I will call it a Consensus Engine.
Plants send aspiring-messages into the Consensus Engine.
The Consensus Engine orders aspiring-messages into a canonical order, and sends them back to Plants.
[new] There is a tidy method for doing late-starts on Plants. When a Plant is late-started, it connects to the Consensus Engine, consumes all of the messages for the day until it is caught up, and then continues to run as though it has been running all day.
[new] If parts of the Consensus Engine collapse, the rest of the Consensus Engine seamlessly picks up the slack so that the whole is not interrupted.
:: Structuring the work
It would be foolhardy to head into this without first having a protocol-buffer technique worked out. Hence, get issue #124 clear before going deep on this.
We should be careful to think about these concepts independently of one another,
A carrier layer. This will be a layer for carrying messages over a network. This could be done in protocol buffers, but it could equally be one by redis.
A message layer. This is to do with a schema of messages as understood by the application layer.
The lingo of 'carrier layer' and 'message layer' is ad hoc, and not drawn from an external resource.
The first one is about ordered delivery of bytes. The second one is about ordered delivery of messages which are composed of the bytes. The reason this is important: it should not be necessary for the consensus engine to understand the messaging schema. At this point, something like apache kafka may be viable as a consensus engine. I would not want to "just use kafka" though. I would want to have a clear understanding of the options, and possibly to be able to switch in different types of consensus engine depending on the throughput, latency and redundancy demands of different domains.