摘要：要完成這些，實現(xiàn)必須支持中繼，雖然它應(yīng)該是可選的，并且能夠被終端用戶關(guān)閉連接中繼應(yīng)該作為傳輸來實現(xiàn)，以便對上層透明中繼的實現(xiàn)，可參考啟用多種網(wǎng)絡(luò)拓撲不同的系統(tǒng)有不同的需求，進而導致不同的拓撲結(jié)構(gòu)。

目前進度為80%, 持續(xù)更新...

在開發(fā)IPFS（星際文件系統(tǒng)）的過程中，我們遇到了很多在異構(gòu)設(shè)備之上運行分布式文件系統(tǒng)所帶來的若干挑戰(zhàn)，這些設(shè)備具有不同的網(wǎng)絡(luò)設(shè)置和能力。在這個過程中，我們必須重新審視整個網(wǎng)絡(luò)堆棧和詳細的解決方案，以克服由多個網(wǎng)絡(luò)層級和多種協(xié)議設(shè)計所施加的障礙，而不打破兼容性或再造技術(shù)。

為了構(gòu)建這個庫，我們專注于獨立解決問題，創(chuàng)建具有復雜抽象的復雜的解決方案，當把關(guān)注點進行組合時，可以為P2P對等應(yīng)用程序提供一個可靠的工作環(huán)境。

1.1 動機
libp2p 是我們建立分布式系統(tǒng)的集體經(jīng)驗的結(jié)果，因為它對開發(fā)者負責，決定他們希望應(yīng)用程序如何與網(wǎng)絡(luò)中的其他人進行交互，并支持配置和可擴展性，而不是對網(wǎng)絡(luò)SETU做出假設(shè)。P.

本質(zhì)上，使用LIPP2P的對等體應(yīng)該能夠使用各種不同的傳輸來與另一個對等體通信，包括連接中繼，以及在不同的協(xié)議上進行協(xié)商，按需協(xié)商。

libp2p 規(guī)范及其實現(xiàn)的目標是：
允許使用各種:
傳輸協(xié)議: TCP、UDP、SCTP、UDT、UTP、QIC、SSH等
認證傳輸協(xié)議：TLS，DTLS，CurveCP，SSH等
高效使用套接字（連接重用）
使對等體之間的通信在一個套接字上復用（避免握手開銷）
使用協(xié)商過程使多種協(xié)議和不同協(xié)議版本在對等體之間使用
向后兼容
能在現(xiàn)有系統(tǒng)中工作
利用當前網(wǎng)絡(luò)技術(shù)的全部能力
有 NAT 穿透功能
允許中繼連接
啟用加密通道
有效利用底層傳輸（例如本地流復用、本地AUTH等）。

?本節(jié)向讀者介紹了網(wǎng)絡(luò)棧的可用協(xié)議和體系結(jié)構(gòu)。我們的目標是提供推斷結(jié)論的基礎(chǔ)，并理解為什么 libp2p 提出了這些需求和體系結(jié)構(gòu).

客戶端-服務(wù)器模型表明信道兩端的雙方具有不同的角色，它們支持不同的服務(wù)和/或具有不同的能力，或者換句話說，他們講不同的協(xié)議。

構(gòu)建客戶機-服務(wù)器應(yīng)用程序成為主流趨勢有以下幾個原因:
數(shù)據(jù)中心內(nèi)部的帶寬遠遠高于客戶端可以互相連接的帶寬。
數(shù)據(jù)中心資源相當便宜，由于有效的使用和散裝備貨。
開發(fā)人員和系統(tǒng)管理員更容易對應(yīng)用程序進行細粒度的控制。
減少了要處理的異構(gòu)系統(tǒng)的數(shù)量（雖然這個數(shù)字仍然相當可觀）。
像NAT這樣的系統(tǒng)使得客戶機很難彼此查找并進行通信，迫使開發(fā)者執(zhí)行非常聰明的hack來穿透這些障礙
Protocols started to be designed with the assumption that a developer will create a client-server application from the start.

