Skip to content

Hypervisor RPC always over a transport, dmsg-type transport as the floor #4752

Description

@0pcom

The visor's RPC connection to its hypervisor (ServeRPCClient, pkg/visor/rpc_client_serve.go) dials a bare dmsg stream unless a direct stcpr/sudph/ws transport exists, in which case it rides skynet. That split dates from the hypervisor being a separate dmsg-only process. Today a dmsg-type transport exists (#4707), so the RPC path can always ride skynet over a transport, with a dmsg-type transport as the floor when nothing direct is up.

What that removes: the dmsg-or-skynet decision and its 5-minute cooldown, the watchForSkynetUpgrade poll, and the 90 s idle timer, because transport ping/pong is the liveness signal and a dead transport tears the route down, which closes the RPC conn and triggers the redial. The absent-peer backoff from #4748 stays, keyed on "no transport and no entry".

Check before doing it: whether dmsg-type transports to a hypervisor should be registered in transport discovery (they are relay paths, not network edges) and how the tab's same-origin swsr transport fits (it already does; it is the direct case).

Follow-up to #4484 and #4750 phase 2.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions