The current implementation of the WebSocketConnector is a "Hub-style" connector, where it collects all incoming WebSockets connections and streams a single input stream to the single ConnectionHandler.
This is very useful in the case of WebShell where the final consume (ShellAgent) can only consume/generate a single stream so the stream has to be replicated to all the WebSocket clients.
However, with the API side of things, this causes an issue since multiple users could be connected to the same MasterContainer but the MasterContainer will treat them all as a single user since it only sees a single ConnectionHandler. This causes the browser-based fjåge Gateways to be unable to perform the wantsMessagesFor action.
The downside of not supporting this action is the browser-based fjåge Gateways get a ton of unwanted messages which affects performance especially over slower connections.
We should add support for a WebSocketConnector like the TCPConnector that can be spawned on a new connection and independently manage the connection to a single WebSocket client. We can keep the current functionality of WebSocketConnector and rename as WebSocketHubConnector since it is similar to the TCPHubConnector
The current implementation of the WebSocketConnector is a "Hub-style" connector, where it collects all incoming WebSockets connections and streams a single input stream to the single ConnectionHandler.
This is very useful in the case of WebShell where the final consume (
ShellAgent
) can only consume/generate a single stream so the stream has to be replicated to all the WebSocket clients.However, with the API side of things, this causes an issue since multiple users could be connected to the same MasterContainer but the MasterContainer will treat them all as a single user since it only sees a single ConnectionHandler. This causes the browser-based fjåge Gateways to be unable to perform the
wantsMessagesFor
action.The downside of not supporting this action is the browser-based fjåge Gateways get a ton of unwanted messages which affects performance especially over slower connections.
We should add support for a
WebSocketConnector
like theTCPConnector
that can be spawned on a new connection and independently manage the connection to a single WebSocket client. We can keep the current functionality ofWebSocketConnector
and rename asWebSocketHubConnector
since it is similar to theTCPHubConnector