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 On Sep 7, 6:30 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > 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 > requesthttp://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 forhttp://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 > forhttp://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. > > On Sep 7, 5:50 am, markww <[EMAIL PROTECTED]> wrote: > > > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
