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

feat: add support initial peerstore support #14

Merged
merged 3 commits into from
Mar 25, 2019
Merged

Conversation

jacobheun
Copy link
Contributor

@jacobheun jacobheun commented Mar 22, 2019

This also bumps to the latest release candidate for js-libp2p

Note: the spec for this is still underway and may be subject to change, libp2p/go-libp2p-daemon#91. This is to unblock interop testing with identify in support of the gossipsub needs for peer protocol knowledge.

@jacobheun jacobheun marked this pull request as ready for review March 25, 2019 13:31
@jacobheun jacobheun changed the title [WIP] feat: add support initial peerstore support feat: add support initial peerstore support Mar 25, 2019
Copy link
Member

@vasco-santos vasco-santos left a comment

Choose a reason for hiding this comment

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

I noticed that you did not implement the remaining operations. Considering that we only need this one for now, I am ok with implementing just that, but I would expect the other ones to throw ERR_NOT_IMPLEMENTED. What do you think?

message PeerstoreRequest {
enum Type {
GET_PROTOCOLS = 1;
GET_PEER_INFO = 2;
Copy link
Member

Choose a reason for hiding this comment

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

What about the remaining types of PeerstoreRequest?

libp2p/go-libp2p-daemon#91/files#diff-d864c93b68284fafd809efbf29a1f0ebR166

Copy link
Member

Choose a reason for hiding this comment

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

So, I noticed that you have only implemented GET_PROTOCOLS here.

Can I recommend adding the other ones and then throw a ERR_NOT_IMPLEMENTED for that? Moreover, can you create an issue for tracking the remaining ones?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I'll create an issue for when the spec gets done. I only added these initial two, as those likely won't change, but since the spec is still being discussed it didn't make sense to me to pull in a bunch of theoretical types.

I'll add ERR_NOT_IMPLEMENTED for the types that are currently in the proto file.


required Type type = 1;
optional bytes id = 2;
repeated string protos = 3;
Copy link
Member

Choose a reason for hiding this comment

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

We are also missing some properties here and in the response.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've only added the required properties for the two types that are here. The rest should be added once the spec is merged for the other types.

const message = await stream.first()
let response = Response.decode(message)
expect(response.type).to.eql(Response.Type.OK)
expect(response.peerStore).to.eql({
Copy link
Member

Choose a reason for hiding this comment

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

Why not expect(response.peerStore.protos) instead?

peer: null is not part of the spec, and we could potentially accept anything else there in the future, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

peer is a response field for GET_PEER_INFO, which is currently not implemented. I'm validating the full response to ensure that no additional fields are being "leaked"/accidentally set in the response. While expect(response.peerStore.protos) verifies I am getting the correct protocols, it doesn't fully verify I am getting the expected response.

@jacobheun
Copy link
Contributor Author

I added #15 to track the implementation of the remaining peerstore types, once the initial spec is merged.

Copy link
Member

@vasco-santos vasco-santos left a comment

Choose a reason for hiding this comment

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

LGTM!

@jacobheun jacobheun merged commit 36a520c into master Mar 25, 2019
@jacobheun jacobheun deleted the feat/update-protos branch March 25, 2019 15:38
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

Successfully merging this pull request may close these issues.

None yet

2 participants