go-libp2p
go-libp2p copied to clipboard
libp2p implementation in Go
In fixing libp2p/go-libp2p-kad-dht#96, we introduced a bug: we now *don't* backoff when the context is canceled. Unfortunately, this means we don't backoff if we timeout.
So, it turns out we really need dial priorities, given the dial limits we have in place. The behavior I'm noticing is: 1. We fire off a FindProviders. 2. This...
I'm on a new internet connection since a few weeks and I'm noticing interesting pattern with the ISP provided router - it can handle 1000s of connections just fine, but...
We need to classify addresses as FD/Non-FD consuming at two places: - Before we dial them. because we rate limit FD consuming addresses: * Relay addresses should be classified as...
Types: 1. TCP connect timeout, RTT, expected latency, etc... 2. Per address dial timeouts. 3. Overall time/resources spent on dialing a peer. 4. Default timeout for `DialPeer` and `NewStream`. Concerns:...
Currently, relay dials may trigger file descriptor limiting logic because they contain a TCP transport. This means: 1. We'll double-pay. 2. We could end up blocking as the relay dialer...
In https://github.com/libp2p/go-libp2p-swarm/pull/227, it's possible for a dial to be initiated on a transport after calling `Close` while shutting down. This _usually_ won't be an issue, but it would be nice...
That way, we can get rid of some of the fallback logic. See the TODO here: https://github.com/libp2p/go-reuseport-transport/pull/6#discussion-diff-245203302R42 Alternatively, we can remove the TODO.
Currently, it looks like we're spinning off a "goprocess" to periodically re-establish the mapping and we only close this process when we close the nat manager (not when we remove...
Currently, the user has to call `DiscoverNAT` up-front. However, if the user changes networks, they'll have to call this again. Instead, we should provide a standard `New()` constructor that calls...