Sets up the RPC handler by populating connector info, setting up event handlers, and doing one of the following:
An implementation that opens an endpoint MUST NOT resolve true until that endpoint is
actually accepting connections. Callers treat this resolving as permission to start processes
that immediately connect, and those clients may get a single attempt with no retry — so
reporting ready optimistically surfaces as a client that was refused, whose symptoms appear in
a different process entirely. See adr-papi-websocket-hostname-bind.
Function that handles events from the server by accepting an eventType and an event and emitting the event locally. Used when receiving an event over the network.
true once the connection is established and usable — for a server, once its endpoint
is accepting connections. false if the connection could not be established.
TODO(PT-4495): implementations disagree on what they return when this handler was already connected or connecting, so a caller can neither rely on that case nor tell a benign double-connect from a real failure. PT-4495 replaces the boolean with a result type that distinguishes the three outcomes; until then, only the two states above are contractual.
Whether this connector is setting up or has finished setting up its connection and is ready to communicate on the network
Disconnects from the connection:
Sends an event to other processes. Does NOT run the local event subscriptions as they should be run by NetworkEventEmitter after sending on network.
Send a request and resolve after receiving a response
Type of request (or "method" in JSONRPC jargon) to call
Parameters associated with this request
OptionalskipRetry: booleanWhether to skip the retry process that will retry up to 10 times
Promise that resolves to a JSONRPCSuccessResponse or JSONRPCErrorResponse message
Defines how to support sending requests on the network and emitting events on the network
NOTE: In JSONRPC jargon, a "request" is made to a "method". In our code we talk about "request types", but JSONRPC doesn't have the notion of a "request type". However, a "request type" is really just the name of a method in JSONRPC. So "method names" and "request types" are treated as the same thing. Similarly, what we call a "request handler" is the same thing as a "method" that has been registered with a JSONRPC server.