Hi! I’ve solved the challenge for basic topology where each node can communicate with another node. However, I am doubtful about broadcasting for a different topology.
Assuming following topology:
a => b, c, d
b => c, e
c => f, a
d => a
e => c
f => a
If b is to broadcast the message, what’s a good way of doing it? Here are my approaches:
For each neighbour, send a read RPC and check if it already received message. If true, don’t do anything, else send broadcast RPC with the message.
Challenge: When handling read, node didn’t have the message, but received it right after the reply. Now it’s receiving the same message from another node.
Can be improved if we only do a Send to the neighbours, and they handle duplicates on their end.
Setting up a new RPC to handle broadcast message receives?
The thread started by @andrewarrow was incredibly useful in understanding the quirks. The solution I used was a mix of second and third. A read RPC for all messages to see duplicate would’ve been incredibly expensive. Hence, I sent the message out, and let it be dealt with by the receiver node.
I’ll share the corner cases, their possible explanations and the relevant fixes:
Corner Cases
Sending message kept showing no handler error. This happened because the node broadcasting message sent it with type broadcast and the other node replied, but the current node didn’t handle it. A way around was to use node.RPC, and create empty handler function.
Sending message from n1 to other nodes creates an infinite loop because they’ll try sending the message back to n1 too. This is why unhandled cases saw a huge number of broadcast 0’s. They weren’t coming from the server. Instead, they happened because n1 -> n2 -> n1 -> n2 -> ...
Fix is to check for either msg_id, or find duplicate in array/ map where you stored message. If msg_id is missing or duplicate found in map, return nil.
In other cases, broadcast message to nodes that aren’t source or self.
In case something isn’t clear, please feel free to ask more questions.