Fixes:
- Make sure that failed state messages stay around until next connect.
- Get status message font colors working.
- Clear RQ_reorder list on re-connect.
Instead of selecting on everything every time, only select the writers
that we have items queued for. Most of the time the writers are ready
so if we select on them even when we don't have anything to send we
will fall into a tight loop.
On the client side, this adds the as3crypto library to web-socket-js
so that the WebSocket 'wss://' scheme is supported which is WebSocket
over SSL/TLS.
Couple of downsides to the fall-back method:
- This balloons the size of the web-socket-js object from about 12K to 172K.
- Getting it working required disabling RFC2718 web proxy support
in web-socket-js.
- It makes the web-socket-js fallback even slower with the
encryption overhead.
The server side (wsproxy.py) uses python SSL support. The proxy
automatically detects the type of incoming connection whether flash
policy request, SSL/TLS handshake ('wss://') or plain socket
('ws://').
Also added a check-box to the web page to enable/disabled 'wss://'
encryption.
Query string variable 'b64encode' determine if wsproxy b64 encodes the
results. Variable 'seq_num' determines if sequence numbers are
prepended. This way, sequence numbers are only used with the flash
WebSocket proxy.
- web-socket-js is from http://github.com/gimite/web-socket-js. It is
a flash object that emultates WebSockets.
Unfortunately, events (or packets) from the web-socket-js object can
get re-ordered so we need to know the packet order.
- So wsproxy.py prepends the sequence number of the packet when
sending.
- If the client receives packets out of order it queues them up and
scans the queue for the sequence number it's looking for until
things are back on track. Gross, but hey: It works!
- Also, add packet sequence checking to wstest.*
Joel Martin
Kevin Chan