Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Set/rework libp2p connection limits #4095

Closed
emberian opened this issue Dec 17, 2019 · 0 comments
Closed

Set/rework libp2p connection limits #4095

emberian opened this issue Dec 17, 2019 · 0 comments
Labels
consider-for-closing daemon stale triage

Comments

@emberian
Copy link
Contributor

Right now we just use the defaults, copying the note from coda_net2.mli:

In the original coda_net, connection limits were enforced synchronously on every received connection. Right now with coda_net2, connection management is asynchronous and post-hoc. In the background, once per minute it checks the connection count. If it is above the "high water mark", it will close ("trim") eligible connections until it reaches the "low water mark". All connections start with a "grace period" where they won't be closed. Peer IDs can be marked as "protected" which prevents them being trimmed. cmr believes this is vulnerable to resource exhaustion by opening many new connections.
@emberian emberian mentioned this issue Dec 17, 2019
Merged
bkase pushed a commit that referenced this issue Feb 10, 2020
@emberian
New gossip_net backend using libp2p (#3988)
16b8125 
This is the revival of the tmp/cmr/net2 branch rebased onto develop. 

Some important user-facing changes:

- No separate discovery/communication/etc ports. One port for all public daemon communications.
- Automatic port forwarding with UPnP. If your local network supports UPnP, there should be no configuration required.
- Local peer discovery. If your local network supports mDNS broadcast, coda daemons will automatically discover each other. This includes several daemons on the same machine- no more building peer lists!
- New libp2p keypairs. These are managed  the same as our key pairs with secret_file. Without configuration, key pairs are ephemeral and will disappear when the daemon restarts. (TODO: should we instead persist  the keypair? does it matter for  non-infrastructure?)

Some important internal changes:

- All daemon-daemon connections are now authenticated and confidential.
- Connections are no longer transient and per-request. Individual requests get multiplexed as their own stream over the one connection between the peers. This is analogous to HTTP/2. Outgoing connections will appear to originate from the libp2p listening port, vs some transient port. 

Outstanding details:

- Trust system needs to get augmented to track Peer.t instead of just an IP. Until then we can't implement ban_notify (#4093, #4096).
- Libp2p has little per-connection structured reporting, some things we currently penalize trust for are not detected (eg opening a libp2p connection without also
opening a coda RPC stream) (#4098).
- New pubsub allows banning senders by peer ID. We currently don't do this but we should ban peerIDs that originated bad info and not just the IP of the whoever relayed it to us (#4096).
- ~~Current pubsub validation flow goes a bit against the libp2p grain, and it's not clear to me that the current behavior will survive [this libp2p PR](libp2p/go-libp2p-kad-dht#388). There's an inline comment near the should_forward_message impl (#4097).~~ done
- Connection limit enforcement (#4095)

Other changes:

- Rips out the last vestiges of old membership, which aren't in use.
- The connection info in envelopes is much more accurate now. We shouldn't start trusting it just yet due to some future vagaries around relaying.
- bump nixpkgs version

Future improvements:

- IPv6. There's a hardcoded IPv4 assumption in the helper around IP filtering. 
- Investigate libp2p autorelay. This should help nodes in restrictive networks achieve better connectivity, but has a host of problems.
- Intelligent request routing. I believe we can use the "provider" feature to, at the very least, only send eg sync/bootstrap requests to nodes who believe themselves to be in sync. There are other options.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
consider-for-closing daemon stale triage
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@emberian @es92 @shimkiv @nholland94