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

namesys: add entry to DHT cache after publish #3501

Merged
merged 4 commits into from
Dec 14, 2016

Conversation

Kubuxu
Copy link
Member

@Kubuxu Kubuxu commented Dec 13, 2016

Resolves #2078

License: MIT
Signed-off-by: Jakub Sztandera [email protected]

@Kubuxu Kubuxu added the status/in-progress In progress label Dec 13, 2016
License: MIT
Signed-off-by: Jakub Sztandera <[email protected]>
@Kubuxu
Copy link
Member Author

Kubuxu commented Dec 13, 2016

@whyrusleeping it isn't supper nice solution but without some refactor there isn't anything much better might be done.

@Kubuxu Kubuxu added the need/review Needs a review label Dec 13, 2016
path "github.com/ipfs/go-ipfs/path"

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@whyrusleeping whyrusleeping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why cant this be done at a slightly lower layer? Is it because the dht publisher and the dht resolver are different bits of code?

if err != nil {
return err
}
ns.addToDHTCache(name, value, time.Now().Add(time.Hour*24))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets pull this magic number out and justify it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is the same as in publisher.go, should I add comment for it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or extract it from publisher?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd extract it from both, and give it a small comment

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets just call it DefaultRecordTTL (i had to go look at it again to remember what exactly this was)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hah, gave it the same name without reading this. <3

var err error
value, err = path.ParsePath(value.String())
if err != nil {
log.Error("could not parse path")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe add the actual error to this? might aid in debugging random error messages

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only cache, I didn't want it to fail the publish (as it was already published and we can't revert it).

return ns.publishers["/ipns/"].PublishWithEOL(ctx, name, val, eol)
func (ns *mpns) addToDHTCache(key ci.PrivKey, value path.Path, eol time.Time) {
var err error
value, err = path.ParsePath(value.String())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wait, why are we converting the thing to a string, then back to a path?

Copy link
Member Author

@Kubuxu Kubuxu Dec 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes as the publisher can publish hash only but resolver will sanitize this value to be /ipfs/CID which is what ParsePath does.

License: MIT
Signed-off-by: Jakub Sztandera <[email protected]>
@Kubuxu
Copy link
Member Author

Kubuxu commented Dec 13, 2016

Yes, they are separate modules that don't know about each others existence.

@Kubuxu Kubuxu added this to the ipfs 0.4.5 milestone Dec 13, 2016
@wigy-opensource-developer

Is this problem IPNS specific? I love how this PR solves the problem in hand without changing much code, but I see it as a temporary fix that will need to be removed after the real issue has been addressed.

The caching could be moved into the DHT-based IPRS implementation, so the /pk/ namespace could benefit from it as well. Namesys uses both. I am not aware of other IPRS namespaces, but probably it would apply to any record types.

@Kubuxu
Copy link
Member Author

Kubuxu commented Dec 14, 2016

IPRS doesn't exist yet, I like to call IPNS a huge PoC that mutable data is possible even though the content is immutable.

Yes, after IPRS is designed, speced out, and implemented it can be moved into one place with infrastructure that will include caching of self published record in its design. When code of namesys was written it wasn't a feature that was taken into account.

License: MIT
Signed-off-by: Jakub Sztandera <[email protected]>
if err != nil {
return err
}
ns.addToDHTCache(name, value, time.Now().Add(DefaultRecortTTL))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: DefaultRecordTTL

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Me and my typos. Sorry.

License: MIT
Signed-off-by: Jakub Sztandera <[email protected]>
Copy link
Member

@whyrusleeping whyrusleeping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks @Kubuxu

@whyrusleeping whyrusleeping merged commit a47d1b0 into master Dec 14, 2016
@whyrusleeping whyrusleeping deleted the feat/namesys/publish-cache branch December 14, 2016 21:00
@whyrusleeping whyrusleeping removed the status/in-progress In progress label Dec 14, 2016
@ghost ghost mentioned this pull request Dec 23, 2016
@makew0rld
Copy link
Contributor

I am still experiencing slow ipns resolving. For a minute after I publish it will be fast, but then it takes a very long time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/review Needs a review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants