On Thu, Apr 2, 2009 at 6:13 AM, ryandscott <[email protected]> wrote: > > I'm wondering what the best way to implement a chat system would be. > Currently, I have a javascript timer that goes off every x seconds to > query the database and return the list of chats. I keep my list to a > certain number of chats, but it seems that the way I'm doing the whole > process is a fairly poor design.
Given the natural limitations of the HTTP protocol, I don't think you can do it much more better than this. HTTP is based on request/response paradigm and thus, the only way to simulate server-initiated updates is to do polling using any of the available options (timed requests/ajax/comet/fancynamehere, etc.) You must also add to the limitations of the HTTP protocol the restrictions of the GAE environment (maximum number of simultaneous requests, maximum amount of time allowed to serve a request, etc.), and this will narrow your available options to -probably- just one: periodic polling to some URLs from the client in order to emulate/simulate server updates. Take care about this, since this option, depending on your application and update intervals, may exhaust your free quotas or your bugdget very quickly. For example, supose you have 40 chat rooms per day with 40 users each one, with a lifespan of 2 hours per chat, with clients polling for updates each 5 seconds (that is, 12 status update requests per minute, just to make the whole thing look like "real time"), this sill result in: 40chats x 40uses x 120min x 12 reqs/min = 2304000 requests Assuming 200ms-cpu per request (process request, lookup memcache/datastore, write request, etc.), this yields: 2304000 requests * 200ms-cpu/requests = 460800000 ms-cpu = 128hours cpu (If you think 40 chats / 40 users is too much, just make those numbers smaller and increase the reqs/second from 12 to 24/60, since an update each 5 seconds could probably result in jumpy updates. Also, the 200ms/request figure is estimated, but I doubt you can lower it more, since you *must* do something with memcache/datastore in the server, in order to compute and send updates) Right now it's very hard to interpret how to compute exact costs since there are many different figures to look at: cpu time, datastore cpu time, billable/not billable, current free limits / future free limits, etc., but "128 cpu hours" falls beyond any of the figures in that page, so this means that either your app will stop working after some activity (if you don't have billing enabled) or that you are going to pay *a lot* due to polling and the fact that it incurs in CPU usage (128 cpu-hours/day, woud represent 12.8$/day and aprox 384$/month, which means you'll probably must start writing a business plan :-) ) Besides that, there's some movement right now around HTML 5 and the idea of "WebSockets", which specifications are on track to be standardized (I don't know exactly at which point they are), but I would'nt bet for it to be included in short time in GAE (maybe some response from any of the Google team members here could be great). Also, there's something related to XMPP/GAE integration on the roadmap, in order to make GAE applications able to send/receive XMPP messages, but I believe that (a) this would imply that your chat's users must be registered/authenticated agains an XMPP server and that (b) you would need a third element -an XMPP server- to appear into action... well, none ot these scenarios look very promising right now (without the cited business plan, of course :-) ) Hope that helps. Best, Jose --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" 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-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
