core-geth icon indicating copy to clipboard operation
core-geth copied to clipboard

JS console: admin.nodeInfo.protocols.snap.version missing?

Open meowsbits opened this issue 4 years ago • 4 comments
trafficstars

admin.nodeInfo.protocols.snap differs from the node information returned via admin_peers.

Snippet call/response from JS console:

      snap: {}

à la:

> admin
{
  datadir: "/home/ia/SAMSUNG_T5/e/clients/core-geth/classic",
  nodeInfo: {
    enode: "enode://c195c4b7b90468d660f832ab5fbd3c11abf8dc8864b79d6c198008753d2174d8e462551e89e89a0eb41b13efb4872f698963640a3e02f36835225ce435bc56e1@35.132.144.253:30361",
    enr: "enr:-vC4QFZHHdlimRY56gFwhtQBleymnhopM-mXTIxnHnnLySJ2CHvp2yY1XF1ahLoT5kN193YCBrGBvrBsHbvNadosQF4Eg2V0aMrJhNtjocqDyUANgmlkgnY0gmlwhEuGkPyJc2VjcDI1NmsxoQOxlcS3uQRo1dD4MqtfvTwRq_jMiGS3nWwZgAh1PSF02IRzbmFwwIN0Y3CCdpmDdWRwgnaZ",
    id: "743d52467f97cd6ef40a3872108c0cad7bd7f77bd0803b0ed7b0c459c7bbc339",
    ip: "35.132.144.253",
    listenAddr: "[::]:30361",
    name: "CoreGeth/v1.12.1-unstable-0d47cc62-20210701/linux-amd64/go1.16.2",
    ports: {
      discovery: 30361,
      listener: 30361
    },
    protocols: {
      eth: {
        config: {...},
        difficulty: 17179869184,
        genesis: "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3",
        head: "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3",
        network: 1
      },
      snap: {}
    }
  },
  peers: [],

Snippet of admin_peers response via nc from IPC connection:

  "protocols": {
    "eth": {
      "difficulty": 1.284669335778087e+21,
      "forkId": {
        "hash": "0xdb63a1ca",
        "next": 13189133,
        "tag": "Thanos",
        "nextTag": "Magneto"
      },
      "head": "0xf50b11495261ca9496f81d6852317b719c305ba57ac2eb2820f7e6da2e1d7b42",
      "version": 66
    },
    "snap": {
      "version": 1
    }
  },

meowsbits avatar Jul 05 '21 15:07 meowsbits

Will check @meowsbits

ziogaschr avatar Jul 05 '21 15:07 ziogaschr

@meowsbits I believe that the diff comes from the confusion that the first example from geth console is for admin.nodeInfo while the 2nd example from nc is for admin_peers. Admin peers have version on snap for both APIs.

I am thinking if it makes sense to add version for admin.nodeInfo.protocols.(eth|snap).version and I am leaning to no (only reason for a yes, is that it has the config as well), what do you think?

ziogaschr avatar Jul 06 '21 09:07 ziogaschr

Oh, I see. Thanks for figuring this out. I updated the original post.

So the existence of snap: {} means that snap is turned on, but the admin.nodeInfo.protocols objects DO NOT (and are not supposed to) contain version information?

Is there currently any way to see what protocol versions are running/supported (from admin perspective)? If not, worth pursuing? (Or a: "please see/share your CLI args" dialogue :joy:).

reason for a yes, is that it has the config as well I'm not sure I follow this; can you say more about this?

meowsbits avatar Jul 06 '21 11:07 meowsbits

admin.nodeInfo.protocol gives the protocols supported by our own node, based on the exact struct and its use case I think version won't be a nice addition. (forget about my config thinking bubble)

admin.peers gives some info that you want to check for other peers (including version) and that you don't know by checking your CLI args :)

Having an API to read your supported protocol versions is an idea, which I think I left out on our latest related PRs for a specific reason which I can't recall. (will check it)

ziogaschr avatar Jul 06 '21 11:07 ziogaschr