我們甚至學會了如何使用Internet上的網(wǎng)關(guān)隱藏分布式系統(tǒng)的所有復雜性，使用協(xié)議來執(zhí)行點對點操作（如HTTP），使得應(yīng)用程序不透明地查看和理解每一次調(diào)用的服務(wù)調(diào)用級聯(lián).

libP2P提供了一種從客戶端-服務(wù)器偵聽器向撥號器偵聽器交互的方法，其中不隱含哪些實體、撥號器或偵聽器具有哪些能力或能夠執(zhí)行哪些操作?，F(xiàn)在在兩個應(yīng)用程序之間建立連接是一個需要解決的多層問題，并且這些連接不應(yīng)該有目的偏向，而應(yīng)該支持多個其他協(xié)議來工作在已建立的連接之上。在客戶機-服務(wù)器模型中，發(fā)送來自客戶端的先前請求的服務(wù)器被稱為推送模型，它通常會增加更多的復雜性；相比之下，在撥號偵聽器模型中，兩個實體可以獨立地執(zhí)行請求。

在深入到LIPP2P協(xié)議之前，重要的是了解已經(jīng)廣泛使用和部署的協(xié)議的多樣性，這有助于維護今天的簡單抽象。例如，當我們考慮HTTP連接時，人們可能天真地認為HTTP/TCP/IP是涉及的主要協(xié)議，但實際上更多的協(xié)議參與進來，這取決于使用情況、涉及的網(wǎng)絡(luò)等。諸如DNS、DHCP、ARP、OSPF、以太網(wǎng)、802.11（Wi-Fi）等許多協(xié)議都涉及進來。看看ISPs內(nèi)部網(wǎng)絡(luò)，會發(fā)現(xiàn)更多的信息.

此外，值得注意的是，傳統(tǒng)的7層OSI模型表征不適合于 libp2p. 作為替代的是，我們基于它們的角色來分類協(xié)議，即它們解決的問題。OSI模型的上層面向應(yīng)用之間的點對點鏈路，而 libp2p 協(xié)議在各種不同的安全模型下更傾向于具有不同功能，不同大小的網(wǎng)絡(luò)。不同的 libp2p 協(xié)議可以具有相同的角色（在OSI模型中，這將是“地址相同的層”），這意味著多個協(xié)議可以同時運行，所有處理一個角色（而不是傳統(tǒng)的OSI堆疊中的每層協(xié)議）。例如，Bootstrap列表、mDNS、DHT發(fā)現(xiàn) 和 PEX 都是“對等發(fā)現(xiàn)”的形式，它們可以共存甚至協(xié)同。

2.2.1 構(gòu)建物理鏈接

Ethernet
Wi-Fi
Bluetooth
USB

2.2.2 尋址機器或進程
IPv4
IPv6
Hidden addressing, like SDP

2.2.3 發(fā)現(xiàn)對等節(jié)點或服務(wù)?ARP
DHCP
DNS
Onion

2.2.4 通過網(wǎng)絡(luò)路由消息
RIP(1, 2)
OSPF
BZGP
PPP
Tor
I2P
cjdns??2.2.5 傳輸?TCP?UDP
UDT
QUIC
WebRTC data channel

2.2.6 應(yīng)用程序之間協(xié)商一致的通信語義
RMI
Remoting
RPC
HTTP

?雖然我們目前有一系列的協(xié)議可供我們的服務(wù)進行通信，但解決方案的豐富性和多樣性也產(chǎn)生了自身的問題。目前，應(yīng)用程序難以通過多種傳輸機制（例如，在瀏覽器應(yīng)用程序中缺少TCP/UDP棧）來支持和使用。

也沒有“存在性鏈接”，這意味著沒有一個對等體在多個傳輸中聲明自己的概念，因此其他對等體可以保證它總是相同的對等體。

?

