Fabric網路節點發現及成員管理
阿新 • • 發佈:2020-06-14
一個新節點通過已知的節點加入到網路中,此時,它所知的網路節點資訊是非常有限的,需要通過節點發現獲知更多的節點,建立起足夠的連線。另外,當一個新節點加入到網路時,原有網路節點也需要通過節點發現感知到新節點的加入。
分佈在各地的網路節點總是會有上線離線的變化,有這就需要Fabric網路必須動態維護一個節點成員列表,這就需要節點成員管理。
### 一、節點發現與成員管理
#### 1. 節點發現
一個節點要加入Fabric網路,必須要知道至少一個已知Fabric節點作為啟動節點。
相關配置如下:
```yaml
# Gossip related configuration
gossip:
# Bootstrap set to initialize gossip with
bootstrap: 127.0.0.1:7051
```
Fabric節點發現與成員管理流程如下圖所示:
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190403141352547.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NfbGlzaGVuZw==,size_16,color_FFFFFF,t_70)
#### 2. 網路連線層次的節點成員管理(線上,掉線)
線上節點(Peer)通過持續不斷地廣播“活著”的訊息,來表明他們的可用性。
>這一部分相當於心跳檢測,如果節點離線,就在channel成員列表中刪除節點。
#### 3. 相關訊息定義
```proto3
// AliveMessage is sent to inform remote peers
// of a peer's existence and activity
message AliveMessage {
Member membership = 1;
PeerTime timestamp = 2;
bytes identity = 4;
}
// MembershipRequest is used to ask membership information
// from a remote peer
message MembershipRequest {
Envelope self_information = 1;
repeated bytes known = 2;
}
// MembershipResponse is used for replying to MembershipRequests
message MembershipResponse {
repeated Envelope alive = 1;
repeated Envelope dead = 2;
}
```
### 二、節點間訊息傳播(Gossip)
#### 1. 訊息傳送方式:
- 點對點發送(end to end)
- gossip方式——傳送訊息時會根據訊息型別對節點進行過濾篩選(另外還會去除掉髮送節點)後再隨機(*具體實現上是隨機就近原則*)選擇$k$個節點發送訊息。
這裡採用的是push和pull方式。
#### 2. push
節點有了新訊息後,隨機選擇$k$個節點(例如,3),向它們傳送新訊息。$k$個節點收到後,繼續隨機選擇$k$個節點發送新資訊,直到所有節點都知道該新資訊。
#### 3. pull
所有節點週期性的隨機選取$k$個(預設配置=3)個節點,向它們獲取資料。Fabric中gossip協議pull操作如下:
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190403141738836.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NfbGlzaGVuZw==,size_16,color_FFFFFF,t_70)
```Go
/* PullEngine is an object that performs pull-based gossip, and maintains an internal state of items
identified by string numbers.
The protocol is as follows:
1) The Initiator sends a Hello message with a specific NONCE to a set of remote peers.
2) Each remote peer responds with a digest of its messages and returns that NONCE.
3) The initiator checks the validity of the NONCEs received, aggregates the digests,
and crafts a request containing specific item ids it wants to receive from each remote peer and then
sends each request to its corresponding peer.
4) Each peer sends back the response containing the items requested, if it still holds them and the NONCE.
Other peer Initiator
O <-------- Hello ------------------------- O
/|\ --------- Digest <[3,5,8, 10...], NONCE> --------> /|\
| <-------- Request <[3,8], NONCE> ----------------- |
/ \ --------- Response <[item3, item8], NONCE>-------> / \
*/
```
###### 4. pull相關訊息定義
```proto
// GossipHello is the message that is used for the peer to initiate
// a pull round with another peer
message GossipHello {
uint64 nonce = 1;
bytes metadata = 2;
PullMsgType msg_type = 3;
}
// DataDigest is the message sent from the receiver peer
// to the initator peer and contains the data items it has
message DataDigest {
uint64 nonce = 1;
repeated bytes digests = 2; // Maybe change this to bitmap later on
PullMsgType msg_type = 3;
}
// DataRequest is a message used for a peer to request
// certain data blocks from a remote peer
message DataRequest {
uint64 nonce = 1;
repeated bytes digests = 2;
PullMsgType msg_type = 3;
}
// DataUpdate is the final message in the pull phase
// sent from the receiver to the initiator
message DataUpdate {
uint64 nonce = 1;
repeated Envelope data = 2;
PullMsgType msg_type =