You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Goal: I’d like to know what percentage of requests served through the gateway and resolved through the DHT are served within the first 10mins of the CID/Provider Record being published.
Context: Routing tables are refreshed every 10 mins and after the first 10mins of the CID/Provider Record being published the multiaddress of the original publisher is not included in the record anymore - that's in order to cover the case where a peer has gone offline and back online and it's multiaddress is not the same anymore. So one way to figure out what I need is to count the number of provider records returned to the gateway and include a multiaddress (as compared to those that don’t include a multiaddress). In that second case, clients have to walk the DHT again to map the PeerID to the peer's latest multiaddress.
A small modification on a gateway's kubo node should be able to do the trick. It would be great to have that in the next 3 weeks or so (if possible), as it will influence some other design decisions.
The text was updated successfully, but these errors were encountered:
Goal: I’d like to know what percentage of requests served through the gateway and resolved through the DHT are served within the first 10mins of the CID/Provider Record being published.
Context: Routing tables are refreshed every 10 mins and after the first 10mins of the CID/Provider Record being published the multiaddress of the original publisher is not included in the record anymore - that's in order to cover the case where a peer has gone offline and back online and it's multiaddress is not the same anymore. So one way to figure out what I need is to count the number of provider records returned to the gateway and include a multiaddress (as compared to those that don’t include a multiaddress). In that second case, clients have to walk the DHT again to map the PeerID to the peer's latest multiaddress.
A small modification on a gateway's kubo node should be able to do the trick. It would be great to have that in the next 3 weeks or so (if possible), as it will influence some other design decisions.
The text was updated successfully, but these errors were encountered: