I wrote that part of the README and committed the relevant patch. More information here: http://cometdaily.com/2008/09/30/why-flash-must-adopt-comet/
On Thu, Sep 30, 2010 at 11:31 AM, Tad Glines <[email protected]> wrote: > 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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- Guillermo Rauch http://devthought.com -- 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.
