libp2p implementation in Go

libp2p hex logo

The Go implementation of the libp2p Networking Stack.



Table of Contents

Background

libp2p is a networking stack and library modularized out of The IPFS Project, and bundled separately for other tools to use.

libp2p is the product of a long, and arduous quest of understanding -- a deep dive into the internet's network stack, and plentiful peer-to-peer protocols from the past. Building large-scale peer-to-peer systems has been complex and difficult in the last 15 years, and libp2p is a way to fix that. It is a "network stack" -- a protocol suite -- that cleanly separates concerns, and enables sophisticated applications to only use the protocols they absolutely need, without giving up interoperability and upgradeability. libp2p grew out of IPFS, but it is built so that lots of people can use it, for lots of different projects.

We will be writing a set of docs, posts, tutorials, and talks to explain what p2p is, why it is tremendously useful, and how it can help your existing and new projects. But in the meantime, check out

Usage

This repository (go-libp2p) serves as the entrypoint to the universe of modules that compose the Go implementation of the libp2p stack.

You can start using go-libp2p in your Go application simply by adding imports from our repos, e.g.:

import "github.com/libp2p/go-libp2p"

Run go get or go build, excluding the libp2p repos from Go modules proxy usage. You only need to do this the first time you import go-libp2p to make sure you latch onto the correct version lineage (see golang/go#34189 for context):

$ GOPRIVATE='github.com/libp2p/*' go get ./...

The Go build tools will look for available releases, and will pick the highest available one.

As new releases of go-libp2p are made available, you can upgrade your application by manually editing your go.mod file, or using the Go tools to maintain module requirements.

API

GoDoc

Examples

Examples can be found in the examples folder.

Development

Using the go-libp2p Workspace

While developing, you may need to make changes to several modules at once, or you may want changes made locally in one module to be available for import by another.

The go-libp2p workspace provides a developer-oriented view of the modules that comprise go-libp2p.

Using the tooling in the workspace repository, you can checkout all of go-libp2p's module repos and enter "local mode", which adds replace directives to the go.mod files in each local working copy. When you build locally, the libp2p depdendencies will be resolved from your local working copies.

Once you've committed your changes, you can switch back to "remote mode", which removes the replace directives and pulls imports from the main go module cache.

See the workspace repo for more information.

About gx

Before adopting gomod, libp2p used gx to manage dependencies using IPFS.

Due to the difficulties in keeping both dependency management solutions up-to-date, gx support was ended in April 2019.

Ending gx support does not mean that existing gx builds will break. Because gx references dependencies by their immutable IPFS hash, any currently working gx builds will continue to work for as long as the dependencies are resolvable in IPFS.

However, new changes to go-libp2p will not be published via gx, and users are encouraged to adopt gomod to stay up-to-date.

If you experience any issues migrating from gx to gomod, please join the discussion at the libp2p forums.

Tests

go test ./... will run all tests in the repo.

Releasing

Please start a release by opening a new Libp2p Release issue.

Packages

This table is generated using the module package-table with package-table --data=package-list.json.

List of packages currently in existence for libp2p:

Name CI/Travis Coverage Description
Libp2p
go-libp2p Travis CI codecov go-libp2p entry point
go-libp2p-core Travis CI codecov core interfaces, types, and abstractions
go-libp2p-blankhost Travis CI codecov minimal implementation of the "host" interface
Network
go-libp2p-swarm Travis CI codecov reference implementation of network state machine
Transport
go-ws-transport Travis CI codecov WebSocket transport
go-tcp-transport Travis CI codecov TCP transport
go-libp2p-quic-transport Travis CI codecov QUIC transport
go-udp-transport Travis CI codecov UDP transport
go-utp-transport Travis CI codecov uTorrent transport (UTP)
go-libp2p-circuit Travis CI codecov relay transport
go-libp2p-transport-upgrader Travis CI codecov upgrades multiaddr-net connections into full libp2p transports
go-libp2p-reuseport-transport Travis CI codecov partial transport for building transports that reuse ports
Encrypted Channels
go-libp2p-secio Travis CI codecov SecIO crypto channel
go-libp2p-tls Travis CI codecov TLS 1.3+ crypto channel
go-conn-security-multistream Travis CI codecov multistream multiplexed meta crypto channel
Private Network
go-libp2p-pnet Travis CI codecov reference private networking implementation
Stream Muxers
go-libp2p-yamux Travis CI codecov YAMUX stream multiplexer
go-libp2p-mplex Travis CI codecov MPLEX stream multiplexer
NAT Traversal
go-libp2p-nat Travis CI codecov
Peerstore
go-libp2p-peerstore Travis CI codecov reference implementation of peer metadata storage component
Connection Manager
go-libp2p-connmgr Travis CI codecov reference implementation of connection manager
Routing
go-libp2p-record Travis CI codecov record type and validator logic
go-libp2p-kad-dht Travis CI codecov Kademlia-like router
go-libp2p-kbucket Travis CI codecov Kademlia routing table helper types
go-libp2p-coral-dht Travis CI codecov Router based on Coral DHT
go-libp2p-pubsub-router Travis CI codecov record-store over pubsub adapter
Consensus
go-libp2p-consensus Travis CI codecov consensus protocols interfaces
go-libp2p-raft Travis CI codecov consensus implementation over raft
Pubsub
go-libp2p-pubsub Travis CI codecov multiple pubsub over libp2p implementations
RPC
go-libp2p-gorpc Travis CI codecov a simple RPC library for libp2p
Utilities/miscellaneous
go-libp2p-loggables Travis CI codecov logging helpers
go-maddr-filter Travis CI codecov multiaddr filtering helpers
go-libp2p-netutil Travis CI codecov misc utilities
go-msgio Travis CI codecov length prefixed data channel
go-addr-util Travis CI codecov address utilities for libp2p swarm
go-buffer-pool Travis CI codecov a variable size buffer pool for go
go-libp2p-routing-helpers Travis CI codecov routing helpers
go-reuseport Travis CI codecov enables reuse of addresses
go-sockaddr Travis CI codecov utils for sockaddr conversions
go-flow-metrics Travis CI codecov metrics library
go-libp2p-gostream Travis CI codecov Go 'net' wrappers for libp2p
go-libp2p-http Travis CI codecov HTTP on top of libp2p streams
Testing and examples
go-libp2p-testing Travis CI codecov a collection of testing utilities for libp2p

Contribute

go-libp2p is part of The IPFS Project, and is MIT-licensed open source software. We welcome contributions big and small! Take a look at the community contributing notes. Please make sure to check the issues. Search the closed ones before reporting things, and help us with the open ones.

Guidelines:

  • read the libp2p spec
  • please make branches + pull-request, even if working on the main repository
  • ask questions or talk about things in issues, our discussion forums, or #libp2p or #ipfs on freenode.
  • ensure you are able to contribute (no legal issues please -- we use the DCO)
  • run go fmt before pushing any code
  • run golint and go vet too -- some things (like protobuf files) are expected to fail.
  • get in touch with @raulk and @mgoelzer about how best to contribute
  • have fun!

There's a few things you can do right now to help out:

  • Go through the modules below and check out existing issues. This would be especially useful for modules in active development. Some knowledge of IPFS/libp2p may be required, as well as the infrasture behind it - for instance, you may need to read up on p2p and more complex operations like muxing to be able to help technically.
  • Perform code reviews.
  • Add tests. There can never be enough tests.

The last gx published version of this module was: 6.0.41: QmTRN7hRxvGkxKxDdeudty7sRet4L7ZKZCqKsXHa79wmAc

Owner
libp2p
Modular peer-to-peer networking stack (used by IPFS and others)
libp2p
Comments
  • NAT Traversal in chat example

    NAT Traversal in chat example

    Hi, I'm new to libp2p https://github.com/libp2p/go-libp2p/tree/master/examples/chat This example shows peer A (A behind NAT) connect peer B (B has public IP), but B couldn't connect A. I don't think it is a typical P2P example. How could a peer to connect a peer which behinds NAT or firewall, give us an example please.

  • Support for WebRTC transport

    Support for WebRTC transport

    So the Duo team (working on OpenBazaar) was all excited that we can now have truly peer-to-peer communications between js-ipfs and go-ipfs using WebSockets. It turns out that, in practice, WebSockets doesn't work direct p2p. The reason is that Firefox (since always) and Chrome (since recently) only allow for wss:// (secure WebSockets) on an https:// page. So the Duo team has to use a wss:// to ws:// proxy, which truly sucks.

    Our hope is that go-libp2p will support WebRTC. The Duo team would be happy to review and test the implementation. πŸ‘

  • Yamux + secio data race

    Yamux + secio data race

    I have found a yamux + secio data race when running tests and I'm a bit lost with this one:

    ==================
    WARNING: DATA RACE
    Write at 0x00c420d9eb5a by goroutine 310:
      gx/ipfs/QmZt87ZHYGaZFBrtGPEqYjAC2yNAhgiRDBmu8KaCzHjx6h/yamux.header.encode()
          /usr/lib64/go/1.10/src/encoding/binary/binary.go:119 +0x1d9
      gx/ipfs/QmZt87ZHYGaZFBrtGPEqYjAC2yNAhgiRDBmu8KaCzHjx6h/yamux.(*Stream).sendReset()
          /home/hector/go/src/gx/ipfs/QmZt87ZHYGaZFBrtGPEqYjAC2yNAhgiRDBmu8KaCzHjx6h/yamux/stream.go:287 +0xe1
      gx/ipfs/QmZt87ZHYGaZFBrtGPEqYjAC2yNAhgiRDBmu8KaCzHjx6h/yamux.(*Stream).Reset()
          /home/hector/go/src/gx/ipfs/QmZt87ZHYGaZFBrtGPEqYjAC2yNAhgiRDBmu8KaCzHjx6h/yamux/stream.go:306 +0xac
      gx/ipfs/QmdjC8HtKZpEufBL1u7WxvQn78Lqq2Wk31NJS8WvFX3crB/go-libp2p-swarm.(*Stream).Reset()
          /home/hector/go/src/gx/ipfs/QmdjC8HtKZpEufBL1u7WxvQn78Lqq2Wk31NJS8WvFX3crB/go-libp2p-swarm/swarm_stream.go:111 +0x52
      gx/ipfs/QmUDzeFgYrRmHL2hUB6NZmqcBVQtUzETwmFRUc9onfSSHr/go-libp2p/p2p/host/basic.(*BasicHost).newStreamHandler()
          /home/hector/go/src/gx/ipfs/QmUDzeFgYrRmHL2hUB6NZmqcBVQtUzETwmFRUc9onfSSHr/go-libp2p/p2p/host/basic/basic_host.go:228 +0x353
      gx/ipfs/QmUDzeFgYrRmHL2hUB6NZmqcBVQtUzETwmFRUc9onfSSHr/go-libp2p/p2p/host/basic.(*BasicHost).(gx/ipfs/QmUDzeFgYrRmHL2hUB6NZmqcBVQtUzETwmFRUc9onfSSHr/go-libp2p/p2p/host/basic.new
          /home/hector/go/src/gx/ipfs/QmUDzeFgYrRmHL2hUB6NZmqcBVQtUzETwmFRUc9onfSSHr/go-libp2p/p2p/host/basic/basic_host.go:154 +0x55
      gx/ipfs/QmdjC8HtKZpEufBL1u7WxvQn78Lqq2Wk31NJS8WvFX3crB/go-libp2p-swarm.(*Conn).start.func1.1()
          /home/hector/go/src/gx/ipfs/QmdjC8HtKZpEufBL1u7WxvQn78Lqq2Wk31NJS8WvFX3crB/go-libp2p-swarm/swarm_conn.go:113 +0xec
    
    Previous read at 0x00c420d9eb5a by goroutine 131:
      crypto/cipher.fastXORBytes()
          /usr/lib64/go/1.10/src/crypto/cipher/xor.go:39 +0x131
      crypto/cipher.xorBytes()
          /usr/lib64/go/1.10/src/crypto/cipher/xor.go:60 +0x9e
      crypto/cipher.(*ctr).XORKeyStream()
          /usr/lib64/go/1.10/src/crypto/cipher/ctr.go:78 +0x2a1
      gx/ipfs/QmZ69yKFZ7V5hLCYFWzJF1Nz4dH1Es4LaE8jGXAFucLe3K/go-libp2p-secio.(*etmWriter).WriteMsg()
          /home/hector/go/src/gx/ipfs/QmZ69yKFZ7V5hLCYFWzJF1Nz4dH1Es4LaE8jGXAFucLe3K/go-libp2p-secio/rw.go:49 +0x1da
      gx/ipfs/QmZ69yKFZ7V5hLCYFWzJF1Nz4dH1Es4LaE8jGXAFucLe3K/go-libp2p-secio.(*etmWriter).Write()
          /home/hector/go/src/gx/ipfs/QmZ69yKFZ7V5hLCYFWzJF1Nz4dH1Es4LaE8jGXAFucLe3K/go-libp2p-secio/rw.go:34 +0x5a
      gx/ipfs/QmWBug6eBS7AxRdCDVuSY5CnSit7cS2XnPFYJWqWDumhCG/go-msgio.(*readWriter).Write()
          <autogenerated>:1 +0x82
      gx/ipfs/QmZ69yKFZ7V5hLCYFWzJF1Nz4dH1Es4LaE8jGXAFucLe3K/go-libp2p-secio.(*secureSession).Write()
          <autogenerated>:1 +0x7d
      gx/ipfs/QmZt87ZHYGaZFBrtGPEqYjAC2yNAhgiRDBmu8KaCzHjx6h/yamux.(*Session).send()
          /home/hector/go/src/gx/ipfs/QmZt87ZHYGaZFBrtGPEqYjAC2yNAhgiRDBmu8KaCzHjx6h/yamux/session.go:398 +0xf3
    
  • autorelay

    autorelay

    Implements autorelay; Closes #444.

    Depends on:

    • [X] https://github.com/libp2p/go-libp2p-discovery/pull/1
    • [X] https://github.com/libp2p/go-libp2p-autonat/pull/2
    • [X] https://github.com/multiformats/go-multiaddr-net/pull/46

    TBD:

    • [X] gx import discovery
    • [X] gx import autonat
    • [X] gx update multiaddr-net
    • [X] Update New constructor to automatically create relay/autorelay/routed hosts
    • [X] tests!
  • 2018 Q4 OKR Planning

    2018 Q4 OKR Planning

    Ref: https://github.com/ipfs/pm/issues/698

    Urls:

    It's time to do the OKR Planning for Q4 \o/. This is the first time that the go-ipfs team is going to do it this way, you can find a lot of information at https://github.com/ipfs/pm/issues/698. Please make sure to read it to get the full context in how we are going to do this (Retrospective + Open OKR Planning).

  • peer discovery fail

    peer discovery fail

    Hi guy's,

    in the last few day's I have been playing around with content / peer discovery. Discovery of content work's quite nice tho it's a bid slow (I wonder what it's so fast when using IPFS directly) but peer discovery doesn't work. When I search for a bootstrapping node (e.g. QmSoLer265NRgSp2LA3dPaeykiS1J6DifTC88f5uVQKNAd) it fails after 2 - 5 minutes because the peer can't be found (error message is: routing: not found). I created an test repo here which you can use to reproduce the problem. The interesting thing is that I can call FindPeer on the DHT with any string. There is no validation, which might mean that I am using the wrong ID (tho I am sure that this QmSoLer265NRgSp2LA3dPaeykiS1J6DifTC88f5uVQKNAd is a peer id in the libpp2 context). Can someone point me in the right direction where I can find help? I also had a look at whyrusleeping's chat example since it makes use of the DHT. But there it seem's to work.

    Thanks for you help, Florian

  • integrate the event bus, handle protocol update events, make identify emit deltas

    integrate the event bus, handle protocol update events, make identify emit deltas

    This PR introduces the following:

    • the event bus in host implementations.
    • locally emits the EvtLocalProtocolsUpdated events when protocol handlers are added and removed.
    • identify: introduces deltas to avoid sending huge dumps over the wire, for now only for protocol updates, but can easily extend for addr updates.
    • identify: emit delta when local protocols change (reacting to EvtLocalProtocolsUpdated).
    • identify: consume deltas from peers and emit EvtPeerProtocolsUpdated.

    TODO:

    • [x] Release go-libp2p-core after merging https://github.com/libp2p/go-libp2p-core/pull/17.
    • [x] Release go-eventbus.
    • [x] Release go-libp2p-peerstore after merging https://github.com/libp2p/go-libp2p-peerstore/pull/84.
    • [x] Update go.mod here.
  • Ensure DHT clients remain discoverable

    Ensure DHT clients remain discoverable

    Design notes

    • Problem: Servers will prune client connections frequently because they presumably rank low in the connection manager.

      • This: (a) thrashes the routing table, and (b) leads to connection flapping.
      • For solving (a), continue reading below.
      • For solving (b), we can either wait for QUIC/UDP, or implement libp2p connection resumption.
    • Solution:

      • With dissociating the routing table from the connection state, clients will no longer remove disconnected servers from their routing table; instead they’ll test connectivity on refresh. This avoids routing table thrashing.
      • Splinter the table refresh routine into two separate routines:
        • Self-walk (calls GetCloserPeers(self), or FindPeer(self) -- which is special-cased anyway).
        • Table refresh.
      • ~If we are a DHT client:~ edit: we should do this regardless
        • Perform self-walks every 5 minutes; perform standard table refreshes every 10 minutes.
        • When we receive a local address update from the eventbus, trigger an immediate self-walk + connect, and reset the timer.
          • Specifically, we need to make sure our K closest peers have our latest address. An actual walk may not be necessary, we just need to be connected.
      • Queries must no longer terminate upon a hit, they continue until the end (as defined by Kademlia) in order to find the latest record (highest seq number). (part of implementing Kademlia correctly)
      • Signed peer routing records are a requirement.

    Testing mechanics

    1. Two cohorts: DHT clients and DHT servers.
      • DHT clients use the ListenAddrs host constructor option to listen on localhost only, yet they advertise dialable addresses by using a custom AddrFactory.
    2. From all nodes, try to find all DHT clients, and record the time and hops it took.
    3. Make a subcohort of DHT clients change their addresses (and signal so via Redis), and try to find all DHT clients again, recording whether we saw the new addresses (SUCCESS), or not (FAILURE).

    Success Criteria

    • DHT clients remain discoverable even when (#dht clients)/(#dht servers) >> connection manager limits.
  • Sudden stall at 100% CPU

    Sudden stall at 100% CPU

    Knowns:

    • Started happening after 7ba322244e0a but before 0.6.1.
    • The node is completely unresponsive, even to pprof.

    Likely: https://github.com/golang/go/issues/38070

  • exchange signed routing records in identify

    exchange signed routing records in identify

    This is still in progress & gomod is pointing at these PR branches:

    • https://github.com/libp2p/go-libp2p-core/pull/73
    • https://github.com/libp2p/go-libp2p-peerstore/pull/98

    TODO:

    • [x] test
    • [ ] land dependency PRs and update gomod

    @vyzo this should be good enough to start hacking on

  • Remove gx support from builds

    Remove gx support from builds

    We are at a point now where there are changes in gomod that refuse to build in gx, without updating the gx packages. But we have agreed to stop doing that, as gx is no considered deprecated. We need to remove the gx build type from CI builds.

  • identify: simplify implementation by removing peer tracking

    identify: simplify implementation by removing peer tracking

    Identify currently deduplicates deltas sent to peers that we hold multiple connections to. This creates a lot of complexity in the implementation of the protocol.

    It would be nice if we could simplify the logic to act on connections instead. There'd be no complicated tracking logic: start handling a connection when it's opened / accepted, and handle it until it is closed.

    I measured how frequent duplicate connections really are by running Kubo both on my local machine (behind a CGNAT) and on a public server. The highest number of peers with duplicate connections I've come across was duplicates to 9 peers out of a total of 159, but that value quickly dropped as connections churned. For the vast majority of the time, we had duplicate connections to about 1% of the peers. I expect that the number of duplicates will drop even further once we implement a smarter dialing logic (https://github.com/libp2p/go-libp2p/issues/1785), although we will never be able to completely eliminate them, given that two peers dialing each other at exactly the same time will end up with two connections.

    @vyzo @Stebalien quick sanity check, does this make sense?

  • Tracking Issue: QUIC 0.5-RTT Optimization

    Tracking Issue: QUIC 0.5-RTT Optimization

    https://github.com/libp2p/go-libp2p/pull/1959 proposes to prioritize making 0.5-RTT data in QUIC usable to send Identify data immediately. This would cut off 1 RTT from the QUIC handshake, bringing the time it takes to establish a libp2p QUIC connection + run Identify from 2 to 1 RTTs.

    Done Criteria:

    • [ ] enable 0.5-RTT data in quic-go: https://github.com/lucas-clemente/quic-go/issues/3634
    • [ ] introduce an EarlyListener interface that returns connections that are still handshaking, then use those for Identify
    • [ ] write a blog post
  • roadmap: remove optimizations of the TCP-based handshake

    roadmap: remove optimizations of the TCP-based handshake

    As an early result of the swarm metrics effort (#1910), we've discovered that >80% of the connections that a (full) node on the IPFS network establishes / accepts are QUIC connections. We can expect similar numbers for other libp2p networks that use go-libp2p (and that enabled the QUIC transport).

    It therefore makes sense to focus our attention on cutting down roundtrips for QUIC users. This makes sense for multiple reasons:

    1. At the risk of stating the obvious, improving the handshake latency for >80% of the connections is more impactful than improving the handshake latency for <20% of the connections.
    2. Optimizing the TCP-based handshake by getting rid of the security protocol negotiation reduces the latency of a TCP handshake 4 to 3 RTTs (including Identify in the calculation here), that's 25%. Optimizing the QUIC handshake (by using 0.5-RTT data for Identify) allows us to bring down the latency from 2 to 1 RTT, a speedup of 50%.
    3. Moving the security protocol is a complicated change, requiring changes to the libp2p specification (https://github.com/libp2p/specs/pull/353), and requires both nodes to upgrade to the latest versions. Using 0.5-RTT data in QUIC on the other hand is a backwards-compatible change, as it doesn't require the client to upgrade. Thus, the performance impact will materialize much faster.

    I suggest removing the TCP-based optimizations instead of just deprioritizing them, since given our current staffing situation, and the recent addition of the libp2p+HTTP work, we already have a lot on our plate.

  • bug: segfault in webtransport stream

    bug: segfault in webtransport stream

    Version: 0.24.1 Seen in kubo0.18-rc1

    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x1b1b0a0]
    
    goroutine 1359646 [running]:
    github.com/libp2p/go-libp2p/p2p/transport/webtransport.(*stream).Reset(0xc00fcd23c0)
    	/home/hugo/go/pkg/mod/github.com/libp2p/[email protected]/p2p/transport/webtransport/stream.go:54 +0x20
    github.com/libp2p/go-libp2p/p2p/net/swarm.(*Stream).Reset(0xc02b010a00)
    	/home/hugo/go/pkg/mod/github.com/libp2p/[email protected]/p2p/net/swarm/swarm_stream.go:86 +0x2a
    github.com/libp2p/go-libp2p/p2p/host/basic.(*BasicHost).NewStream(0xc0008fc780, {0x2b5a0e0, 0xc01e869170}, {0xc00550a420, 0x26}, {0xc00037a860, 0x1, 0x0?})
    	/home/hugo/go/pkg/mod/github.com/libp2p/[email protected]/p2p/host/basic/basic_host.go:636 +0x2bb
    github.com/libp2p/go-libp2p-kad-dht/internal/net.(*peerMessageSender).prep(0xc01f123c20, {0x2b5a0e0?, 0xc01e869170?})
    	/home/hugo/go/pkg/mod/github.com/libp2p/[email protected]/internal/net/message_manager.go:216 +0x6a
    github.com/libp2p/go-libp2p-kad-dht/internal/net.(*peerMessageSender).SendRequest(0xc01f123c20, {0x2b5a0e0, 0xc01e869170}, 0xc01d88d830?)
    	/home/hugo/go/pkg/mod/github.com/libp2p/[email protected]/internal/net/message_manager.go:277 +0x12c
    github.com/libp2p/go-libp2p-kad-dht/internal/net.(*messageSenderImpl).SendRequest(0xc0014ea800, {0x2b5a038, 0xc01bc02ec0}, {0xc01d88d830, 0x26}, 0xc01eaef000?)
    	/home/hugo/go/pkg/mod/github.com/libp2p/[email protected]/internal/net/message_manager.go:88 +0x374
    github.com/libp2p/go-libp2p-kad-dht/pb.(*ProtocolMessenger).GetClosestPeers(0xc00037a930, {0x2b5a038, 0xc01bc02ec0}, {0xc01d88d830, 0x26}, {0xc01dfd4b70?, 0x0?})
    	/home/hugo/go/pkg/mod/github.com/libp2p/[email protected]/pb/protocol_messenger.go:108 +0xd4
    github.com/libp2p/go-libp2p-kad-dht.(*IpfsDHT).FindPeer.func1({0x2b5a038, 0xc01bc02ec0}, {0xc01d88d830, 0x26})
    	/home/hugo/go/pkg/mod/github.com/libp2p/[email protected]/routing.go:604 +0xfb
    github.com/libp2p/go-libp2p-kad-dht.(*query).queryPeer(0xc02b47bef0, {0x2b5a038, 0xc01bc02ec0}, 0xc000a03530?, {0xc01d88d830, 0x26})
    	/home/hugo/go/pkg/mod/github.com/libp2p/[email protected]/query.go:408 +0x26e
    created by github.com/libp2p/go-libp2p-kad-dht.(*query).spawnQuery
    	/home/hugo/go/pkg/mod/github.com/libp2p/[email protected]/query.go:325 +0x44a
    
πŸ“¦ Command line peer-to-peer data transfer tool based on libp2p.

pcp - Peer Copy Command line peer-to-peer data transfer tool based on libp2p. Table of Contents Motivation Project Status How does it work? Usage Inst

Jan 5, 2023
A Lightweight VPN Built on top of Libp2p for Truly Distributed Networks.
A Lightweight VPN Built on top of Libp2p for Truly Distributed Networks.

Hyprspace A Lightweight VPN Built on top of Libp2p for Truly Distributed Networks. demo.mp4 Table of Contents A Bit of Backstory Use Cases A Digital N

Dec 29, 2022
🌌 A libp2p DHT crawler that gathers information about running nodes in the network.
🌌 A libp2p DHT crawler that gathers information about running nodes in the network.

A libp2p DHT crawler that gathers information about running nodes in the network. The crawler runs every 30 minutes by connecting to the standard DHT bootstrap nodes and then recursively following all entries in the k-buckets until all peers have been visited.

Dec 27, 2022
RPC over libp2p pubsub with error handling

go-libp2p-pubsub-rpc RPC over libp2p pubsub with error handling Table of Contents Background Install Usage Contributing Changelog License Background g

Dec 14, 2022
Transport to allow go-libp2p applications to natively use i2p for communication

I2P Transport for go-libp2p This library can be used to build go-libp2p applications using the i2p network. Look at transport_test.go for example usag

Sep 15, 2022
P2P Forwarder - a tool for farwarding tcp/udp ports. Made using libp2p.
P2P Forwarder - a tool for farwarding tcp/udp ports. Made using libp2p.

P2P Forwarder A tool for farwarding ports. Made using libp2p. How it works A: opens desired ports ports inside P2P Forwarder A: shares it's id from P2

Nov 14, 2022
A simple toy example for running Graphsync + libp2p.
A simple toy example for running Graphsync + libp2p.

graphsync-example Here we outline a simple toy example (main.go) where two local peers transfer Interplanetary Linked Data (IPLD) graphs using Graphsy

Dec 8, 2021
Libp2p chat with discovery and pubsub

Dicovery - pubsub chat with libp2p How to test Run boostrap node $ go run main/main.go --port 35005 --nick boot --pk XDLjuaVJ2yKQ2zHMmsee5PGHtDHmkkvFA

Jul 3, 2022
A simple port forward tools build on libp2p with holepunch support.

p2p-tun A simple port forward and tun2socks tools build on libp2p with holepunch support. Usage NAME: p2p-tun - port forward and tun2socks through

Dec 20, 2022
A go implementation of the STUN client (RFC 3489 and RFC 5389)

go-stun go-stun is a STUN (RFC 3489, 5389) client implementation in golang (a.k.a. UDP hole punching). RFC 3489: STUN - Simple Traversal of User Datag

Jan 5, 2023
A QUIC implementation in pure go
A QUIC implementation in pure go

A QUIC implementation in pure Go quic-go is an implementation of the QUIC protocol in Go. It implements the IETF QUIC draft-29 and draft-32. Version c

Jan 9, 2023
Fast RFC 5389 STUN implementation in go

STUN Package stun implements Session Traversal Utilities for NAT (STUN) [RFC5389] protocol and client with no external dependencies and zero allocatio

Nov 28, 2022
Pure Go implementation of the WebRTC API
Pure Go implementation of the WebRTC API

Pion WebRTC A pure Go implementation of the WebRTC API New Release Pion WebRTC v3.0.0 has been released! See the release notes to learn about new feat

Jan 1, 2023
A LWM2M Client and Server implementation (For Go/Golang)

Betwixt - A LWM2M Client and Server in Go Betwixt is a Lightweight M2M implementation written in Go OMA Lightweight M2M is a protocol from the Open Mo

Dec 23, 2022
A Socket.IO backend implementation written in Go

go-socket.io The socketio package is a simple abstraction layer for different web browser- supported transport mechanisms. It is fully compatible with

Sep 25, 2022
A Windows named pipe implementation written in pure Go.

npipe Package npipe provides a pure Go wrapper around Windows named pipes. Windows named pipe documentation: http://msdn.microsoft.com/en-us/library/w

Jan 1, 2023
An Etsy StatsD (https://github.com/etsy/statsd) implementation in Go

STATSD-GO Port of Etsy's statsd, written in Go. This was forked from https://github.com/amir/gographite to provide Ganglia submission support. USAGE U

Mar 5, 2021
Implementation of the FTPS protocol for Golang.

FTPS Implementation for Go Information This implementation does not implement the full FTP/FTPS specification. Only a small subset. I have not done a

Mar 14, 2022
πŸš₯ Yet another pinger: A high-performance ICMP ping implementation build on top of BPF technology.

yap Yet-Another-Pinger: A high-performance ICMP ping implementation build on top of BPF technology. yap uses the gopacket library to receive and handl

Nov 9, 2022