Method Send

conn/node.go:239–269

Send sends the given RAFT message from this node.

(msg *raftpb.Message)

// Send sends the given RAFT message from this node.
func (n *Node) Send(msg *raftpb.Message) {
	x.AssertTruef(n.Id != msg.To, "Sending message to itself")
	data, err := msg.Marshal()
	x.Check(err)

	if glog.V(2) {
		switch msg.Type {
		case raftpb.MsgHeartbeat, raftpb.MsgHeartbeatResp:
			atomic.AddInt64(&n.heartbeatsOut, 1)
		case raftpb.MsgReadIndex, raftpb.MsgReadIndexResp:
		case raftpb.MsgApp, raftpb.MsgAppResp:
		case raftpb.MsgProp:
		default:
			glog.Infof("RaftComm: [%#x] Sending message of type %s to %#x", msg.From, msg.Type, msg.To)
		}
	}
	// As long as leadership is stable, any attempted Propose() calls should be reflected in the
	// next raft.Ready.Messages. Leaders will send MsgApps to the followers; followers will send
	// MsgProp to the leader. It is up to the transport layer to get those messages to their
	// destination. If a MsgApp gets dropped by the transport layer, it will get retried by raft
	// (i.e. it will appear in a future Ready.Messages), but MsgProp will only be sent once. During
	// leadership transitions, proposals may get dropped even if the network is reliable.
	//
	// We can't do a select default here. The messages must be sent to the channel, otherwise we
	// should block until the channel can accept these messages. BatchAndSendMessages would take
	// care of dropping messages which can't be sent due to network issues to the corresponding
	// node. But, we shouldn't take the liberty to do that here. It would take us more time to
	// repropose these dropped messages anyway, than to block here a bit waiting for the messages
	// channel to clear out.
	n.messages <- sendmsg{to: msg.To, data: data}
}

// Snapshot returns the current snapshot.
func (n *Node) Snapshot() (raftpb.Snapshot, error) {