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...
On Sep 7, 5:29 pm, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > 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 > (seehttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-canva... > 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 > 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. > > On Sep 7, 9:41 pm, markww <[EMAIL PROTECTED]> wrote: > > > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
