Extend cardano-ping to output handshake negotiation parameters

[coot]

This can be useful to discover what are the capabilities of the remote end. We want to use this to check how many P2P nodes are deployed on mainnet.

[coot]

The handshake decoder is implemented by cardano-ping here. A reference codec from ouroboros-network-protocols.

This issue requires:

• extending the codec so that it decodes NodeToNodeVersionData (and NodeToClientVersionData). Reference codecs:
  • NodeToNodeVersionData serialisation
  • NodeToClientVersionData serialisation
• adding a flag --handshake, when this flag is present cardano-ping should trace negotiated protocol version together with a NodeToNodeVersionData (or NodeToClientVersionData) as received from the remote side, e.g.

{ type: `node-to-node`
, version: 10
, networkMagic: 123456
, diffusionMode: 'InitiatorOnly'
}

[coot]

It turns out, as pointed out by @karknu, cardano-ping already prints the version number together with negotiated parameters. But this is not good enough, we need a way to know what the inbound side original version data is, not the one that were negotiated. This requires some changes.

I suggest that we add extra boolean flag in NodeTo{Node,Client}VersionData called query. If it was received the inbound side will replay not with the negotiated options but with its original parameters. Then the outbound & inbound sides can compute the intersection on their end (they will agree, version data form a monoid, although it might not be commutative when we introduce peer-sharing). If the inbound side does not agree with what it would receive it can reply with MsgRefuse instead of MsgAcceptVersion. This way we don't need to modify the protocol itself.

Or we modify the handshake to always act like that (from the next protocol version).

We can also consider if the handshake should just terminate in the query mode, although think this is not necessary.

[jprider63]

@coot, for the first approach, is my understanding correct that the idea is to add a query flag that asks the other party to return a list of supported versions instead of the negotiated options? Then we can log this list and each side can independently compute the negotiated options. Doesn't this require modifying the protocol? What needs to happen to properly modify the protocol?

Can you point me to where in the code the other party handles this request and how the options are negotiated?

Also, it seems like cardano-ping re-implements some of the data types and their codecs. Do you know why this is the case and it doesn't import them?

[coot]

NodeTo{Node,Client}VersionData can have different serialisation for different NodeTo{Node,Client}Version (we use the same type just for convenience, we used to have a GADT but it made things more complex than necessary). Since this flag will only be true for the new versions, the protocol can have a slightly different behaviour.

Here are the links:

• Handshake protocol
• client application
• server application
• the top level API is exposed here

Then there are node-to-node and node-to-client specific types, e.g. versions, version data and their serialisation / deserialisation; they are defined in these modules:

• Ouroboros.Network.NodeToNode.Version
• Ouroboros.network.NodeToClient.Version