search

gimite / web-socket-js

HTML5 Web Socket implementation powered by Flash
BSD 3-Clause "New" or "Revised" License
2.73k stars 489 forks source link

Potential changes. #56

Closed wtritch closed 13 years ago

wtritch commented 13 years ago

Hello all, This is my first post on this project, and I couldn't find a board or message list, so please forgive my posting as an issue. My company is currently working on a websocket implementation and we were hoping to use web-socket-js as a fallback for browsers and/or security situations that won't allow true websockets. After reading up, testing, and scanning the source a bit I had a couple of changes I'd like to make and was wondering if anyone else has tried anything similar, or if it would be useful to post the changes once I've completed them:

  1. I'd like to replace the Vector instances with Arrays in Base64.as They aren't as fast or low-memory-footprint as primitive Vectors, but since the flash component is using Flex 3.0/3.5, it'd be nice to be able to support Flash Player 9 and those two Vector instances are the only stumbling block.
  2. I'd like to remove the dependency on FABridge and have a single flash controller responsible for managing multiple WebSocket instances rather than have javascript maintain flash instances. (This should fix that memory leak further down.)

Any feedback would be appreciated.

wtritch commented 13 years ago

One other note. In our tests it appeared that true WebSockets sat on messages that arrived while javascript was suspended/overloaded, (e.g. execution paused for debugging.) The WebSocket then processed the messages that had been queueing up once browser execution resumed. Since the flash plugin is running on a separate thread from the javascript, the flash component is dropping messages that are received while javascript is unavailable. I haven't tested this thoroughly, but I'd assume that the same problem happens during any heavy load that keeps javascript from responding (e.g. a long synchronous ajax call, burst processing, etc.) I'm going to be adding in a local message queue inside the flash component that will keep messages from being lost while javascript is unresponsive.

TooTallNate commented 13 years ago

+1 for removing FABridge. That lib sucks.

This all sounds like good stuff. Are you preparing a pull request?

wtritch commented 13 years ago

I just forked, and I'll send out a pull request once I have the changes working =)

gimite commented 13 years ago

I'd like to replace the Vector instances with Arrays in Base64.as They aren't as fast or low-memory-footprint as primitive Vectors, but since the flash component is using Flex 3.0/3.5, it'd be nice to be able to support Flash Player 9 and those two Vector instances are the only stumbling block.

It's part of external library, so I don't want to keep its fork. Please send the patch to the original library.

I'd like to remove the dependency on FABridge and have a single flash controller responsible for managing multiple WebSocket instances rather than have javascript maintain flash instances. (This should fix that memory leak further down.)

I may pull such change if it doesn't add much complication.

gimite commented 13 years ago

I'm going to be adding in a local message queue inside the flash component that will keep messages from being lost while javascript is unresponsive.

Have you checked latest version of web-socket-js? It does something similar to your suggestion.