?libp2p 是不依賴具體傳輸機制的，所以它可以運行在任何傳輸協(xié)議上。它甚至不依賴于IP，它可以運行在NDN、XI和其他新的互聯(lián)網(wǎng)體系結(jié)構(gòu)之上.

為了支持不同類型的傳輸機制，libp2p 使用 multiaddr，一種自描述尋址格式。這使得 libp2p 能夠在系統(tǒng)中任意地處理地址，并且支持網(wǎng)絡(luò)層中的各種傳輸協(xié)議。libp2p 中地址的實際格式是
ipfs-addr，以IPFS節(jié)點ID結(jié)束的 multi-addr。例如，這些都是有效的 ipfs-addrs：

# IPFS over TCP over IPv6 (typical TCP)
/ip6/fe80::8823:6dff:fee7:f172/tcp/4001/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

# IPFS over uTP over UDP over IPv4 (UDP-shimmed transport)
/ip4/162.246.145.218/udp/4001/utp/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

# IPFS over IPv6 (unreliable)
/ip6/fe80::8823:6dff:fee7:f172/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

# IPFS over TCP over IPv4 over TCP over IPv4 (proxy)
/ip4/162.246.145.218/tcp/7650/ip4/192.168.0.1/tcp/4001/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

# IPFS over Ethernet (no IP)
/ether/ac:fd:ec:0b:7c:fe/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

注意：當前，尚不存在不可靠的實現(xiàn)。定義和使用不可靠傳輸?shù)膮f(xié)議接口尚未定義。有關(guān)不可靠VS可靠傳輸?shù)母嘈畔?，請參見此處。在WebRTC的上下文中，在 這里 輸入 CTRL+F搜索“可靠”。

libp2p 協(xié)議是多個協(xié)議的集合。為了節(jié)省資源，并使連接更容易，libp2p 可以通過一個端口，如TCP或UDP端口，根據(jù)所使用的傳輸來執(zhí)行其所有操作。libp2p 可以通過點到點連接來復用它的許多協(xié)議。這種復用是用于可靠的流和不可靠的數(shù)據(jù)報。

libp2p 比較務(wù)實。它試圖在盡可能多的配置中使用，以模塊化和靈活的方式來適應(yīng)各種用例，并盡可能少地選擇。因此，libp2p 網(wǎng)絡(luò)層提供了我們松散地稱之為“多重多路復用”的內(nèi)容:

多個網(wǎng)絡(luò)接口的多路復用

多個傳輸協(xié)議的多路復用

多個對等連接的多路復用

可以復用多個客戶端協(xié)議

每個協(xié)議/連接可以多路復用多個流（SPDY、HTTP2、QIC、SSH）

流量控制（背壓，公平性）

用不同的臨時密鑰加密每個連接

舉個例子，假設(shè)一個IPFS節(jié)點：

偵聽特定的TCP/IP地址

偵聽不同的TCP/IP地址

偵聽特定的SCTP/UDP/IP地址

偵聽特定的UDT/UDP/IP地址

具有與另一個節(jié)點X的多個連接

具有與另一個節(jié)點Y的多個連接

每個連接都有多個流打開

和 X 節(jié)點之間通過HTTP2協(xié)議復用流

和 Y 節(jié)點之間通過SSH復用流

掛載在 libp2p 頂部的協(xié)議為 每個對等節(jié)點使用一個流

掛載在 libp2p 頂部的協(xié)議為 每個對等節(jié)點使用多個流

如果不提供這種級別的靈活性將不可能在各種平臺、場景或網(wǎng)絡(luò)配置中使用 libp2p。
所有實現(xiàn)都支持所有的選擇并不重要；關(guān)鍵的是，規(guī)范足夠靈活，允許實現(xiàn)精確地使用他們所需要的。這確保了復雜的用戶或應(yīng)用程序約束不排除 libp2p 作為選項。

在 libp2p 之上的通信可能是:?

加密的

簽名的(沒有加密, 防篡改)

