Here's the link to the wiki page I've started: http://code.google.com/p/socketio-java/wiki/Protocol It's a bit sparse at the moment.
-Tad On Mon, Oct 25, 2010 at 8:39 PM, Tad Glines <[email protected]> wrote: > Because I anticipate multiple changes and because it deals with multiple > files, I've created a clone and pushed the changes there. > http://code.google.com/r/tadglines-socketio/ > > I've also included a fix for the reconnect issue I mentioned in my last > e-mail on this thread. > > -Tad > > > On Mon, Oct 25, 2010 at 5:06 PM, Tad Glines <[email protected]> wrote: > >> I was planning on documenting (in the socketio-java wiki) the "protocols" >> supported. The idea is to have a client/server interaction design that its >> independent of the implementations. >> I can start by describing the message encoding. >> >> I also plan to write a HowTo describing how to use the server API and GWT >> client API, but both are in flux at the moment so I'm holding off until I'm >> a little happier with both. >> >> I submitted the patch early in the hope that people would try it and >> report any problems they encounter. I've already identified one problem. If >> a connection attempt fails, nothing gets reported from Socket.IO so the >> client doesn't know it needs to try again (state gets stuck in CONNECTING). >> I'm working on a fix for that (and altering the API slightly). >> >> -Tad >> >> >> On Mon, Oct 25, 2010 at 4:44 PM, Alex North <[email protected]> wrote: >> >>> Hi Tad, >>> >>> Would you be willing to write up a quick design document describing, for >>> example, the different message encoding etc? >>> >>> On 24 October 2010 16:19, Tad Glines <[email protected]> wrote: >>> >>>> All the transports are implemented and I've tested all but htmlfile in >>>> Firefox and Chrome 6. I'm not sure which browser uses htmlfile but if >>>> someone can tell me, I'll try and test that one as well. >>>> >>>> Testing at this point consisted of using the chat example and making >>>> sure messages went both ways. >>>> >>>> This server will not work with existing versions of Socket.IO because I >>>> changed the message encoding format in order to support a few extra message >>>> types. >>>> >>>> >>>> The socketio-java project is hosted at: >>>> http://code.google.com/p/socketio-java/ >>>> My fork of the Socket.IO project is at: >>>> http://github.com/tadglines/Socket.IO >>>> >>>> My next step is to integrate this into WaiB and see if it still works. >>>> The underlying message encoding is different from raw websocket messages so >>>> I plan to implement a java client that the consoleclient can use. It'll use >>>> the websocket transport and deal with the Socket.IO message encoding. >>>> >>>> The code is still demo quality (lack of comments, possible race >>>> conditions/threading issues). I welcome any input at this time. >>>> >>>> -Tad >>>> >>>> >>>> On Thu, Oct 21, 2010 at 2:57 PM, Joseph Gentle <[email protected]>wrote: >>>> >>>>> Awesome. >>>>> >>>>> Well, when you're happy enough with it, request a codereview and lets >>>>> workshop it. >>>>> >>>>> -J >>>>> >>>>> On Thu, Oct 21, 2010 at 11:28 PM, Tad Glines <[email protected]> >>>>> wrote: >>>>> > I'm fairly certain I can have it working well enough and integrated >>>>> into >>>>> > WiaB be the summit, but the code will probably still be demo-ware >>>>> quality. >>>>> > >>>>> > -Tad >>>>> > >>>>> > On Wed, Oct 20, 2010 at 10:01 PM, Joseph Gentle <[email protected]> >>>>> wrote: >>>>> >> >>>>> >> Awesome work guys. Really looking forward to it all being integrated >>>>> >> in wave in a box. >>>>> >> >>>>> >> Do you think we'll have other browser support before the summit? >>>>> >> >>>>> >> -J >>>>> >> >>>>> >> >>>>> >> On Fri, Oct 1, 2010 at 5: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. >>>>> >> >>>>> > >>>>> > -- >>>>> > 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. >>>>> >>>>> >>>> -- >>>> 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. >>> >> >> > -- 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.
