Tad, First of all, amazing work.
I discourage against removing the framing, even for persistent-connection transports. The framing is useful if you want to alter the closeTimeout of websocket and buffer between disconnections. With the current socket.io, it's fairly trivial to save the session id in a cookie or local storage, set the closeTimeout to something like 10 seconds, and then you can buffer messages for user between browser refreshes. Its also useful to buffer if the connection is spotty. I think it provides great flexibility at a very small (or inexistent) price. On Wed, Oct 20, 2010 at 9:35 PM, Tad Glines <[email protected]> wrote: > 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]<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.