clear(沒有加密，也沒有簽名)

我們同時作了安全和性能考慮. 加密通信在數(shù)據(jù)中心內(nèi)部高性能通信場景下不是很必要.
我們推薦:

默認加密所有的通信

實現(xiàn)需要被審計

除非絕對必要，用戶通常只需要加密通信

Libp2p 采用類似TLS的加密套件.

Note: 我們不直接使用 TLS, 因為我們不需要 CA 系統(tǒng)包. 大多數(shù) TLS 實現(xiàn)都非常龐大. Since libp2p model begins with keys, libp2p only needs to apply ciphers. 這只是整個 TLS 標準中很小的一部分.

網(wǎng)絡(luò)地址轉(zhuǎn)換在英特網(wǎng)上無處不在. Not only are most consumer devices behind many layers of NAT,?but most data center nodes are often behind NAT for security or virtualization reasons.
As we move into containerized deployments, this is getting worse. IPFS的實現(xiàn) 需要 提供一個方法來穿透 NAT, 否則操作可能會受到影響. 即使要用真實IP地址運行的節(jié)點也必須實現(xiàn)NAT穿越技術(shù)，因為它們可能需要建立與NAT后面的對等體的連接.

Libp2p 采用了類 ICE 的協(xié)議完成了完整的 NAT 穿透. 他并不完全是 ICE, 因為 IPFS 網(wǎng)絡(luò)提供了通過IPFS協(xié)議中繼通信的可能性, 用于協(xié)調(diào)穿孔甚至中繼通信.

建議在實現(xiàn)中使用諸多可用的NAT穿透庫之一，例如 libnice、libwebrtc 或 natty. 總而言之，NAT穿透必須是可互操作的.

然而，對于對稱的NATS，容器和VM NAT，以及其他不可能繞過的NATS，libp2p 必須回退到中繼通信，以建立一個完整的連通圖。要完成這些，實現(xiàn)必須支持中繼，雖然它應(yīng)該是可選的，并且能夠被終端用戶關(guān)閉.
連接中繼應(yīng)該作為傳輸來實現(xiàn)，以便對上層透明.
中繼的實現(xiàn)，可參考 p2p-circuit transport.

不同的系統(tǒng)有不同的需求，進而導致不同的拓撲結(jié)構(gòu)。在P2P文獻中，我們可以發(fā)現(xiàn)這些拓撲被列舉為：非結(jié)構(gòu)化的、結(jié)構(gòu)化的、混合的和集中式的.
集中式拓撲是在Web應(yīng)用基礎(chǔ)設(shè)施中最常見的拓撲結(jié)構(gòu)，它要求給定的服務(wù)或服務(wù)群存在于已知的靜態(tài)地址，以便其他服務(wù)能夠訪問它們。非結(jié)構(gòu)化網(wǎng)絡(luò)代表了一種P2P網(wǎng)絡(luò)類型，其中網(wǎng)絡(luò)拓撲結(jié)構(gòu)是完全隨機的，或者至少是非確定性的，而結(jié)構(gòu)化網(wǎng)絡(luò)具有隱組織的方式?；旌暇W(wǎng)絡(luò)是前兩者的混合體.
考慮到這一點，libp2p 必須準備好執(zhí)行不同的路由機制和對等點發(fā)現(xiàn)，以便構(gòu)建將使服務(wù)能夠傳播消息或找到彼此的路由表.

libp2p 還通過記錄解決了網(wǎng)絡(luò)內(nèi)部資源的可發(fā)現(xiàn)性問題。記錄是一個數(shù)據(jù)單元，可以被數(shù)字簽名、時間戳和/或與其他方法一起使用，以使其具有短暫的有效性。這些記錄保存諸如網(wǎng)絡(luò)中存在的資源的位置或可用性等信息。這些資源可以是數(shù)據(jù)、存儲、CPU周期和其他類型的服務(wù)。

