Communication Buses

[deontologician]

Communication buses are how information will be sent around the spaceship.

Both "real" and simulated data will be sent over the buses.

• Real data consists of logging messages and notifications from various components that are being broadcast. This includes commands, requests, and general alerts. Real data is considered negligible in size and won't consume any bandwidth
• Simulated data consists of game-relevant data transmission. Things like telemetry data, backups, etc. These messages will have a "size" parameter, which will affect their transmission speed due to bandwidth restrictions on buses. The size parameter simulates a real payload.

Buses are laid out in a hierarchy (a tree). Each Bus will have a name based on its position in the hierarchy. Take the following example:

A -- B -- C
|    |
|    + -- D
|
+ -- E -- F
     |
     + -- G

The full path names will be: /A /A/B /A/B/C /A/B/D /A/E/F /A/E/G If you try to attach G and F, they will not, saying they both already have parents. If you try to attach G and A, they will not, saying that G and A are already attached

A message sent from G should go through E. E should send it both to F and to A

At each Bus in the chain, the Bus checks all of its subscribers to see if any are interested in the message. If so, it sends the message to that subscriber. The subscriber gives a pattern which is matched against the message's topic.

[deontologician]

Current issues involves rebroadcasting downwards. Messages are broadcast up the chain, but won't make it to siblings.

Assuming the diagram above, see what happens when A/E/G broadcasts:

1. A/E receives the broadcast, sends to A and to A/E/F (assume it's easy to skip A/E/G)
2. A/E/F receives the broadcast
3. A receives the broadcast, sends to A/B and to A/E
4. A/B receives the broadcast, sends to A, A/B/C, and A/B/D
5. All kinds of echoing going on without end

So, there needs to be a rule to decide when to rebroadcast and it needs to rule out 3 different recipients:

1. The original broadcaster (simple path comparison should work)
2. A node that's already seen the message.

Here are some rules that might stop rebroadcasting in the above example:

1. A/E should not broadcast to A/E/G because the sender of the message is a prefix of A/E/G
2. A/E should broadcast to A despite a being a sender prefix, because A/B is a more specific sender prefix (it's closer)
3. A should not broadcast to A/E because A/E is a prefix of the sender A/E/G
4. B should not broadcast to A because A is a prefix of the sender A/E/G
5. A/B/D should not broadcast to A/B because you only broadcast to parent nodes if you are a prefix of the sender.

So in summary, here's my suggested rules:

1. send to parent nodes only if you are a prefix of the sender (meaning you're closer to the sender than your parent)
2. send only to children nodes who are not a prefix of the sender