Skip to content

ProtocolId re-work #3980

@realbigsean

Description

@realbigsean

Description

ProtocolId contains a single Version enum for all protocols, this doesn't really make sense though because protocols are versioned independently. Places where this isn't great include #3972 where we want a complete match across protocol + version, but currently this means matching on protocol + version combinations that don't actually exist, e.g. LightClientBootstrap + Version::V2. Also handle_v1_response the handle_v2_response end up being very confusing to work with because some v1 protocols end up having functionality more similar to v2 protocols (e.g. fork-awareness in the blobs by range v1 protocol is almost the same as fork-awareness in blocks by range v2 protocol and very unlike the blocks by range v1 protocol) but have to be handled independently.

Options:

  • Add variants per-version to Protocol. Maximally strict but maybe makes the most sense.
enum Protocol {
    MetadataV1,
    MetadataV2,
...
}
  • Nest version enums inside each protocol. More verbose, but more flexible
enum Protocol {
    Metadata(MetadataVersion),
    BlocksByRange(BlocksByRangeVersion),
...
}

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions