Just one minor comment; in:
http://code.google.com/p/socketio-java/source/browse/src/com/glines/socketio/server/transport/FlashSocketTransport.java
Start flash policy server isn't going to overcome the issue with the
default policy port being 843, and thus < 1024 requiring root to bind
that port (handily ignored by:
if (flashPolicyServerHost != null && flashPolicyDomain != null &&
flashPolicyPorts != null) { try { startFlashPolicyServer(); } catch
(IOException e) { /* Ignore */ } }
Not that much of an issue since I guess you just fail over to another
method, but it does mean flash basically just won't get used as a
transport in the majority of cases; I never followed up doing that as
part of the websocket stuff I did because I don't think it's really
the right answer.
Really the solution is for the server to respond to an auth XML
request on the websocket port, but that requires the websocket
listener on the server side to handle a special xml auth request code
as a special case, which is annoying. Had any thoughts on that front?
~
Doug.
On Oct 27, 5:27 am, Tad Glines <[email protected]> wrote:
> There are two parts to this effort. The bulk of the code for socket.io is
> not in WiaB, it's in two separate projects (a fork of Socket.IO and the
> socketio-java project I created).
>
> The code changes in WiaB are minimal. The code in socketio-java is all new
> and no one has reviewed it.
>
> The wave-protocol clone (http://code.google.com/r/tadglines-socketio/)
> contains all the WiaB changes needed (so far) to work with the current dev
> version of socketio-java. So you can just pull it and test it if you want.
> It's not final yet because the socketi-java interface is in flux. I hope to
> have it nailed down in the next day or so.
>
> What would be great is if other people tested what's currently in
> (http://code.google.com/r/tadglines-socketio/) and looked at that code.
>
> Perhaps what we need to do is figure out how to support both the existing
> WebSockets and the new Socket.IO communication with some way for people to
> switch between one and the other. That way there would not be as much risk
> of integrating the Socket.IO stuff.
>
> -Tad
>
> On Tue, Oct 26, 2010 at 1:48 PM, Joseph Gentle <[email protected]> wrote:
> > Cool. Is the change ready for us to take a look at it? (I can throw up
> > a code review if it is).
>
> > -J
>
> > On Tue, Oct 26, 2010 at 2: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 developedhttp://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
>
> ...
>
> read more »
--
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.
