-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
IPNS republisher should not rely on DHT to store (possibly expired) records #4749
Comments
@whyrusleeping do you have a suggestion for how we should store these records? |
Proposal: make the republisher wrap the namesys service in a republishing namesys service. When calling Thoughts? |
That sounds like a reasonable proposal to me. |
Should we merge in the PR to use variadic options for the namesys interface first? |
@Stebalien is this what you were imagining? #4753 |
So, as I noted on that PR, the underlying namesys relies on this record itself to keep track of the sequence number. I can think of three solutions:
|
Quick note: you should be able to update to latest-gx-tagged |
I noticed that the Pubsub publisher puts an IPNS record directly into the datastore, so that the republisher can later retrieve the record's sequence number. But it looks like namesys will always publish to both the DHT and to Pubsub anyway, so is it necessary for Pubsub publisher to do this? |
And I guess a related question: Should the republisher care about records published directly to Pubsub (but not to the DHT)? |
That's so that both itself and the DHT publisher can find it; the latter is important if you run your daemon having disabled pubsub. |
And yes, i think the republisher should care about pubsub published records, as these will have a different seqno. |
It looks like the pubsub record sequence number may be different from the DHT record sequence number for the same value in the following scenario:
I'm not sure if that actually causes any problems, but it's probably worth fixing |
Yes, that's an artifact of the implementation. |
But since we are hacking the publishers, we might as well go the extra mile and have them use the same seqno for the record. |
Yes I agree, @Stebalien suggested simply comparing the values to make sure the sequence number is not incremented when the same value is published. |
Is there a case in which we would want to publish only to pubsub (but not to the DHT)? I'm wondering if the pubsub publisher should call out to the DHT publisher itself, which would take care of all the sequence number handling that the pubsub publisher has to do at the moment |
Currently no, but we might want this in the future. |
I think if we don't always publish to the DHT it will cause an issue with publishing to a key shared between peers:
|
fixes #4749 License: MIT Signed-off-by: Steven Allen <[email protected]>
fixes #4749 License: MIT Signed-off-by: Steven Allen <[email protected]>
fixes #4749 License: MIT Signed-off-by: Steven Allen <[email protected]>
fixes #4749 License: MIT Signed-off-by: Steven Allen <[email protected]>
fixes #4749 License: MIT Signed-off-by: Steven Allen <[email protected]>
fixes #4749 License: MIT Signed-off-by: Steven Allen <[email protected]>
fixes #4749 License: MIT Signed-off-by: Steven Allen <[email protected]>
fixes #4749 License: MIT Signed-off-by: Steven Allen <[email protected]>
The republisher relies on the DHT to store records, but those records may expire before republish occurs (eg if the republishing node goes offline). We should store them somewhere else in the datastore.
See #4742 (comment) for more details
The text was updated successfully, but these errors were encountered: