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

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

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

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

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

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

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

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

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

對(duì)等路由子系統(tǒng)公開(kāi)一個(gè)接口，以標(biāo)識(shí)消息在DHT中應(yīng)該路由到哪些對(duì)等點(diǎn)。它接收一個(gè)密鑰并且必須返回一個(gè)或多個(gè) PeerInfo 對(duì)象.

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

4.1.1 kad-routing

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

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

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

4.2.2 Protocol Muxer
協(xié)議復(fù)用是在應(yīng)用層級(jí)別處理的，而不是在端口級(jí)別(不同的服務(wù)/協(xié)議在不同端口監(jiān)聽(tīng))的常規(guī)方式. 這使得我們能夠過(guò)支持多個(gè)協(xié)議在同一個(gè)套接字中進(jìn)行加密，從而節(jié)省了為多個(gè)端口進(jìn)行NAT穿透的成本.
協(xié)議復(fù)用是通過(guò)多流協(xié)議來(lái)完成的, 該協(xié)議使用 multicodec 來(lái)協(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信標(biāo)來(lái)查找是否有更多的對(duì)等體可用。局域網(wǎng)節(jié)點(diǎn)對(duì)于對(duì)等協(xié)議是非常有用的，因?yàn)樗鼈兊牡脱舆t鏈路.

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

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

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

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

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

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

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

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

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

4.5.2 IPNS

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

接口

=====

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

libp2p, 作為頂級(jí)模塊，為其它接口提供 libp2p 實(shí)例, 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é)點(diǎn)查找其它節(jié)點(diǎn) PeerInfo 信息的方式, 以便連接節(jié)點(diǎn). 最簡(jiǎn)單的形式, Peer Routing 模塊需要一個(gè)接口，其接收一個(gè) "key", 并返回一個(gè) PeerInfo 的集合. 關(guān)于接口和測(cè)試可參考 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 實(shí)現(xiàn)應(yīng)該使它能夠以編程方式實(shí)例化，或者使用以前編譯過(guò)的庫(kù)，并且已經(jīng)進(jìn)行了一些協(xié)議決策，以便用戶可以重用或擴(kuò)展.

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

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 非常簡(jiǎn)單，因?yàn)榇蠖鄶?shù)配置來(lái)自于實(shí)例化多個(gè)模塊，一個(gè)接一個(gè).

撥號(hào)和偵聽(tīng)與對(duì)等體的連接
理想情況下，libp2p 使用自己的機(jī)制（Peer Routing and Record Store）找到撥號(hào)給給定對(duì)等點(diǎn)的方法.

node.dial(PeerInfo)

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

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

查找對(duì)等節(jié)點(diǎn)
找到對(duì)等點(diǎn)是通過(guò)對(duì)等路由，所以接口是相同的.

存儲(chǔ)和檢索記錄
像查找對(duì)等體一樣，通過(guò)記錄存儲(chǔ)來(lái)完成記錄的存儲(chǔ)和檢索，所以接口是相同的。

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.

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

這是當(dāng)前 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

當(dāng)前已知實(shí)現(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

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

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()
        }
    }
}