GitLab

addConn is called both when we add a dialed and an accepted connection to the
swarm. InterceptAddrDial is only supposed to intercept outgoing connections
though. When dialing, we already call InterceptAddrDial when we compose the
list of dialable addresses.

they work with private data types, so there is no point in having them public

Given 1k requests per second (assuming one stream per request), we can
easily loop around the stream ID after less than 2 months. 32bits is
plenty (usually) for connection-scoped stream IDs because individual
connections don't usually last that long, but isn't enough for a
_global_ stream ID.

Given that there's no reason for these to be 32bit IDs, let's just make
them 64bits.

This way, transports with shared resources (e.g., reused sockets) can clean them
up.

fixes https://github.com/libp2p/go-libp2p/issues/999

Given two relay connections, prefer the one that's non-transient.
Otherwise, a transient connection could prevent us from opening streams
even if we have a second non-transient connection through a better relay.

* support for forced direct connections.

Co-authored-by: Aarsh Shah <aarshkshah1992@gmail.com>
Co-authored-by: Raúl Kripalani <raul@protocol.ai>

* Rank dial addresss.

Otherwise, we can modify the context after/while the process is shutting down.

fixes #189

only cancel dials when an outbound connection succeeds. this may result in duplicate connections, but it's better to have two connections than dropping both of them and ending up with zero connections.

1. Always return the caller's context error if relevant.
2. Don't return "context canceled" when we're just shutting down.
3. Don't claim that the context deadline has been exceeded when the dial timeout
is canceled.

Avoid logging about closed listeners, etc., when shutting down.

License: MIT
Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>

This can be quite an overhead in cases of high connection rates.
The main overhead is thread blocking syscall causing a lot of context
switching.

License: MIT
Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>

This reverts commit 3dded3dc.

The global per-peer dial timeout had a significant drawback: When dialing many
peers, this timeout could cause libp2p to cancel dials while they were still
stuck in the limiter.

A better but more complicated approach is a time budget system but we can
implement that later.

This change simply applies the limit to each `DialPeer`/`NewStream` call
independently and makes it easy to override. While old timeout tried to
account for how much we're willing to spend dialing a single peer, this new
timeout tries to account for the amount of time a single "client" is willing to
wait for a dial to complete before they no longer care.