Get desktop application:
View/edit binary Protocol Buffers messages
* AppendEntries RPC: replicate log entries to a follower.
(message has no fields)
* ID of leader (caller), so the follower can redirect clients.
* Caller's term.
* ID of entry preceding entries, or ID of last log entry for heartbeat.
* Term of prev_log_index.
* Log entries for follower to store, or empty for heartbeat.
* Last committed entry that the follower has, so the follower can advance its state machine.
* Callee's term, for the caller to update itself.
* True if new entries were added to the log.
* The recipient's last log index (after it's applied this RPC's changes to the log). This is used to speed up finding the correct value for nextIndex with a follower that is far behind the leader.
* Sent back to inform leader of what code the recipient is running.
Used in:
* The server's state machine can behave like all state machine versions between min_supported_state_machine_version and max_supported_state_machine_version, inclusive.
* The server's state machine can behave like all state machine versions between min_supported_state_machine_version and max_supported_state_machine_version, inclusive.
* A stable or transitional configuration.
Used in: ,
* The servers in a stable configuration, or the old servers in a transitional configuration.
* Not present in a stable configuration, or the new servers in a transitional configuration.
* Log entry.
Used in:
* The term in which the entry was first created.
* The index for the entry. It's truly optional (if you receive an entry over the network, you shouldn't rely on this). It's used for followers to check that they've got the entry at the right index and also used internally in some storage backends such as SegmentedLog.
* Roughly the number of nanoseconds the cluster has had a leader. This gets passed onto state machines, where it's used for cleaning up client sessions. See ClusterClock for more details.
* See EntryType.
the following are mutually exclusive, depending on 'type'
* A Configuration to be used internally by the consensus module.
* A command to be processed by the state machine.
* The type of payload stored in a log entry.
Used in:
* This must be the first value in the enum and is never assigned explicitly. If new values are added, old code will see them as set and equal to this value (though they will still serialize to the correct value).
* Stores a 'Configuration', to be used internally by the consensus module.
* Stores a command to be processed by the state machine.
* No op.
* The type of "service-specific error" replies that this service returns.
No errors are defined. enum Code { }; required Code error_code = 1;
(message has no fields)
* InstallSnapshot RPC: replicate part of a snapshot file to a follower.
(message has no fields)
* ID of leader (caller), so the follower can redirect clients.
* Caller's term.
* The snapshot covers log entries in the range [1, lastSnapshotIndex]. While this information can be found in the snapshot itself, a follower may want to know sooner (for example, to name the snapshot file or to assert that it's not overwriting something more important).
* The byte offset where 'data' belongs in the file. Followers can expect this to grow without gaps, but they should use this to drop duplicate request messages.
* Raw bytes of the snapshot file. This should be big enough to achieve reasonable throughput without having to pipeline RPCs.
* Set to true if this is the last chunk of the file and the follower should now load the contents; false otherwise.
* Explains which version of this RPC the leader (caller) supports. - Servers speaking version 1 of this RPC (corresponding to LogCabin release v1.0.0 and up to a few weeks after) did not set this field. - Version 2 introduced the bytes_stored field in responses. Before this, leaders assumed that InstallSnapshot always succeeded if the term matched.
* Callee's term, for the caller to update itself.
* The total number of bytes in the snapshot that the follower has stored (after applying the request). This was introduced to fix https://github.com/logcabin/logcabin/issues/174 . Before, followers could only receive snapshot chunks in sequence. If they restarted, they'd have discarded their previous chunks and they would just repeatedly PANIC. This is now used to signal to the leader how many bytes the follower actually has saved. The leader considers the snapshot transfer complete when bytes_stored equals the full size of the snapshot. The leader should use bytes_stored as the value for byte_offset in the next request (most importantly, when a follower reboots, it returns 0 here and the leader starts at offset 0 in the next request). Leaders that do not support InstallSnapshot version 2 entirely ignore this field.
* Identifies which RPC is being executed.
Keep these numbers dense.
* RequestVote RPC: ask a server for its vote in an election and/or get a server's log information.
(message has no fields)
* ID of the caller, so that if it re-requests the vote from the callee, the server will respond granted.
* Caller's term.
* Term of last entry in caller's log. Used to compare log completeness.
* ID of last entry in caller's log. Used to compare log completeness.
* Callee's term, for caller to update itself.
* True if the follower granted the candidate its vote, false otherwise.
* Set to true if the caller's log is as up-to-date as the recipient's. This isn't presently used, but it's easy to return and might be useful later. In the Pre-Vote extension to Raft described in Section 9.6 "Preventing disruptions when a server rejoins the cluster" of Diego Ongaro's PhD dissertation, a server needs to know if its log is sufficient to get elected before actually starting an election.
* A server in a configuration.
Used in:
* The ID of the server.
* The network address(es) of the server (comma-delimited).
* A stable configuraton, in which a simple majority constitutes a quorum.
Used in: