乙太坊網路消息傳遞
我正在嘗試圍繞乙太坊的網路方面“加入點點滴滴”。從文件看來，底層協議是RLPx，它為ÐΞVp2p Wire Protocol提供支持。
儘管 TCP 提供了一種面向連接的媒介，但 DΞVp2p 節點以數據包的形式進行通信。RLPx 提供了發送和接收數據包的功能。
在 RLPx 文件中有一個切線的說法是它使用RLP。
數據包是動態成幀的，以 RLP 編碼的標頭為前綴，經過加密和驗證。多路復用是通過指定數據包目標協議的幀頭實現的。
ÐΞVp2p 有線協議反過來支持乙太坊有線協議是其中之一的子協議。
來自 ÐΞVp2p 文件：
ÐΞVp2p 旨在支持基本有線協議上的任意子協議（又名能力）。
來自乙太坊文件：
執行乙太坊客戶端的節點之間的點對點通信使用底層 ÐΞVp2p Wire Protocol 執行。
問題：
- 您能否解釋一下，乙太坊子協議在哪裡/如何插入 DΞVp2p 協議？
- SDK 的 API（比如Javascript）可以映射到乙太坊子協議消息 ID 嗎？
- 或者，消息 ID 的映射是否僅限於Geth等客戶端？
我在 gitter.im 頻道上寫了這篇文章，所以不管怎樣，它又來了。需要注意的是，我沒有查看最近的 geth 程式碼，因此可能與實際情況存在細微差異。
一個關鍵段落是這個“消息 ID 被假定為從 ID 0x10 開始是緊湊的（0x00-0x10 保留給 DΞVp2p 消息）並按字母順序分配給每個共享（相同版本，相同名稱）子協議。子協議未共享的將被忽略。如果多個版本共享相同（同名）子協議，則數值最高的獲勝，其他版本將被忽略。
基本上，DevP2P 消息都由它們的類型標識，即第一個整數。
第一個 0x0F(?) 為 DevP2P 消息保留，在 DevP2P-Wire-Protocol 文件中指定。
下一個消息 ID 似乎取決於這對對等點通常支持的協議。通常，我的意思是共享。
對等體共享的子協議在Hello消息（0x00）中建立，與此相關的文件中的關鍵片語是“cap指定對等體能力名稱為長度為3的ASCII字元串。目前支持的能力是eth，shh。 "
因此，假設 Hello 消息之後的兩個對等點僅支持“eth”，那麼根據 Ethereum 有線協議文件，下一個消息標識符是偏移量 + 0x00 用於乙太坊“狀態”消息（使其成為 0x10）
對於您的問題，“假設，我想引入一個新的子協議”，我認為以上回答了這個問題。您需要創建一個新的 3 字母標識符（如 ETH、LES、SHH）並將其作為您的 DevP2P 客戶端中的一項功能進行宣傳。客戶會握手並在 Hello 消息中確定他們擁有您的 ??? 共同的協議，這將成為消息 id 空間的一部分。
因此，總而言之：“子協議”是由 3 個字母名稱標識的消息 id 空間。對等方握手並在 Hello 消息中指定它們支持的子協議。對於這種 p2p 關係，通用協議按字母順序排列，並且在發送消息時，它們的標識符是相對於按字母順序排列的消息 id 空間的消息 id 空間開始的偏移量。