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. 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
