Why or why not use RequestVote RPC as heartbeat in Raft implementation?
As introduced in the paper, we use empty AppendEntries RPC for heartbeat. Then how about the RequestVote RPC? When FOLLOWER or CANDIDATE receives RequestVote RPC call, is it suppose to reset the election timeout as well? Why or why not to do so?
One benefit in my mind is that when RequestVote RPC call also treated as heartbeat, we can potentially prevent the multiple candidates condition. Since multiple candidates may split votes and take longer time in the election stage. By using that as heartbeat, the RequestVote RPC calls from one candidate will reset the election timer so that other live peers are less likely to timeout and become a candidate as well.
algorithm distributed-computing distributed-system raft
asked Nov 26 '18 at 14:44
Diyi WangDiyi Wang
56
add a comment |
As introduced in the paper, we use empty AppendEntries RPC for heartbeat. Then how about the RequestVote RPC? When FOLLOWER or CANDIDATE receives RequestVote RPC call, is it suppose to reset the election timeout as well? Why or why not to do so?
One benefit in my mind is that when RequestVote RPC call also treated as heartbeat, we can potentially prevent the multiple candidates condition. Since multiple candidates may split votes and take longer time in the election stage. By using that as heartbeat, the RequestVote RPC calls from one candidate will reset the election timer so that other live peers are less likely to timeout and become a candidate as well.
algorithm distributed-computing distributed-system raft
asked Nov 26 '18 at 14:44
Diyi WangDiyi Wang
56
add a comment |
As introduced in the paper, we use empty AppendEntries RPC for heartbeat. Then how about the RequestVote RPC? When FOLLOWER or CANDIDATE receives RequestVote RPC call, is it suppose to reset the election timeout as well? Why or why not to do so?
One benefit in my mind is that when RequestVote RPC call also treated as heartbeat, we can potentially prevent the multiple candidates condition. Since multiple candidates may split votes and take longer time in the election stage. By using that as heartbeat, the RequestVote RPC calls from one candidate will reset the election timer so that other live peers are less likely to timeout and become a candidate as well.
algorithm distributed-computing distributed-system raft
asked Nov 26 '18 at 14:44
Diyi WangDiyi Wang
56
As introduced in the paper, we use empty AppendEntries RPC for heartbeat. Then how about the RequestVote RPC? When FOLLOWER or CANDIDATE receives RequestVote RPC call, is it suppose to reset the election timeout as well? Why or why not to do so?
One benefit in my mind is that when RequestVote RPC call also treated as heartbeat, we can potentially prevent the multiple candidates condition. Since multiple candidates may split votes and take longer time in the election stage. By using that as heartbeat, the RequestVote RPC calls from one candidate will reset the election timer so that other live peers are less likely to timeout and become a candidate as well.
algorithm distributed-computing distributed-system raft
algorithm distributed-computing distributed-system raft
asked Nov 26 '18 at 14:44
Diyi WangDiyi Wang
56
asked Nov 26 '18 at 14:44
Diyi WangDiyi Wang
56
asked Nov 26 '18 at 14:44
Diyi WangDiyi Wang
56
asked Nov 26 '18 at 14:44
Diyi WangDiyi Wang
56
asked Nov 26 '18 at 14:44
Diyi WangDiyi Wang
56
56
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Well, there’s probably not anything inherently unsafe about it. But the problem is nodes that can’t win an election can still start one. So, if a node that can’t win starts an election and requests votes from all the other nodes, resetting their timers would block the election. And since the can’t-win candidate started its timer first, it would likely also timeout and start another election first, thus blocking the cluster again, and another election, and so on.
Of course, the fix for this could be to only reset election timeouts when a vote is cast. This could be safe. After all, election timeouts are randomized anyways. But the question is whether it’s effective. It wouldn’t prevent split votes since it doesn’t stop multiple nodes from requesting votes concurrently, and during split votes it would only make the election take that much longer. I suspect the pre-vote protocol is much more efficient for that reason and probably avoids split votes as well as they can be avoided.
answered Nov 27 '18 at 1:59
kuujokuujo
4,2451717
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53483543%2fwhy-or-why-not-use-requestvote-rpc-as-heartbeat-in-raft-implementation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Well, there’s probably not anything inherently unsafe about it. But the problem is nodes that can’t win an election can still start one. So, if a node that can’t win starts an election and requests votes from all the other nodes, resetting their timers would block the election. And since the can’t-win candidate started its timer first, it would likely also timeout and start another election first, thus blocking the cluster again, and another election, and so on.
Of course, the fix for this could be to only reset election timeouts when a vote is cast. This could be safe. After all, election timeouts are randomized anyways. But the question is whether it’s effective. It wouldn’t prevent split votes since it doesn’t stop multiple nodes from requesting votes concurrently, and during split votes it would only make the election take that much longer. I suspect the pre-vote protocol is much more efficient for that reason and probably avoids split votes as well as they can be avoided.
answered Nov 27 '18 at 1:59
kuujokuujo
4,2451717
add a comment |
Well, there’s probably not anything inherently unsafe about it. But the problem is nodes that can’t win an election can still start one. So, if a node that can’t win starts an election and requests votes from all the other nodes, resetting their timers would block the election. And since the can’t-win candidate started its timer first, it would likely also timeout and start another election first, thus blocking the cluster again, and another election, and so on.
Of course, the fix for this could be to only reset election timeouts when a vote is cast. This could be safe. After all, election timeouts are randomized anyways. But the question is whether it’s effective. It wouldn’t prevent split votes since it doesn’t stop multiple nodes from requesting votes concurrently, and during split votes it would only make the election take that much longer. I suspect the pre-vote protocol is much more efficient for that reason and probably avoids split votes as well as they can be avoided.
answered Nov 27 '18 at 1:59
kuujokuujo
4,2451717
add a comment |
Well, there’s probably not anything inherently unsafe about it. But the problem is nodes that can’t win an election can still start one. So, if a node that can’t win starts an election and requests votes from all the other nodes, resetting their timers would block the election. And since the can’t-win candidate started its timer first, it would likely also timeout and start another election first, thus blocking the cluster again, and another election, and so on.
Of course, the fix for this could be to only reset election timeouts when a vote is cast. This could be safe. After all, election timeouts are randomized anyways. But the question is whether it’s effective. It wouldn’t prevent split votes since it doesn’t stop multiple nodes from requesting votes concurrently, and during split votes it would only make the election take that much longer. I suspect the pre-vote protocol is much more efficient for that reason and probably avoids split votes as well as they can be avoided.
answered Nov 27 '18 at 1:59
kuujokuujo
4,2451717
Well, there’s probably not anything inherently unsafe about it. But the problem is nodes that can’t win an election can still start one. So, if a node that can’t win starts an election and requests votes from all the other nodes, resetting their timers would block the election. And since the can’t-win candidate started its timer first, it would likely also timeout and start another election first, thus blocking the cluster again, and another election, and so on.
Of course, the fix for this could be to only reset election timeouts when a vote is cast. This could be safe. After all, election timeouts are randomized anyways. But the question is whether it’s effective. It wouldn’t prevent split votes since it doesn’t stop multiple nodes from requesting votes concurrently, and during split votes it would only make the election take that much longer. I suspect the pre-vote protocol is much more efficient for that reason and probably avoids split votes as well as they can be avoided.
answered Nov 27 '18 at 1:59
kuujokuujo
4,2451717
answered Nov 27 '18 at 1:59
kuujokuujo
4,2451717
answered Nov 27 '18 at 1:59
kuujokuujo
4,2451717
answered Nov 27 '18 at 1:59
kuujokuujo
4,2451717
4,2451717
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53483543%2fwhy-or-why-not-use-requestvote-rpc-as-heartbeat-in-raft-implementation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
