Expose bitswap sessions through a global flag

[magik6k]

We could expose sessions to commands through a global flag, which would take a random session id, and potentially some parameters, like timeout:

ipfs get --session-id=4e237431db9b4e6d425b-10m /some/path
ipfs get --session-id=4e237431db9b4e6d425b-10m /other/path
ipfs get --session-id=4e237431db9b4e6d425b-0 /yet/another/path

First invocation would create the session and store it somewhere, second and third would re-use it, after 3-rd get is done, the session would get removed.

We should also consider creating sort of 'session GC' to cleanup sessions in case we accumulate too many (and to make it safe to expose on gateway port)

cc @Stebalien @hannahhoward

[hsanjuan]

Hi, this would be super useful for Cluster, particularly in block get. I was just talking to @hannahhoward about it.

[hannahhoward]

So, this is a sizable undertaking but potentially worth it. It would need to track sessions all the way down through DagService -> BlockService -> Bitswap to be useful. Marking it an open and valid feature request but not sure if/when we will get to it.

[Stebalien]

This may be easier than you think. We already expose bitswap sessions all the way up to CoreAPI.

[hannahhoward]

so quick glance at the code showed me the following:

• coreAPI as implemented inside go-ipfs does have a getSession method, but it's private (only used by UnixFS API)
  • said method does not actually create a session for the blockService, only the dag service (not sure if this is relevant for the use case abov)
• getSession is called internally to UnixFS CoreApi commands, and we probably would need to check somehow that the API wasn't already "session-ed" as it were :)
• getSession should probably be renamed GetSession and be exposed on interface-go-ipfs-core (needed at minimum to support the use case here)
• @magik6k might have thoughts on the best way to do this.
• I think given how fundamental sessions are to performance, and most things built on IPFS use CoreAPI, having a method to expose a session at that level feels pretty important, even if we don't implement this command line level technique

[hsanjuan]

Heads up that this is no longer high prio for Cluster since we decided to run the whole exchange internally and use cluster's DHT and swarm to exchange that data so we have access to sessions.

It might be useful in the future though, for getting pinned content block-by-block when that content is sharded across multiple ipfs peers.