Sprint Proposal: Connection Closing

[whyrusleeping]

This won't be super well thought through quite yet, but i'm just going to list some things that need to be done and requirements:

• Need to close connections to other peers
  • requires having a metric for choosing which peers to disconnect from
• Need bootstrap only peers
• Need disk backed peerstore
• Need ephemeral port filtering

[dgrisham]

@whyrusleeping guessing this needs to be discussed still, but as far as a metric for choosing peers to disconnect from are you thinking something related to Bitswap metrics (e.g. debt_ratio)? Or more like the connection state (older connections, LRU connections, etc.)? Mainly asking because, as I understand it, IPFS nodes are currently altruistic so Bitswap may not be the focus for this.

Also, I'd be interested in joining this sprint when it comes around.

[ghost]

Yes this is at first more about getting rid of unneccessary connections. Right now we don't ever disconnect unless there's network problems underneath.

[dgrisham]

Gotcha, thanks Lars. @lgierth @whyrusleeping Given my relative lack of IPFS experience, would there be anything in particular I could familiarize myself with if I wanted to be useful in this sprint?

[whyrusleeping]

@dgrisham Yeah, I would make sure youre familiar with kademlia DHTs, and some of the characteristics that ours has in particular (including things like "we use tcp by default right now"). Basically get familiar with all the reasons ipfs nodes need to talk to eachother and why.

Past that, theres this issue: libp2p/go-libp2p#45 that doesnt have much, but should be worth reading through.

This problem is really not a super technical one, it just requires a good amount of thinking about heuristics.

I was thinking of doing something like an LRU, but have the 'use' factor be determined by useful work between peers, so making random dht queries or responding to them shouldnt cause us to keep connections open unnecessarily).

There will also be a lot of experimental work to be done, this will likely involve parsing eventlogs (ipfs log tail) to observe real world behaviour.

If you need any help finding anything or have any questions, feel free to ping me! I respond most reliably on IRC

[dgrisham]

@whyrusleeping Awesome, thanks! I know the basics of Kademlia and related work, but only from research papers. I'll check out the IPFS DHT specs and source code to get a handle on the implementation.

The experimental work should be fun, may be useful to use the test-lab to gather data/test specific cases.

How soon would you expect this sprint to happen?

[daviddias]

linking here ipfs/js-ipfs#962 as this will be crucial for js-ipfs as well.