Clarification on Test_HW1_Messaging_Broadcast_Rumor_Three_Nodes_No_ContinueMongering

Clarification on Test_HW1_Messaging_Broadcast_Rumor_Three_Nodes_No_ContinueMongering

by David Howard Neill -
Number of replies: 2

I'm confused about the behavior expected by the test `Test_HW1_Messaging_Broadcast_Rumor_Three_Nodes_No_ContinueMongering`.

Here's the test description:


// Given the following topology:

//   A -> B -> C

// If A broadcast a message, then B should receive it AND then send it to C. C

// should also update its routing table with a relay to A via B. We're setting

// the ContinueMongering attribute to 0.


When C receives A's rumor from B, it should send an acknowledgment back to "the source" (task 2). I interpreted this as C should send the acknowledgment back to B, since B constructed a new RumorsMessage containing the rumors it got from A. So B is both the source and the relay for the RumorMessage that C received. Since C sees a message from B and relayed by B, C adds {"B":"B"} to the routing table. Later, C will add the entry {"A":"B"} when processing the rumor.

However, C must have B in its relay table in order to Unicast the AckMessage back to B. But the test expects the following relay table for C:

{"127.0.0.1:1":"127.0.0.1:2", "127.0.0.1:3":"127.0.0.1:3"}

So clearly my interpretation of the peer's behavior is wrong. Here are a few possible correct interpretations:

  1. B should not construct a new RumorsMessage, but just resend the one it got from A (and update the RelayedBy field). When C receives the message, it should update the relay table to {"A": "B"}. C then unicasts the ack back to A (the source).
  2. Same as 1, but C unicasts the ack back to B (the relay). This means that Unicast should allow sending messages to an arbitrary destination, even if it is not in the routing table.
  3. Same as 1, but C uses the socket directly to send the ack to B. Again, this means we are allowed to send messages to unknown destinations, but Unicast can still prevent these cases.

I think option 3 seems the most reasonable, but I'm not sure which is correct. Option 2 seems to break an implicit assumption that Unicast should only work on know peers. Option 3 leads to a lot of communication because every peer will send an ack back to A, even though A is only expecting a single ack from a neighbor.

Thanks for your time and sorry for the wall of text! I wanted to make sure the question is clear. :)

In reply to David Howard Neill

Re: Clarification on Test_HW1_Messaging_Broadcast_Rumor_Three_Nodes_No_ContinueMongering

by Yifei Li -
Hi,

You could check this discussion https://moodlearchive.epfl.ch/2021-2022/mod/forum/discuss.php?d=65266. Somehow the test assumes the routing table is only updated by the logic in the RumorsCallback. But for me, it seems quite natural to firstly add the RelayBy of any received packet to Routing Table.
In reply to Yifei Li

Re: Clarification on Test_HW1_Messaging_Broadcast_Rumor_Three_Nodes_No_ContinueMongering

by David Howard Neill -
Thanks for the link, I followed the thread and was able to get the test to pass.

For anyone looking at this in the future, the right interpretation seems to be:

  • Peers should only update the routing table when processing rumors, NOT every time they receive a message. When sending acks, status messages, or any other messages between neighbors, do not use Unicast but send directly through the socket without checking whether the peer is in the routing table.