CS-438: Clarifications for CallbackPacket and Promise

Hello,

I had a look again in the packets.go file and found a class named callbackPacket. However, I didn't found anything about it in the handout. Could you clarify it's aim ?

Regarding the promise info in the handouts, it's written at some point, "sends a PROMISE back to the proposer". I assumed that we use the rumor message to do so like for all other PaxosMessageType and that the receiver take this message into account only if IDp is equal to the value the node has just proposed. Is it correct or should we implement something different on the receiver side to send only to the sender ?

Finally, for the learner system, should we learn a value when we receive n/2+1 accept message with the same ID even if we didn't promise this ID before ?

Thanks in advance for your answers.

Best regards,

Bastien

Re: Clarifications for CallbackPacket and Promise

par Pasindu Nivanthaka Tennage, lundi, 7 décembre 2020, 12:09

Hello,

1. I had a look again in the packets.go file and found a class named callbackPacket. However, I didn't find anything about it in the handout. Could you clarify it's aim ?

CallbackPacket is only used for sending the packets to the frontend, gui. Since we do not have a GUI for HW3, you can safely ignore that

2. Regarding the promise info in the handouts, it's written at some point, "sends a PROMISE back to the proposer". I assumed that we use the rumor message to do so like for all other PaxosMessageType and that the receiver take this message into account only if IDp is equal to the value the node has just proposed. Is it correct or should we implement something different on the receiver side to send only to the sender ?

You are correct, rumors should be used to send/receive all the PREPARE, PROMISE, PROPOSE, ACCEPT messages, and there should not be any other overlay functionality than Rumors (do not implement something different in the receiver side)

3. Finally, for the learner system, should we learn a value when we receive n/2+1 accept message with the same ID even if we didn't promise this ID before ?

Yes, correct

Re: Clarifications for CallbackPacket and Promise

par Bastien Wermeille, lundi, 7 décembre 2020, 15:05

Great thank you for those responses.

I have still some troubles to make some tests pass and after digging a bit with some log I found out that some statusPacket received from the binGossiper do not keep track of the RumorMessages sent to them. Here are some logs :

> I : message_send.go:57 (gossip.(*Gossiper).SendMessageTo) - Send prepare to 127.0.0.1:48882
> BINGOSSIP:acceptor.go:88[0m[36m >[0m message received from 127.0.0.1:48610: (jdmiaikfechhekjkibak.Pefofjpommakgllpfddc) {PaxosSeqID:0 ID:0} [36mID=[0m127.0.0.1:48882 [36mtype=[0macceptor
>BINGOSSIP:acceptor.go:187[0m[36m >[0m promising to 127.0.0.1:48610 with value {0 [] [] } [36mID=[0m127.0.0.1:48882 [36mtype=[0macceptor
> I : message_handle.go:224 (gossip.(*MessageHandler).handlePacket) - PAXOS_PROMISE origin NB---TestBinGossiper_No_Contention_Block_Consensus from 127.0.0.1:48882 ID -1 contents 0
> I : message_handle.go:229 (gossip.(*MessageHandler).handlePacket) - RUMOR origin NB---TestBinGossiper_No_Contention_Block_Consensus from 127.0.0.1:48882 ID 1 contents
> I : message_handle.go:238 (gossip.(*MessageHandler).handlePacket) - STATUS from 127.0.0.1:48882 peer NB---TestBinGossiper_No_Contention_Block_Consensus nextID 2

As you can see on the statusPacket receive on the last line, we are missing the status indicating that this gossiper received the prepare packet we just send him from NA---TestBinGossiper_No_Contention_Block_Consensus.

Do you have any idea why this is happening ?

Thanks in advance.

Re: Clarifications for CallbackPacket and Promise

par Pasindu Nivanthaka Tennage, mercredi, 9 décembre 2020, 12:38

Hi Bastien,

We debugged the issue you pointed out, but unfortunately we were not able to reproduce your error. We observe that our bin_gossiper is sending and receiving correct Rumor/Status messages.

In order to debug this further, can you please provide some additional information?

Regards

Re: Clarifications for CallbackPacket and Promise

par Bastien Wermeille, vendredi, 11 décembre 2020, 17:37

Solution solved ! Thanks for the help Cristina.

WARNING, be sure to have the latest version of the binGossip in your repo, I did a git pull from master but there seems to be a problem which led me to still have the older version.

Re: Clarifications for CallbackPacket and Promise

par Francesco Intoci, lundi, 7 décembre 2020, 15:59

Hello Pasindu,

I manage to pass all the tests, but I have a slightly different implementation from the one you proposed. Taking in account that we have a fully connected topology, I implemented the sending of prepares, accepts and TLCs as broadcast messages, while the promises as unicast messages to the sender(instead of relying on the rumor logic for spreading the message). Furthermore, in order to reduce the amount of traffic in the network, I decided to process as Rumor Messages (so update the list of rumors in the status, adding addresses to routing tables, ecc...) just TLCs messages. Shall I modify my implementation? If so, should I send for example a prepare to a random node and wait for the status messages exchange logic to kick in for delivering the message to all other nodes?

Thanks,

Francesco

Re: Clarifications for CallbackPacket and Promise

par Francesco Intoci, lundi, 7 décembre 2020, 16:11

P.S: To make my question more clear: I do use Rumor Messages to wrap the Paxos Messages, but I won't use Rumor logic functionalities for them, excluding the case of TLCs messages, which will be treated as standard Rumors

Re: Clarifications for CallbackPacket and Promise

par Pasindu Nivanthaka Tennage, mardi, 8 décembre 2020, 11:26

Hello Intoci,

In this case, your implementation is incorrect, because in the handouts we mentioned that all packets (Paxos, TLC) should be sent/received using Rumors/Status. So yes, you will have to modify your implementation.

Regarding how to handle Rumors, it is the same logic you implemented in homework 1. We enforce that you do not add any other functionality to Rumor layer, but treat is as a complete overlay.

Hope this helps

Regards