utils/README.md, docs/TODO, docs/notes: updates.

Add wswrapper info to utils/README.md and docs/TODO. Remove innacurate
info from docs/notes.
This commit is contained in:
Joel Martin 2010-12-30 11:00:50 -07:00
parent b9f2b4ae01
commit 94b94b1029
3 changed files with 45 additions and 53 deletions

View File

@ -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.

View File

@ -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:

View File

@ -53,32 +53,36 @@ These are not necessary for the basic operation.
#### 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>
@ -86,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