Skip to content

mgnp: better error handling #23

Description

@hawkw

right now (as of 87dc51d) we handle frame decode/encode errors by "just skipping the frame", and wire errors by "just stop running the interface". here's what we should do instead, IMO:

  • on outbound frame serialize errors, do: send an error back to the local conn that sent that frame
  • on inbound frame decode errors, do:
    • if we were able to decode the header and get a link ID, then: close the connection for that link ID (send a RESET to the remote/an error to the local channel, or a NAK if it was a connection being established?) and remove it from the conn table
    • else if we weren't able to decode the header and get a link ID, then: either destroy the whole interface and reset all conns, or...log an error and ignore it? idk @jamesmunns what do you think?
  • on outbound frame wire send errors, do:
    • if it was a DATA or CONNECT frame, then: send an error back to the local conn?
    • if it was an ACK, NAKor RESET then: we're probably fucked, blow up the whole link?
    • if we were trying to send a RESET due to a previous error, then: hahaha we're Super Fucked, destroy everything as violently as possible
  • on inbound frame wire recv errors, do: idk, either ignore it or destroy the whole world probably? @jamesmunns what do you think?

imo if the Wire sees an error that it's capable of retrying or believes to be ignorable, it should just ... do that? and the only errors that should bubble up from the Wire are fatal-ish and should blow up the whole interface.

currently, wire errors just make us stop the interface state machine. they should actually send errors on all existing local connections.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions