Regarding the updated TestGossiper_No_Contention_Single_Retry

Regarding the updated TestGossiper_No_Contention_Single_Retry

par Stratos Triantafyllou,
Nombre de réponses : 6

I apologize if this has been already clarified in another post, I must admit I have found it difficult to keep up with the the discussions for this homework.

I understand that in the revised test, node E is also down, and A is required to send 5 messages in every phase 1 attempt. I also understand that between the start of the consensus process and when we count the number of messages that A has sent, there is around 1 second.

What I'm struggling to understand is how A is able to send 5 messages in each try. From the handout, I was under the impression that A gossips the PREPARE message, i.e. it sends it to one peer at a time. If the peer responds, A might send it to another or stop. If the peer doesn't, then A sends the message to another peer after 10 seconds. Because of the reliability of the gossip, peers that get the message from A eventually relay it to the rest of the network.

Assuming that all nodes are down, I would expect that A is going to attempt to contact one of its peers. Because the test is waiting 1 second, A is not going to contact anyone else before the paxosRetry timeout fires. Therefore, aSent should be 1 before the retry, and 2 after the retry (as it was before the change).

Am I getting something wrong?

En réponse à Stratos Triantafyllou

Re: Regarding the updated TestGossiper_No_Contention_Single_Retry

par Francesco Intoci,

Hi,

I think that we are expected to broadcast the prepare to all nodes. So node A will send the prepare to all of its neighbours nodes.

En réponse à Stratos Triantafyllou

Re: Regarding the updated TestGossiper_No_Contention_Single_Retry

par Morten Borup Petersen,
+1 on this; the broadcast should be implied in the rumor mongering (which we've been asked to rely upon). If we are required to modify the handling of outgoing prepares within a rumor message to "manually" be broadcast to all peers of a node (which the now updated test seems to expect), then this should ideally be clarified clearly by the TAs.
En réponse à Morten Borup Petersen

Re: Regarding the updated TestGossiper_No_Contention_Single_Retry

par Francesco Intoci,

I think that the rumor logic is used just to rely on the status messages exchange to keep track of the consensus

En réponse à Stratos Triantafyllou

Re: Regarding the updated TestGossiper_No_Contention_Single_Retry

par Bastien Wermeille,

Thanks for finding this particularity. As it is stated in the handout :

> All these messages are sent as rumors and they’re embedded in the rumor using a new optional field, called ExtraMessage​.

I assumed in my implementation that we only send one Rumor containing an Extra value. Such as to rely on the existing type I just added an addExtraMessage interface in the gossiper which allow to reuse the logic already implemented.

If we really want to send one message to all other node but in a private manner then we would need to have a destination field such as to filter which messages are for us. Regarding the logic of the test, I think that your explanation is correct and that we should expect one message before the retry if we use the rumor infrastructure as implemented in homework 2.

En réponse à Stratos Triantafyllou

Re: Regarding the updated TestGossiper_No_Contention_Single_Retry

par Pasindu Nivanthaka Tennage,

Hello

As we have announced, there is an issue with the bin_gossiper and some tests.

We are currently working on the changes and will be pushing the corrected code to your repos soon.

Sorry for the inconvenience.

Regards