libp2p 不應(yīng)該限制資源的位置，而應(yīng)該提供在網(wǎng)絡(luò)中或旁路通道去方便查找資源的方式.

高效的消息傳遞協(xié)議提供以最小等待時間傳遞內(nèi)容的方法和/或支持用于分發(fā)的大型和復雜拓撲。LIPP2P試圖結(jié)合多播和PUBSUB的發(fā)展來滿足這些需求.

網(wǎng)絡(luò)的變化和應(yīng)用應(yīng)該讓使用者不感知具體的網(wǎng)絡(luò)拓撲結(jié)構(gòu)，命名便解決了這個問題.

Libp2p 是遵循UNIX理念設(shè)計的, 它由很多易于創(chuàng)建和測試的小組件組成. 這些組件應(yīng)該便于替換，以適應(yīng)不同的技術(shù)或場景，并使其能夠隨著時間的推移而升級.

雖然不同的對等體可以根據(jù)它們的能力來支持不同的協(xié)議，但是任何對等體都可以充當撥號器和/或監(jiān)聽器，用于連接其他節(jié)點，一旦建立起的連接可以從兩端重新使用，從而消除客戶端和服務(wù)器之間的區(qū)別.

libp2p 接口在多個子系統(tǒng)上充當薄的粘合劑，以便對等體能夠通信。只要它們尊重標準化的接口，這些子系統(tǒng)就可以建立在其他子系統(tǒng)的頂部。這些子系統(tǒng)適合的主要領(lǐng)域是:
點對點路由 - 機制來決定哪些節(jié)點用于路由特定消息。這種路由可以遞歸地、迭代地或甚至在廣播/組播模式下完成.
Swarm - 處理所有從LBP2P中打開“流”部分的內(nèi)容，從協(xié)議復用、流復用、NAT穿越和連接中繼，同時支持多路傳輸.
存儲和分發(fā)記錄的系統(tǒng)。記錄是其他系統(tǒng)用于信令、建立鏈接、宣布對等或內(nèi)容等的小條目。它們在更廣泛的互聯(lián)網(wǎng)上與DNS有相似的作用.
發(fā)現(xiàn)-發(fā)現(xiàn)或識別網(wǎng)絡(luò)中的其他對等體.

這些子系統(tǒng)中的每一個都公開了一個眾所周知的接口（見第6章），并且可以相互使用以實現(xiàn)其目標。系統(tǒng)的全局概覽:
libp2p
Peer Routing
Swarm
Distributed Record Store
Discovery
4.1 Peer Routing

對等路由子系統(tǒng)公開一個接口，以標識消息在DHT中應(yīng)該路由到哪些對等點。它接收一個密鑰并且必須返回一個或多個 PeerInfo 對象.

我們提出了兩個可能的對等路由子系統(tǒng)的例子，第一個基于 Kademlia DHT，第二個基于 mDNS. 然而，只要實現(xiàn)相同的期望和接口，就可以實現(xiàn)更多的對等路由機制.
kad-routing
mDNS-routing
Other-routing-mechanisms
Peer Routing

4.1.1 kad-routing

kad-routing 路由實現(xiàn)了 Kademlia 路由表，其中每個節(jié)點持有一組k桶，每個桶包含來自網(wǎng)絡(luò)中其他對等點的多個 PeerInfo 對象.

4.1.2 mDNS-routing
mDNS路由 使用 mDNS 探針來識別局域網(wǎng)節(jié)點是否具有給定的密鑰，或者它們只是簡單地存在.

4.2.1 Stream Muxer
流復用器必須實現(xiàn)接口流復用器提供的接口.

4.2.2 Protocol Muxer
協(xié)議復用是在應(yīng)用層級別處理的，而不是在端口級別(不同的服務(wù)/協(xié)議在不同端口監(jiān)聽)的常規(guī)方式. 這使得我們能夠過支持多個協(xié)議在同一個套接字中進行加密，從而節(jié)省了為多個端口進行NAT穿透的成本.
協(xié)議復用是通過多流協(xié)議來完成的, 該協(xié)議使用 multicodec 來協(xié)商不同類型的流(協(xié)議).

