Merge branch 'master' of git@github.com:kanaka/noVNC
This commit is contained in:
commit
9aaf26e878
30
docs/TODO
30
docs/TODO
|
@ -1,19 +1,10 @@
|
|||
Short Term:
|
||||
|
||||
- Playback/demo on website.
|
||||
|
||||
- VNC performance and regression playback suite.
|
||||
- Keyboard layout/internationalization support
|
||||
- convert keyCode into proper charCode
|
||||
|
||||
- Test on IE 9 preview 3.
|
||||
|
||||
- Fix cursor URI detection in Arora:
|
||||
- allows data URI, but doesn't actually work
|
||||
|
||||
|
||||
Medium Term:
|
||||
|
||||
- Viewport support
|
||||
|
||||
- Status bar menu/buttons:
|
||||
- Explanatory hover text over buttons
|
||||
|
||||
|
@ -29,7 +20,20 @@ Medium Term:
|
|||
- Clipboard button -> popup:
|
||||
- text, clear and send buttons
|
||||
|
||||
- wswrapper:
|
||||
- Flash policy request support.
|
||||
- SSL/TLS support.
|
||||
- Tests suite:
|
||||
- test pselect/poll/ppoll
|
||||
|
||||
Longer Term:
|
||||
Medium Term:
|
||||
|
||||
- VNC performance and regression playback suite.
|
||||
|
||||
- Viewport support
|
||||
|
||||
- Touchscreen testing/support.
|
||||
|
||||
- wswrapper:
|
||||
- epoll_* support
|
||||
|
||||
- Get web-socket-js RFC2817 proxying working again.
|
||||
|
|
37
docs/notes
37
docs/notes
|
@ -4,39 +4,12 @@ There is an included flash object (web-socket-js) that is used to
|
|||
emulate websocket support on browsers without websocket support
|
||||
(currently only Chrome has WebSocket support).
|
||||
|
||||
The performance on Chrome is great. It only takes about 150ms on my
|
||||
system to render a complete 800x600 hextile frame. Most updates are
|
||||
partial or use copyrect which is much faster.
|
||||
|
||||
When using the flash websocket emulator, packets event aren't always
|
||||
delivered in order. This may be a bug in the way I'm using the
|
||||
FABridge interface. Or a bug in FABridge itself, or just a browser
|
||||
event delivery issue. Anyways, to get around this problem, when the
|
||||
flash emulator is being used, the client issues the WebSocket GET
|
||||
request with the "seq_num" variable. This switches on in-band sequence
|
||||
numbering of the packets in the proxy, and the client has a queue of
|
||||
out-of-order packets (20 deep currently) that it uses to re-order.
|
||||
Gross!
|
||||
|
||||
The performance on firefox 3.5 is usable. It takes 2.3 seconds to
|
||||
render a 800x600 hextile frame on my system (the initial connect).
|
||||
Once the initial first update is done though, it's quite usable (as
|
||||
above, most updates are partial or copyrect). I haven't tested firefox
|
||||
3.7 yet, it might be a lot faster.
|
||||
|
||||
Opera sucks big time. The flash websocket emulator fails to deliver as
|
||||
many as 40% of packet events when used on Opera. It may or not be
|
||||
Opera's fault, but something goes badly wrong at the FABridge
|
||||
boundary.
|
||||
|
||||
Javascript doesn't have a bytearray type, so what you get out of
|
||||
a WebSocket object is just Javascript strings. I believe that
|
||||
Javascript has UTF-16 unicode strings and anything sent through the
|
||||
WebSocket gets converted to UTF-8 and vice-versa. So, one additional
|
||||
(and necessary) function of the proxy is base64 encoding/decoding what
|
||||
is sent to/from the browser. Another option that I want to explore is
|
||||
UTF-8 encoding in the proxy.
|
||||
|
||||
a WebSocket object is just Javascript strings. Javascript has UTF-16
|
||||
unicode strings and anything sent through the WebSocket gets converted
|
||||
to UTF-8 and vice-versa. So, one additional (and necessary) function
|
||||
of wsproxy is base64 encoding/decoding what is sent to/from the
|
||||
browser.
|
||||
|
||||
Building web-socket-js emulator:
|
||||
|
||||
|
|
|
@ -1,7 +1,20 @@
|
|||
## wsproxy: WebSockets to TCP Proxy
|
||||
## WebSockets Utilities: wswrapper and wsproxy
|
||||
|
||||
|
||||
### How it works
|
||||
### wswrapper
|
||||
|
||||
wswrapper is an LD_PRELOAD library that converts a TCP listen socket
|
||||
of an existing program to a be a WebSockets socket. The `wswrap`
|
||||
script can be used to easily launch a program using wswrapper. Here is
|
||||
an example of using wswrapper with vncserver. wswrapper will convert
|
||||
the socket listening on port 5901 to be a WebSockets port:
|
||||
|
||||
`cd noVNC/utils`
|
||||
|
||||
`./wswrap 5901 vncserver -geometry 640x480 :1`
|
||||
|
||||
|
||||
### wsproxy
|
||||
|
||||
At the most basic level, wsproxy just translates WebSockets traffic
|
||||
to normal socket traffic. wsproxy accepts the WebSockets handshake,
|
||||
|
@ -15,7 +28,7 @@ case the data from the client is not a full WebSockets frame (i.e.
|
|||
does not end in 255).
|
||||
|
||||
|
||||
### Additional features
|
||||
#### Additional wsproxy features
|
||||
|
||||
These are not necessary for the basic operation.
|
||||
|
||||
|
@ -38,34 +51,38 @@ These are not necessary for the basic operation.
|
|||
option.
|
||||
|
||||
|
||||
### Implementations
|
||||
#### Implementations of wsproxy
|
||||
|
||||
There are three implementations of wsproxy included: python, C, and
|
||||
Node (node.js).
|
||||
There are three implementations of wsproxy: python, C, and Node
|
||||
(node.js). wswrapper is only implemented in C.
|
||||
|
||||
Here is the feature support matrix for the wsproxy implementations:
|
||||
Here is the feature support matrix for the the wsproxy implementations
|
||||
and wswrapper:
|
||||
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Implementation</th>
|
||||
<th>Basic Proxying</th>
|
||||
<th>Application</th>
|
||||
<th>Language</th>
|
||||
<th>Proxy or Interposer</th>
|
||||
<th>Multi-process</th>
|
||||
<th>Daemonizing</th>
|
||||
<th>SSL/wss</th>
|
||||
<th>Flash Policy Server</th>
|
||||
<th>Session Recording</th>
|
||||
</tr> <tr>
|
||||
<td>wsproxy</td>
|
||||
<td>python</td>
|
||||
<td>yes</td>
|
||||
<td>proxy</td>
|
||||
<td>yes</td>
|
||||
<td>yes</td>
|
||||
<td>yes 1</td>
|
||||
<td>yes</td>
|
||||
<td>yes</td>
|
||||
</tr> <tr>
|
||||
<td>wsproxy</td>
|
||||
<td>C</td>
|
||||
<td>yes</td>
|
||||
<td>proxy</td>
|
||||
<td>yes</td>
|
||||
<td>yes</td>
|
||||
<td>yes</td>
|
||||
|
@ -73,14 +90,25 @@ Here is the feature support matrix for the wsproxy implementations:
|
|||
<td>no</td>
|
||||
</tr>
|
||||
</tr> <tr>
|
||||
<td>wsproxy</td>
|
||||
<td>Node (node.js)</td>
|
||||
<td>yes</td>
|
||||
<td>proxy</td>
|
||||
<td>yes</td>
|
||||
<td>no</td>
|
||||
<td>no</td>
|
||||
<td>no</td>
|
||||
<td>no</td>
|
||||
</tr>
|
||||
</tr> <tr>
|
||||
<td>wswrapper</td>
|
||||
<td>C</td>
|
||||
<td>interposer</td>
|
||||
<td>indirectly</td>
|
||||
<td>indirectly</td>
|
||||
<td>no</td>
|
||||
<td>no</td>
|
||||
<td>no</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
* Note 1: to use SSL/wss with python 2.5 or older, see the following
|
||||
|
|
|
@ -13,6 +13,7 @@
|
|||
* - programs using ppoll or epoll will not work correctly
|
||||
*/
|
||||
|
||||
#define DO_MSG 1
|
||||
//#define DO_DEBUG 1
|
||||
//#define DO_TRACE 1
|
||||
|
||||
|
@ -828,6 +829,7 @@ int _WS_poll(int mode, struct pollfd *fds, nfds_t nfds, int timeout,
|
|||
return ret;
|
||||
}
|
||||
|
||||
|
||||
/*
|
||||
* Overload (LD_PRELOAD) standard library network routines
|
||||
*/
|
||||
|
|
|
@ -7,6 +7,14 @@
|
|||
* wswrapper.so.
|
||||
*/
|
||||
|
||||
#ifdef DO_MSG
|
||||
#define MSG(...) \
|
||||
fprintf(stderr, "wswrapper: "); \
|
||||
fprintf(stderr, __VA_ARGS__);
|
||||
#else
|
||||
#define MSG(...)
|
||||
#endif
|
||||
|
||||
#ifdef DO_DEBUG
|
||||
#define DEBUG(...) \
|
||||
if (DO_DEBUG) { \
|
||||
|
@ -27,10 +35,6 @@
|
|||
#define TRACE(...)
|
||||
#endif
|
||||
|
||||
#define MSG(...) \
|
||||
fprintf(stderr, "wswrapper: "); \
|
||||
fprintf(stderr, __VA_ARGS__);
|
||||
|
||||
#define RET_ERROR(eno, ...) \
|
||||
fprintf(stderr, "wswrapper error: "); \
|
||||
fprintf(stderr, __VA_ARGS__); \
|
||||
|
|
Loading…
Reference in New Issue