Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

Gateway should return the peerId along with the block in the response #476

Closed
KrishnaPG opened this issue May 22, 2019 · 1 comment
Closed

Comments

@KrishnaPG
Copy link

KrishnaPG commented May 22, 2019

When a file or block is queried from a public gateway using the hash, the gateway queries the peer nodes and gives back the content as http response.

For example,

The question is:

  • is there any way, say response header or some other way, of knowing from which peer / remote machine the gateway retrieved the content ? (in the above example my machine's peer-id)

This issue is to request the feature, where:

  • the gateway includes the source peerId in the response header (along with the block / file content in the body), and
  • the caller can then use the block, and also use the peerId to query any further blocks directly (bypassing the gateway as much as possible).

While public gateways offer flexibility, they are centralized structures, and including the source peerID in the response encourages more distributed usage (at least for programmers who want to utilize that information and build distributed retrieval paradigms)

@alanshaw
Copy link
Contributor

I don't think this is possible right now. With the current implementation of bitswap there's no guarantee all the data came from a single node. Bitswap queries local peers and then the DHT and receives blocks from potentially many different peers. Peer(s) a block came from (we sometimes receive dups) are not tracked in memory or on disk.

There's also the problem of once we recieve blocks they remain in the repo until the next gc run, so a subsequent request would result in a different peer (ourself) unless we persisted information about who sent us a block for every single block we ever create or recieve.

Also, in a HTTP response, it would be difficult to communicate that information. We could possibly communicate who sent us the first block but not the rest.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants