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.

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

Negotiate time frames before request #37

Open
s-tikhomirov opened this issue Oct 17, 2023 · 3 comments
Open

Negotiate time frames before request #37

s-tikhomirov opened this issue Oct 17, 2023 · 3 comments

Comments

@s-tikhomirov
Copy link
Contributor

s-tikhomirov commented Oct 17, 2023

Currently, if a node signals that it suns Store (as a server), it is assumed that it can respond to any client request. This assumes that each Store node stores all past messages forever, which may not be sustainable. Explore the following idea:

  • a server can choose which pieces of history it serves;
  • a server announces what past periods it covers;
  • a client chooses a server accordingly.

Two sub-ideas on how time frame negotiations can happen:

  1. servers announce them proactively in the P2P network;
  2. a client asks a particular server before sending the actual request.
@alrevuelta
Copy link
Contributor

Indeed. Related to capability discovery. Ideally we should use 1) since its more efficient than 2). In other words, having this capability announcement as part of discovery, allows peers to search for the capability they are interested in a more efficient way. 2. would require going node by node, setting up a connection to query the capabilities, which is very inneficient.

@s-tikhomirov
Copy link
Contributor Author

we should use 1) since its more efficient

On the other hand, 1) distributes the burden to the whole network, while in 2) only the two involved nodes care about this negotiation. I'm thinking about edge cases, for example, when the description of which time frames a node covers is in itself heavy. A malicious operator could set up its node such that it covers lots of small irregular intervals, and everyone would have to sync this across the DHT or whatever peer discovery mechanism. This is likely a secondary concern though.

@alrevuelta
Copy link
Contributor

A malicious operator could set up its node such that it covers lots of small irregular intervals, and everyone would have to sync this across the DHT or whatever peer discovery mechanism

yep, we should limit this to a fixed (or max) length field. The simpler the better. I dont think it would be necesary to allow for weird configurations. Just "this node stores the last x days" in shard y", where x and y are parameters advertised as capabilities in the discovery layer.

@s-tikhomirov s-tikhomirov changed the title Negotiate time frames before request in Store Negotiate time frames before request Nov 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants