You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
notthetup
changed the title
Add support for a connection oriented WebSocket connector
Add support for a connection oriented WebSocketConnector
Apr 3, 2024
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
The text was updated successfully, but these errors were encountered: