diff --git a/docs/TODO b/docs/TODO index e8d12005..87f786f5 100644 --- a/docs/TODO +++ b/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. diff --git a/docs/notes b/docs/notes index b41d56dd..b3cc0cfb 100644 --- a/docs/notes +++ b/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: diff --git a/utils/README.md b/utils/README.md index b0ed6018..0e75d51f 100644 --- a/utils/README.md +++ b/utils/README.md @@ -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:
Implementation | -Basic Proxying | +Application | +Language | +Proxy or Interposer | Multi-process | Daemonizing | SSL/wss | Flash Policy Server | Session Recording |
---|---|---|---|---|---|---|---|---|---|
wsproxy | python | -yes | +proxy | yes | yes | yes 1 | yes | yes | |
wsproxy | C | -yes | +proxy | yes | yes | yes | @@ -73,14 +90,25 @@ Here is the feature support matrix for the wsproxy implementations:no | ||
wsproxy | Node (node.js) | -yes | +proxy | yes | no | no | no | no | |
wswrapper | +C | +interposer | +indirectly | +indirectly | +no | +no | +no | +