Package com.ultikits.ultitools.websocket
Connection lifecycle, reconnect strategy and inbound message dispatch for the link to UltiPanel. The whole subsystem is driven by the framework: it is created after a successful cloud login and torn down on shutdown. The wire protocol is a private contract between this client and the panel worker, and both sides change together — nothing here is a stable extension point.
The live dispatch path is UltiPanelWebSocketClient plus the inbound-message dispatch
table PluginInitiationUtils#handleInboundMessage builds for the framework's own message
types, with PanelResponderRegistry as the single-owner extension point a module uses to
claim a request/response responder for a type the framework does not own (WIRE-16).
This package previously also held a second, superseded dispatch mechanism — a
registry-plus-interface pair with five per-message-type implementations, formerly the sole
public class of a now-deleted handlers sub-package (WIRE-17) — replaced by the dispatch
table above in Phase 1 (plan 01-05) but left in the tree, unreferenced, until it was deleted in
6.3.0 (GEN-11, see compatibility/records/6.3.0.md). A reader arriving here from an old
link to that cluster will not find it; this is why.
- Since:
- 6.2.5
-
ClassDescriptionExponential backoff reconnection strategy.Builder for ExponentialBackoffStrategy.Writes the framework's lines about the panel connection itself to the server console, marked so the panel's log stream never sends them back to the panel (as of 6.3.0).The mark: a record of this type is a panel-connection line.The single-owner registry a module uses to claim a request/response responder for a panel message type the framework itself does not own (WIRE-16, D-26/D-27).An immutable pairing of a responder function with the module name that registered it and, when the registration named one, the module instance (#506).Strategy interface for WebSocket reconnection behavior.UltiPanel WebSocket Client