I'm working on a J2EE Servlet based Socket.IO server implementation. So far I have websocket, flashsocket and xhr-polling working with the chat example. It's demo-ware quality code at the moment. The project is hosted at: http://code.google.com/p/socketio-java/
This implementation uses jetty's Continuation which I know works in jetty 6+ and the latest version of Tomcat 6. The server side API mirrors the jetty WebSocketServlet and WebSocket interface, so this will nearly a drop-in replacement for jetty's WebSocket. I plan to tweek the socket.io.js and server side so that for the case of WebSocket/Flashsocket it will work with non socket.io.js clients. This primarily involves dropping the "~m~" message encoding when using WebSockets because WebSockets already provides a clear message boundary. At the moment there's no build script but I'll be adding an ant based build.xml soon. -Tad On Thu, Sep 30, 2010 at 11:25 AM, Guillermo Rauch <[email protected]> wrote: > I also developed http://socket.io. You can use the client and implement a > backend for it. It leverages websocket, websocket through Flash, long > polling, iframes, multipart ajax, jsonp polling. > > > On Thu, Sep 30, 2010 at 2:26 PM, Tad Glines <[email protected]> wrote: > >> Thanks, that confirms it. If we want wave-in-a-box to work for users >> behind a proxy with browsers that don't support Web Sockets, then an >> alternative to flash is needed. >> >> That leaves, to the best of my knowledge, two options. One, roll our own >> long pooling implementation, or two, make use of the existing message >> routing capabilities of CometD (or some other Comet/Long polling >> implementation). >> >> -Tad >> >> >> On Thu, Sep 30, 2010 at 7:43 AM, Guillermo Rauch <[email protected]>wrote: >> >>> 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]<wave-protocol%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/wave-protocol?hl=en. >>> >> >> -- >> 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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- 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.
