Bug 4859 - Decide how to handle multiple services over the WebSocket protocol
Summary: Decide how to handle multiple services over the WebSocket protocol
Status: ASSIGNED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: 4.1.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Peter Åstrand
URL:
Keywords:
Depends on:
Blocks: 4700 4822 4823
  Show dependency tree / graph
 
Reported: 2013-10-21 10:54 CEST by Peter Åstrand
Modified: 2015-06-20 14:59 CEST (History)
0 users

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Peter Åstrand cendio 2013-10-21 10:54:03 CEST 
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:
http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name

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:
http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-11
Looks fairly good, but I haven't found any actual implementations.
Comment 1 Peter Åstrand cendio 2013-10-28 10:45:34 CET 
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.
Note You need to log in before you can comment on or make changes to this bug.