Bug 4859 - Decide how to handle multiple services over the WebSocket protocol
: Decide how to handle multiple services over the WebSocket protocol
: ThinLinc
Web Access
: 4.1.0
: PC Unknown
: P2 Normal
: MediumPrio
Assigned To:
: 4700 4822 4823
  Show dependency treegraph
Reported: 2013-10-21 10:54 by
Modified: 2015-06-20 14:59 (History)
Acceptance Criteria:



You need to log in before you can comment on or make changes to this bug.

Description From cendio 2013-10-21 10:54:03
Currently, the HTML5 client only supports basic redirection of graphics,
keyboard, and mouse. When we start adding support for local devices such as
audio, printing etc, we need to transfer data for them as well. With the native
client, we are using SSH tunnels. We need to find something similar for the
HTML5 client. There are several possible solutions:

1) Using multiple TCP connections. To distinguish between the multiple
connections, we can either use different URLs, or use the Websocket
"subprotocol" support (http://tools.ietf.org/html/rfc6455#section-1.9). It
turns out that RFB is actually already registered as a subprotocol:

2) Using a single TCP connection. The base websocket protocol does not have any
multiplexing mechanism built in. There's an extension for that though:
Looks fairly good, but I haven't found any actual implementations.
------- Comment #1 From cendio 2013-10-28 10:45:34 -------
The Multiplexing Extension for WebSockets seems to be in a bad shape: The
interest is pretty low, and I haven't found any evidence that browser vendors
are planning to implement this in a near future. Haven't found any pure JS
implementation either. It might not be what we need. 

The good thing is that as long as we are following the WS protocol - staying
compatible with the browser implementations - we can change the solution in
future TL versions without problems, since the client side JS files are served
from the server which also acts as the WS server. 

So, I'd say that in the near future, we'll go for multiple WS connections and
thus multiple TCP connections. This also means that we will have multiple
tlwebaccess connection daemons on the server side. Although perhaps not
optimal, it will make the implementation easier. 

In the future, we can always change this, for example by creating our own
simple multiplexing protocol ("first byte indicates channel") etc. 

What remains now is to decide how we should distinguish between VNC and other
services such as audio. We can either use "subprotocol", or include such
information in the URL.