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.
