The Flash based Web Socket implementation may not work behind a proxy
without some extra rigmarole. Here's the relevant text from the
web-socket-js README file:

The AS3 Socket class doesn't implement this mechanism, which renders
it useless for the scenarios where
the user trying to open a socket is behind a proxy.

The class RFC2817Socket (by Christian Cantrell) effectively lets us
implement this, as long as the
proxy settings are known and provided by the interface that
instantiates the WebSocket. As such, if you
want to support proxied conncetions, you'll have to supply this
information to the WebSocket
constructor when Flash is being used. One way to go about it would be
to ask the user for proxy
settings information if the initial connection fails.

This was surprising. I had always assumed that Flash would obtain the proxy
info from the host browser and use it when connecting back to the server. I
haven't tested this yet so I can't be certain if this is a real issue. If it
is, then prompting the user for proxy information is not, in my opinion, a
valid solution.

We also know that Web Sockets (native or flash) don't work on iOS based
devices.

I recently did some work using CometD and I noticed that, besides long
pooling, it also supports Web Sockets as one of its transports. And, it also
seems to have automatic fallback support. Perhaps using CometD would be a
better alternative to the Flash based Web Sockets. There is also a CometD
java client library so the console client could also interface with the
server via CometD over Web sockets.

The one downside I see is that the Bayuex protocol adds some additional
overhead (channel ID, message ID, timestamp, etc...). We could implement our
own long polling based alternative to Web Sockets, but why re-invent the
wheel.

Also, it's possible to combine the Flash based Web Sockets impl with CometD
since CometD will fall back to long polling if it fails to establish a
connection using Web Sockets.

-Tad

-- 
You received this message because you are subscribed to the Google Groups "Wave 
Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/wave-protocol?hl=en.

Reply via email to