4.2.3 Transport?
4.2.4 Crypto

4.2.5 Identify
Identify is one of the protocols mounted on top of Swarm, our Connection handler. However, it follows and respects the same pattern as any other protocol when it comes to mounting it on top of Swarm. Identify enables us to trade listenAddrs and observedAddrs between peers, which is crucial for the working of IPFS. Since every socket open implements REUSEPORT, an observedAddr by another peer can enable a third peer to connect to us, since the port will be already open and redirect to us on a NAT.

4.2.6 回放(Replay)
See Circuit Relay.

4.3.1 Record
Follows IPRS spec.

4.3.2 abstract-record-store??4.3.3 kad-record-store

4.3.4 mDNS-record-store

4.3.5 s3-record-store

4.4.1 mDNS-discovery
mDNS-發(fā)現(xiàn) 是一種在局域網(wǎng)上使用 mDNS 的發(fā)現(xiàn)協(xié)議。它發(fā)射了mDNS信標來查找是否有更多的對等體可用。局域網(wǎng)節(jié)點對于對等協(xié)議是非常有用的，因為它們的低延遲鏈路.

mDNS-發(fā)現(xiàn)是一種獨立的協(xié)議，不依賴于任何其他的 libp2p 協(xié)議。在不依賴其他基礎(chǔ)設(shè)施的情況下，mDNS-發(fā)現(xiàn) 可以產(chǎn)生局域網(wǎng)中可用的對等點. 這在內(nèi)聯(lián)網(wǎng)、與互聯(lián)網(wǎng)主干斷開的網(wǎng)絡(luò)以及暫時失去鏈路的網(wǎng)絡(luò)中尤其有用.

mDNS-discovery 可以針對每個服務(wù)進行配置(i.e. 即僅發(fā)現(xiàn)參與特定協(xié)議的對等體，如IPFS), 還有私有網(wǎng)絡(luò)(發(fā)現(xiàn)屬于專用網(wǎng)絡(luò)的對等體).

我們正在探索加密 mDNS-discovery beacons 的方式 (使得本地網(wǎng)絡(luò)中的其他節(jié)點無法識別正在使用的服務(wù)), though the nature of mDNS will always reveal local IP addresses.

隱私注意：mDNS 在局域網(wǎng)中進行廣告，在同一本地網(wǎng)絡(luò)中向聽眾顯示IP地址。不推薦使用隱私敏感的應(yīng)用程序或太公開的路由協(xié)議.

4.4.2 random-walk
隨機游走是DHTS（具有路由表的其他協(xié)議）的發(fā)現(xiàn)協(xié)議。它進行隨機DHT查詢，以便快速了解大量的對等體。這導致DHT（或其他協(xié)議）收斂得更快，而在初始階段需要承擔一定負載開銷.

4.4.3 bootstrap-list
Bootstrap列表是一種發(fā)現(xiàn)協(xié)議，它使用本地存儲來緩存網(wǎng)絡(luò)中可用的高度穩(wěn)定的（和一些可信的）對等點的地址。這允許協(xié)議“找到網(wǎng)絡(luò)的其余部分”。這基本上與DNS自舉的方式相同（盡管注意到，通過設(shè)計改變DNS引導列表——“點域”地址——不容易做到）.
該列表應(yīng)該存儲在長期本地存儲中，無論這意味著本地節(jié)點（例如磁盤）。
協(xié)議可以將默認列表硬編碼或采用標準代碼分發(fā)機制（如DNS）進行傳送。
在大多數(shù)情況下（當然在IPFS的情況下），引導列表應(yīng)該是用戶可配置的，因為用戶可能希望建立多帶帶的網(wǎng)絡(luò)，(or place their reliance and trust in specific nodes)或者將它們的信任和信任放在特定的節(jié)點中.

