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

Extend VersionPayload with service information #548

Closed
ixje opened this issue Jan 15, 2019 · 9 comments
Closed

Extend VersionPayload with service information #548

ixje opened this issue Jan 15, 2019 · 9 comments
Labels
Discussion Initial issue state - proposed but not yet accepted

Comments

@ixje
Copy link
Contributor

ixje commented Jan 15, 2019

Currently if one wants to discover available network services like RPC or REST you need to know about http://monitor.cityofzion.io/, https://happynodes.f27.ventures/ or something alike.

A solution to discover such services via the network would be to extend the VersionPayload with RPCPort, RESTPort and Websocket port (the most common ones currently missing). Then turn the Services into a flag that indicates which services are enabled.

public ulong Services;

This allows one to connect to the network and discover available services via the nodes (through a combination of PeerInfo requests and VersionPayload's). The aforementioned websites could also discover more available services improving the overall user experience.

@erikzhang erikzhang added the Discussion Initial issue state - proposed but not yet accepted label Jan 15, 2019
@erikzhang
Copy link
Member

The VersionPayload.Services field is basically designed for this purpose.

@ixje
Copy link
Contributor Author

ixje commented Jan 15, 2019

That's what I expected, but we miss the port information elsewhere

@erikzhang
Copy link
Member

Once we add the Services flags, we can extend the VersionPayload structure.

@ixje
Copy link
Contributor Author

ixje commented Jan 15, 2019

is this planned for 3.0 or perhaps sooner?

@erikzhang
Copy link
Member

Example:

void ISerializable.Deserialize(BinaryReader reader)
{
    Version = reader.ReadUInt32();
    Services = (ServicesFlags)reader.ReadUInt64();
    Timestamp = reader.ReadUInt32();
    Port = reader.ReadUInt16();
    Nonce = reader.ReadUInt32();
    UserAgent = reader.ReadVarString(1024);
    StartHeight = reader.ReadUInt32();
    Relay = reader.ReadBoolean();
    if (Services.HasFlag(ServicesFlags.Websocket))
    {
        WebsocketPort = reader.ReadUInt16();
    }
    ...
}

@ixje
Copy link
Contributor Author

ixje commented Jan 15, 2019

Looks good

@shargon
Copy link
Member

shargon commented Jan 15, 2019

We should add protocol version, and the possibility to negotiate other protocols, in the future we should consider to use UDP for receive messages.

@shargon shargon mentioned this issue May 10, 2019
@shargon
Copy link
Member

shargon commented May 21, 2019

Done with the Capabilities

@ixje
Copy link
Contributor Author

ixje commented Dec 9, 2019

Done with the Capabilities

@shargon @lock9 please reopen as capabilities do not seem to be intended for the purpose of sharing RPC or REST services according to #1342 (comment)

@lock9 lock9 reopened this Dec 16, 2019
Thacryba pushed a commit to simplitech/neo that referenced this issue Feb 17, 2020
* Create 2.7.6 branch for CLI API

* Update cli.md (neo-project#548)

* Update cli.md

Revise for the new version's features.

* Update cli.md

Reviese for the example of request.

* Update cli.md

Add blank for values

* Update cli.md

Add blank.

* Update api.md (neo-project#551)

Add getvalidators API

* Create getvalidators.md (neo-project#553)

Add getvalidators.md

* release 2.7.6
@ixje ixje closed this as completed Feb 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Initial issue state - proposed but not yet accepted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants