GWT + comet?
16 views
Skip to first unread message
markww
Sep 6, 2008, 11:50:27 PM9/6/08
to Google Web Toolkit
Hi,
Is there any 'comet' support via GWT at the moment? I'm not completely
up to speed with javascript / browser technologies, I believe comet
was the practice of having the browser keep a connection open to the
server so the server could push data to the browser whenever it
wanted, instead of the client browser always polling for new data.
I'm not sure where GWT would fit into that as it would require some
logic server-side to work. Has there been any development with this,
where can I start?
Thanks
Is there any 'comet' support via GWT at the moment? I'm not completely
up to speed with javascript / browser technologies, I believe comet
was the practice of having the browser keep a connection open to the
server so the server could push data to the browser whenever it
wanted, instead of the client browser always polling for new data.
I'm not sure where GWT would fit into that as it would require some
logic server-side to work. Has there been any development with this,
where can I start?
Thanks
Reinier Zwitserloot
Sep 7, 2008, 6:30:01 AM9/7/08
to Google Web Toolkit
As you said, comet is a complex problem on the server side. On the
client it's relatively straightforward.
Some issues:
1) You either need an async webserver (such as something based on the
fairly new java Simple, or the continuation support available in
jetty), or you need an OS + VM combo which can handle tons of threads
without a high overhead (the latest linux + the latest java 6 seems
capable of this). Be especially careful if you've got a frontloader
(such as Apache) that merely redirects to your actual java stuff.
Apache, out of the box, will probably not use the new worked thread
mechanism to communicate with the java server at the backend, and by
default apache will start serving up 'busy' pages if more than 50
simultaneous connections are already running. You get to 50 very
quickly when using comet. If this is your setup, google around for how
to implement apache+comet+java properly. Personally I just run jetty
only, no apache.
2) The only safe way to do comet is to make a request from the client
to the server, then the server returns NOTHING, not a single byte, it
just waits, and then, once data is available, it sends it, and then
closes the connection. In response, the client should open another
connection and this whole song and dance number is repeated. The
reason you can't just keep sending data across a single HTTP
connection, is because the HTTP standard has no concept of 'flush'. A
proxy or even the webclient itself (IE and Safari both do some limited
caching, for example) will simply assume more will come very shortly,
and never forward the data to the endpoint (your GWT app). In order to
do this concept right, you need some sort of tracking number.
For example, imagine an IRC (chat) client using comet. You could
simply assign to each chat line in the chat room an index number, and
upon first connect, tell the client the last chat line index number
spoken. From here on out, comet can be done by letting the client
request http://www.mychatserver.com/chats/line?idx=" +
lastReceivedChatLineIdx++ - the server, upon receiving such a request,
first checks if a line with that idx has already been said. If so, it
is returned immediately (no comet). if NOT, it will not return an
error, it will instead just wait and hold the connection open. Your
servlet should register a listener of some sort with the central
repository of chat messages, so it can wake up when the line with the
given idx is actually spoken. You can't just ask for 'the next line'
without a tracker ID of some sort, because in between receiving one
line, processing it on the client, and opening another connection, a
line might have been spoken. Without tracking you'd miss this line.
3) Because proxies, webservers, and web clients all have HTTP
timeouts, and they are all different, you should manually close the
connection after ~50 seconds. In our chat example, you'd send back
something like: [NO CHAT] to indicate to the client that in the entire
50 second span, the chat line with idx '1234' never came up so far. In
response, the client should re-open the connection with the exact same
request (gimme line 1234).
4) For efficiency you may want to let the server respond with all
relevant messages that have a tracker ID equal to or larger than the
requested item. For example, in our chat app, if a client asks for
message #1234, but on the server you already know that we're on
message 1237 (a burst of rapid chats just recently happened, for
example), then you should just send 1234, 1235, 1236, and 1237 in one
go. You'll need a way to delimit each 'packet' of information in the
response in this case. You could use JSON, for example. Or use a GWT-
RPC call, though I don't know the specifics of making that work right
with comet.
5) Web clients internally have a 2 connections limit. This means that,
for any given full server name, if there are already 2 open
connections, and a third thing is requested from this server, the
client will queue up this request instead of sending it. Once one of
those 2 open connections is closed, it will send it. This is perfectly
reasonable when all requests are handled as fast as possible, but in
comet, the whole point is that requests are NOT handled as fast as
possible. If you have multiple comet elements on a single web page
(Let's say, a 'live' stock ticker AND a chat box, each running a
separate comet connection), then you're out of connections, and the
act of requesting a simple image in response to a mouse over or some
such never goes through!
There are two solutions to this:
A) run your non-AJAX calls off a different server. For example, serve
up images from img.yourhost.com instead of just yourhost.com. You
can't do this for your comet connections, because those usually use
AJAX calls, and those must go to the same domain as the web page (Same
Origin Policy, wikipedia that if you don't know what that is). This
won't help you if you have 3 separate comety things going on, and it
won't help you if you have 2 comety things going on and a third thing
needs to do a non-comet AJAX call (say, a standard GWT-RPC call). Then
you need to go for the more complex option:
B) multiplex all comety stuff over a single connection. In other
words, in one URL, you ask for EITHER the next stock ticker update OR
the next chat line, and the server will respond with an indicator
about what it's responding with, along with the content. In response
your client should update the right widget, increase its index
counter, and open another request of the same type (e.g. first you
asked for http://myserver.com/comet/multiplex?ticker=1234&chat=5678),
and your server responds with ([ticker:1234]AAPL: 170.12), then you
should update the stock widget and right after that, start a request
for http://myserver.com/comet/multiplex?ticker=1235&chat=5678). If you
google around, 'cometd' is a system that has a framework for this
multiplex stuff. I don't usually recommend cometd because for the
majority of comet applications, you don't need to multiplex anything.
client it's relatively straightforward.
Some issues:
1) You either need an async webserver (such as something based on the
fairly new java Simple, or the continuation support available in
jetty), or you need an OS + VM combo which can handle tons of threads
without a high overhead (the latest linux + the latest java 6 seems
capable of this). Be especially careful if you've got a frontloader
(such as Apache) that merely redirects to your actual java stuff.
Apache, out of the box, will probably not use the new worked thread
mechanism to communicate with the java server at the backend, and by
default apache will start serving up 'busy' pages if more than 50
simultaneous connections are already running. You get to 50 very
quickly when using comet. If this is your setup, google around for how
to implement apache+comet+java properly. Personally I just run jetty
only, no apache.
2) The only safe way to do comet is to make a request from the client
to the server, then the server returns NOTHING, not a single byte, it
just waits, and then, once data is available, it sends it, and then
closes the connection. In response, the client should open another
connection and this whole song and dance number is repeated. The
reason you can't just keep sending data across a single HTTP
connection, is because the HTTP standard has no concept of 'flush'. A
proxy or even the webclient itself (IE and Safari both do some limited
caching, for example) will simply assume more will come very shortly,
and never forward the data to the endpoint (your GWT app). In order to
do this concept right, you need some sort of tracking number.
For example, imagine an IRC (chat) client using comet. You could
simply assign to each chat line in the chat room an index number, and
upon first connect, tell the client the last chat line index number
spoken. From here on out, comet can be done by letting the client
request http://www.mychatserver.com/chats/line?idx=" +
lastReceivedChatLineIdx++ - the server, upon receiving such a request,
first checks if a line with that idx has already been said. If so, it
is returned immediately (no comet). if NOT, it will not return an
error, it will instead just wait and hold the connection open. Your
servlet should register a listener of some sort with the central
repository of chat messages, so it can wake up when the line with the
given idx is actually spoken. You can't just ask for 'the next line'
without a tracker ID of some sort, because in between receiving one
line, processing it on the client, and opening another connection, a
line might have been spoken. Without tracking you'd miss this line.
3) Because proxies, webservers, and web clients all have HTTP
timeouts, and they are all different, you should manually close the
connection after ~50 seconds. In our chat example, you'd send back
something like: [NO CHAT] to indicate to the client that in the entire
50 second span, the chat line with idx '1234' never came up so far. In
response, the client should re-open the connection with the exact same
request (gimme line 1234).
4) For efficiency you may want to let the server respond with all
relevant messages that have a tracker ID equal to or larger than the
requested item. For example, in our chat app, if a client asks for
message #1234, but on the server you already know that we're on
message 1237 (a burst of rapid chats just recently happened, for
example), then you should just send 1234, 1235, 1236, and 1237 in one
go. You'll need a way to delimit each 'packet' of information in the
response in this case. You could use JSON, for example. Or use a GWT-
RPC call, though I don't know the specifics of making that work right
with comet.
5) Web clients internally have a 2 connections limit. This means that,
for any given full server name, if there are already 2 open
connections, and a third thing is requested from this server, the
client will queue up this request instead of sending it. Once one of
those 2 open connections is closed, it will send it. This is perfectly
reasonable when all requests are handled as fast as possible, but in
comet, the whole point is that requests are NOT handled as fast as
possible. If you have multiple comet elements on a single web page
(Let's say, a 'live' stock ticker AND a chat box, each running a
separate comet connection), then you're out of connections, and the
act of requesting a simple image in response to a mouse over or some
such never goes through!
There are two solutions to this:
A) run your non-AJAX calls off a different server. For example, serve
up images from img.yourhost.com instead of just yourhost.com. You
can't do this for your comet connections, because those usually use
AJAX calls, and those must go to the same domain as the web page (Same
Origin Policy, wikipedia that if you don't know what that is). This
won't help you if you have 3 separate comety things going on, and it
won't help you if you have 2 comety things going on and a third thing
needs to do a non-comet AJAX call (say, a standard GWT-RPC call). Then
you need to go for the more complex option:
B) multiplex all comety stuff over a single connection. In other
words, in one URL, you ask for EITHER the next stock ticker update OR
the next chat line, and the server will respond with an indicator
about what it's responding with, along with the content. In response
your client should update the right widget, increase its index
counter, and open another request of the same type (e.g. first you
asked for http://myserver.com/comet/multiplex?ticker=1234&chat=5678),
and your server responds with ([ticker:1234]AAPL: 170.12), then you
should update the stock widget and right after that, start a request
for http://myserver.com/comet/multiplex?ticker=1235&chat=5678). If you
google around, 'cometd' is a system that has a framework for this
multiplex stuff. I don't usually recommend cometd because for the
majority of comet applications, you don't need to multiplex anything.
markww
Sep 7, 2008, 3:41:37 PM9/7/08
to Google Web Toolkit
Thanks for the excellent response, that was very helpful. Everything
makes sense, I was taking a look at Jetty and it seems easy to use for
what I want to do. I had been writing my own java nio server for a
class I was taking, it's cool to see how Jetty has taken advantage of
the nio stuff to support 'comet'.
From a game development point of view, this is great because we can
wait for the server to send us data instead of constantly polling it.
One thing that still seems to be missing is fast graphics support, to
actually render dynamic game data. I was working with the gwt canvas
intensively a few months ago, but was disappointed to find out that
IE's support for it was just horrible. Firefox and Safari (and
probably Chrome now) can do a decent job of rendering simple
primitives fast in a <canvas>. In fact, my iPhone could render
primitives faster than IE! I wonder if there is any development on
this (providing a fast canvas for direct pixel manipulation) by the
browsers. Right now it seems like the only way to do it is by using
Flash.
Anyway thanks again for all those answers, definitely got me in the
right direction,
Mark
> requesthttp://www.mychatserver.com/chats/line?idx=" +
> asked forhttp://myserver.com/comet/multiplex?ticker=1234&chat=5678),
makes sense, I was taking a look at Jetty and it seems easy to use for
what I want to do. I had been writing my own java nio server for a
class I was taking, it's cool to see how Jetty has taken advantage of
the nio stuff to support 'comet'.
From a game development point of view, this is great because we can
wait for the server to send us data instead of constantly polling it.
One thing that still seems to be missing is fast graphics support, to
actually render dynamic game data. I was working with the gwt canvas
intensively a few months ago, but was disappointed to find out that
IE's support for it was just horrible. Firefox and Safari (and
probably Chrome now) can do a decent job of rendering simple
primitives fast in a <canvas>. In fact, my iPhone could render
primitives faster than IE! I wonder if there is any development on
this (providing a fast canvas for direct pixel manipulation) by the
browsers. Right now it seems like the only way to do it is by using
Flash.
Anyway thanks again for all those answers, definitely got me in the
right direction,
Mark
> and your server responds with ([ticker:1234]AAPL: 170.12), then you
> should update the stock widget and right after that, start a request
> forhttp://myserver.com/comet/multiplex?ticker=1235&chat=5678). If you
> should update the stock widget and right after that, start a request
Reinier Zwitserloot
Sep 7, 2008, 5:29:14 PM9/7/08
to Google Web Toolkit
Glad you liked the missive. I've saved a bookmark for future reference
in case someone else comes in and asks (Comet usually comes up once a
month or so).
For game development: Just screw IE. There's no way to do halfway
decent graphics on IE, period. Go flash, or tell people to switch to
firefox/opera/safari/comet.
All 3 non-IE browsers are trying to speed up javascript. Opera 9.5 has
a fairly spiffy javascript engine already, and both firefox and webkit
are on the verge of shipping custom very smart and very fast VMs for
javascript (tracemonkey for firefox, and squirrelfish for safari).
Then there's V8, which you can see at work today in Google Chrome. It
looks like V8, Tracemonkey, and squirrelfish will all be roughly as
fast as one another (can you say meep meep?) - should do wonders for
attempts to write games in canvas.
Which brings us back to IE. F!*k IE.
There's future hope though:
I believe apple has rescinded copyright/patent claims on canvas, or
they ran out, so in theory nothing is stopping IE from implementing
them now - though as I understand it, Microsoft never expressed
interest in supporting them.
Microsoft is part of the W3C and evidently they have not been able to
use their considerable weight there to stop the latest news at W3C.
W3C's own home-grown XHTML 2.0 effort has effectively been mothballed
indefinitely, and instead HTML5 has been adopted (HTML5 started as
something from the WHAT-WG, which is a much less officious entity
compared to W3C, and consists of the developers of Opera, WebKit
(Safari), and Gecko (Firefox/mozilla). - e.g. the anti-IE league, and
the main reason stuff like canvas has seeded so quickly to the other
non-IE browsers) HTML5 has been dollied up with some lip service to
XHTML but make no mistake: Few really expected the W3C to 'fold' to
the clearly superior HTML5 work in progress. HTML5 includes Canvas
(see http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html
for proof). The question now becomes: Does Microsoft break even more
from the W3C than they already have (remember, IE isn't exactly
standards compliant). So far betas of IE8 indicate that Microsoft is
seriously attempting to build a more compatible browser, so there's
hope. Then again, armchair analysts (like myself ㋛) believe that
Microsoft is still trying to prevent the web from becoming the host of
virtually every computer app out there, in order to keep their own OS
(Windows) in a safe market leader position. Microsoft's stranglehold
on the web community by way of IE is one of the things holding web
apps back, so there are plenty of pessimists who believe that the
final version of IE8 will be a big disappointment.
in case someone else comes in and asks (Comet usually comes up once a
month or so).
For game development: Just screw IE. There's no way to do halfway
decent graphics on IE, period. Go flash, or tell people to switch to
firefox/opera/safari/comet.
All 3 non-IE browsers are trying to speed up javascript. Opera 9.5 has
a fairly spiffy javascript engine already, and both firefox and webkit
are on the verge of shipping custom very smart and very fast VMs for
javascript (tracemonkey for firefox, and squirrelfish for safari).
Then there's V8, which you can see at work today in Google Chrome. It
looks like V8, Tracemonkey, and squirrelfish will all be roughly as
fast as one another (can you say meep meep?) - should do wonders for
attempts to write games in canvas.
Which brings us back to IE. F!*k IE.
There's future hope though:
I believe apple has rescinded copyright/patent claims on canvas, or
they ran out, so in theory nothing is stopping IE from implementing
them now - though as I understand it, Microsoft never expressed
interest in supporting them.
Microsoft is part of the W3C and evidently they have not been able to
use their considerable weight there to stop the latest news at W3C.
W3C's own home-grown XHTML 2.0 effort has effectively been mothballed
indefinitely, and instead HTML5 has been adopted (HTML5 started as
something from the WHAT-WG, which is a much less officious entity
compared to W3C, and consists of the developers of Opera, WebKit
(Safari), and Gecko (Firefox/mozilla). - e.g. the anti-IE league, and
the main reason stuff like canvas has seeded so quickly to the other
non-IE browsers) HTML5 has been dollied up with some lip service to
XHTML but make no mistake: Few really expected the W3C to 'fold' to
the clearly superior HTML5 work in progress. HTML5 includes Canvas
(see http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html
for proof). The question now becomes: Does Microsoft break even more
from the W3C than they already have (remember, IE isn't exactly
standards compliant). So far betas of IE8 indicate that Microsoft is
seriously attempting to build a more compatible browser, so there's
hope. Then again, armchair analysts (like myself ㋛) believe that
Microsoft is still trying to prevent the web from becoming the host of
virtually every computer app out there, in order to keep their own OS
(Windows) in a safe market leader position. Microsoft's stranglehold
on the web community by way of IE is one of the things holding web
apps back, so there are plenty of pessimists who believe that the
final version of IE8 will be a big disappointment.
Thomas Broyer
Sep 8, 2008, 6:23:01 AM9/8/08
to Google Web Toolkit
http://code.google.com/p/google-web-toolkit-incubator/wiki/ServerPushFAQ
http://code.google.com/p/rocket-gwt/wiki/Comet
markww
Sep 8, 2008, 1:49:15 PM9/8/08
to Google Web Toolkit
Ok so after doing some reading it seems there are quite a few viable
options on how to get started with comet. I can choose any setup I
want for the backend, right now I'm leaning towards Jetty but it's
hard to decide. There seem to be articles dating from 2007 / GWT 1.4
which give conflicting reports on the state of support Jetty and
Tomcat offer:
Go with Jetty:
-easy to setup and supports continuations
-should I go with version 6, or version 7 though? Version 6
seems to use continuations
which are a way of imitating comet (bad explanation) but as I
understand it, version 7
will have a new 'real' continuation system for 'servlet 3'? So
which to choose?
-can you debug your webapp using Jetty as the server, I thought
GWT uses Tomcat
by default?
-need a GWT hack to get it to work: http://docs.codehaus.org/display/JETTY/GWT
because GWT marked some class methods final which Jetty can't
work with (v6)
for RPC, don't know if that's different with v7.
Go with Tomcat:
-GWT uses this as the server for debugging? that's a plus.
-Seems more difficult to configure to work with comet than
Jetty, though most
of the articles I find on this date to pre GWT 1.5 in 2007, not
sure what the
current state of support is.
In terms of the GWT side of things, it seems like the chat example
here:
http://groups.google.com/group/gwtapps/files
is a good one to use as a comet example. Though it is GWT 1.4, I don't
know how much needs to be ported.
Thanks for any comments,
Mark
options on how to get started with comet. I can choose any setup I
want for the backend, right now I'm leaning towards Jetty but it's
hard to decide. There seem to be articles dating from 2007 / GWT 1.4
which give conflicting reports on the state of support Jetty and
Tomcat offer:
Go with Jetty:
-easy to setup and supports continuations
-should I go with version 6, or version 7 though? Version 6
seems to use continuations
which are a way of imitating comet (bad explanation) but as I
understand it, version 7
will have a new 'real' continuation system for 'servlet 3'? So
which to choose?
-can you debug your webapp using Jetty as the server, I thought
GWT uses Tomcat
by default?
-need a GWT hack to get it to work: http://docs.codehaus.org/display/JETTY/GWT
because GWT marked some class methods final which Jetty can't
work with (v6)
for RPC, don't know if that's different with v7.
Go with Tomcat:
-GWT uses this as the server for debugging? that's a plus.
-Seems more difficult to configure to work with comet than
Jetty, though most
of the articles I find on this date to pre GWT 1.5 in 2007, not
sure what the
current state of support is.
In terms of the GWT side of things, it seems like the chat example
here:
http://groups.google.com/group/gwtapps/files
is a good one to use as a comet example. Though it is GWT 1.4, I don't
know how much needs to be ported.
Thanks for any comments,
Mark
Thomas Broyer
Sep 8, 2008, 4:14:36 PM9/8/08
to Google Web Toolkit
On Sep 8, 7:49 pm, markww <mar...@gmail.com> wrote:
>
> -can you debug your webapp using Jetty as the server, I thought
> GWT uses Tomcat
> by default?
whatever server software you want. You just lose the ability to debug
both your client and server code at the same time (i.e. in one click;
I suppose you can debug more than one app at the same time within e.g.
Eclipse)
richard...@gmail.com
Sep 30, 2008, 12:10:20 AM9/30/08
to Google Web Toolkit
I hate to say it but you've got me wondering now. I mean, it would be
a whole lot easier to do considering you can see the source code of
your competitor a lot easier these days...
> (seehttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-canva...
> ...
>
> read more »
a whole lot easier to do considering you can see the source code of
your competitor a lot easier these days...
> for proof). The question now becomes: Does Microsoft break even more
> from the W3C than they already have (remember, IE isn't exactly
> standards compliant). So far betas ofIE8indicate that Microsoft is
> from the W3C than they already have (remember, IE isn't exactly
> seriously attempting to build a more compatible browser, so there's
> hope. Then again, armchair analysts (like myself ㋛) believe that
> Microsoft is still trying to prevent the web from becoming the host of
> virtually every computer app out there, in order to keep their own OS
> (Windows) in a safe market leader position. Microsoft's stranglehold
> on the web community by way of IE is one of the things holding web
> apps back, so there are plenty of pessimists who believe that the
> final version ofIE8will be a big disappointment.
> hope. Then again, armchair analysts (like myself ㋛) believe that
> Microsoft is still trying to prevent the web from becoming the host of
> virtually every computer app out there, in order to keep their own OS
> (Windows) in a safe market leader position. Microsoft's stranglehold
> on the web community by way of IE is one of the things holding web
> apps back, so there are plenty of pessimists who believe that the
>
> read more »
Reply all
Reply to author
Forward
0 new messages