4.5.1 PubSub
參考 https://github.com/libp2p/spe...

4.5.1.1 實現(xiàn)
PubSub 開發(fā)正在進行中, 用 floodsub 作為初始協(xié)議, 隨后是 gossipsub, 這是2018年5月發(fā)布的alpha版本.

Floodsub 的實現(xiàn)包括:
go-libp2p-floodsub: 參考 此篇 作為上下文. 還有 這篇 關(guān)于 gossipsub;
rust-libp2p-floodsub: @jamesray1 正基于 gossipsub 之上研究和開發(fā). Js-libp2p-floodsub.

4.5.2 IPNS

網(wǎng)絡(luò)協(xié)議主要處理以下數(shù)據(jù)結(jié)構(gòu):
PrivateKey: 節(jié)點的私鑰
PublicKey: 節(jié)點的公鑰
PeerId: 節(jié)點公鑰的hash
PeerInfo: 包含節(jié)點的 PeerId, 及其已知的 multiaddr 對象.
Transport: 用于建立與其他對等體的連接. 參考?https://github.com/libp2p/int...
Connection: 節(jié)點之間的點對點連接. 必須實現(xiàn)?https://github.com/libp2p/int...
Muxed-Stream: 雙工通信信道.
Stream-Muxer: 流復用器. 必須實現(xiàn)?https://github.com/libp2p/int...
Record: IPLD(IPFS鏈接數(shù)據(jù)) 描述了實現(xiàn) IPRS 的對象.
multiaddr: 自描述的網(wǎng)絡(luò)地址. 參考 https://github.com/multiforma...
multicodec: 自描述的編碼類型. 參考 https://github.com/multiforma...
multihash: 自描述的hash. 參考?https://github.com/multiforma...

接口

=====

libp2p 是多個協(xié)議的集合，它們一起工作，提供一個可以與任何其他網(wǎng)絡(luò)可尋址進程對話的公共實體接口。這是通過將現(xiàn)有的協(xié)議和實現(xiàn)擺在一組顯式接口中來實現(xiàn)的：對等路由、發(fā)現(xiàn)、Stream Muxing、傳輸、連接等。

libp2p, 作為頂級模塊，為其它接口提供 libp2p 實例, must offer an interface for dialing to a peer and plugging in all of the modules (e.g. which transports) we want to support. We present the libp2p interface and UX in section 6.6, after presenting every other module interface.

A Peer Routing 模塊為 libp2p 提供節(jié)點查找其它節(jié)點 PeerInfo 信息的方式, 以便連接節(jié)點. 最簡單的形式, Peer Routing 模塊需要一個接口，其接收一個 "key", 并返回一個 PeerInfo 的集合. 關(guān)于接口和測試可參考 https://github.com/libp2p/int...

Current interface available and updated at:
https://github.com/libp2p/js-...
?6.3.1 Transport
https://github.com/libp2p/int...

6.3.2 Connection
https://github.com/libp2p/int...

6.3.3 Stream Muxing
https://github.com/libp2p/int...

https://github.com/libp2p/int...

A Peer Discovery module interface should return PeerInfo objects, as it finds new peers to be considered by our Peer Routing modules.

libp2p 實現(xiàn)應(yīng)該使它能夠以編程方式實例化，或者使用以前編譯過的庫，并且已經(jīng)進行了一些協(xié)議決策，以便用戶可以重用或擴展.

程序化構(gòu)建一個LIPP2P實例?
用JavaScript實現(xiàn)的例子, 可以被映射到其他語言:

var Libp2p = require(‘libp2p’)
var node = new Libp2p()

// add swarm instance
node.addSwarm(swarmInstance)

// add one or more Peer Routing mechanisms
node.addPeerRouting(peerRoutingInstance)

// add a Distributed Record Store
node.addDistributedRecordStore(distriburedRecordStoreInstance)

配置 libp2p 非常簡單，因為大多數(shù)配置來自于實例化多個模塊，一個接一個.

撥號和偵聽與對等體的連接
理想情況下，libp2p 使用自己的機制（Peer Routing and Record Store）找到撥號給給定對等點的方法.

node.dial(PeerInfo)

若要接收傳入連接，請指定要處理的一個或多個協(xié)議：

node.handleProtocol("", function (duplexStream) {
})

查找對等節(jié)點
找到對等點是通過對等路由，所以接口是相同的.

存儲和檢索記錄
像查找對等體一樣，通過記錄存儲來完成記錄的存儲和檢索，所以接口是相同的。

Efforts like NDN and XIA are new architectures for the internet, which are closer to the model IPFS uses than what IP provides today. IPFS will be able to operate on top of these architectures trivially, as these are no assumptions made about the network stack in the protocol. Implementations will likely need to change, but changing implementations is vastly easier than changing protocols.

在實現(xiàn)不同的模塊和功能時，libp2p2 的實現(xiàn)應(yīng)該（推薦）遵循一定級別的粒度，以便公共接口易于暴露、測試和檢查與其他實現(xiàn)的互操作性.

這是當前 libp2p 存在的模塊列表:

libp2p(entry point)

Swarm

libp2p-swarm

libp2p-identify

libp2p-ping

Transports

Interface-transport

Interface-connection

libp2p-tcp

libp2p-udp

libp2p-udt

libp2p-utp

libp2p-webrtc

libp2p-cjdns

Stream Muxing

Interface-stream-muxer

libp2p-spdy

libp2p-multiplex

Crypto Channel

libp2p-tls

libp2p-secio

Peer Routing

libp2p-kad-routing

libp2p-mDNS-routing

Discovery

libp2p-mdns-discovery

libp2p-random-walk

libp2p-railing

Distributed Record Store

libp2p-record

interface-record-store

libp2p-distributed-record-store

libp2p-kad-record-store

Generic

PeerInfo

PeerId

multihash

multiaddr

multistream

multicodec

ipld

repo

當前已知實現(xiàn)(WIP):

JavaScript - https://github.com/libp2p/js-...

Go - https://github.com/ipfs/go-li...

Python - https://github.com/candeira/p...

Rust - https://github.com/libp2p/rus...

8.1.1 Swarm Dialer

集群撥號器管理到目標對等體的成功連接，給定一個地址流作為輸入，并且確保遵守速率限制等約定.
為此，我們設(shè)計了以下的撥號邏輯:

DialPeer(peerID) {
    if PeerIsBeingDialed(peerID) {
        waitForDialToComplete(peerID)
        return BestConnToPeer(peerID)
    }
    
    StartDial(peerID)

    waitForDialToComplete(peerID)
    return BestConnToPeer(peerID)
}

    
StartDial(peerID) {
    addrs = getAddressStream(peerID)

    addrs.onNewAddr(function(addr) {
        if rateLimitCanDial(peerID, addr) {
            doDialAsync(peerID, addr)
        } else {
            rateLimitScheduleDial(peerID, addr)
        }
    })
}

// doDialAsync starts dialing to a specific address without blocking.
// when the dial returns, it releases rate limit tokens, and if it
// succeeded, will finalize the dial process.
doDialAsync(peerID, addr) {
    go transportDial(addr, function(conn, err) {
        rateLimitReleaseTokens(peerID, addr)

        if err != null {
            // handle error
        }

        dialSuccess(conn)
    })
}

// rateLimitReleaseTokens checks for any tokens the given dial
// took, and then for each of them, checks if any other dial is waiting
// for any of those tokens. If waiting dials are found, those dials are started
// immediately. Otherwise, the tokens are released to their pools.
rateLimitReleaseTokens(peerID, addr) {
    tokens = tokensForDial(peerID, addr)

    for token in tokens {
        dial = dialWaitingForToken(token)
        if dial != null {
            doDialAsync(dial.peer, dial.addr)
        } else {
            token.release()
        }
    }
}