Well, I wrote my own NIO application server, so yes on both accounts! Polling is not an option, I need to support thousands of concurrent clients per hardware.
http://rupy.googlecode.com /m On Thu, 22 Apr 2010, Tal Liron wrote: > It's hard for me to see Comet as RESTful. I would consider it a new > use of HTTP that demands a new way of thinking. You'd probably want to > use a lower level API than Restlet, so you can fully leverage > asynchronicity. > > Have you considered repeat rapid polling instead of using Comet? > > On 04/21/2010 05:12 PM, Marc Larue wrote: > > Ok, I realize you are all talking mostly from a B2B perspective. I'm > > developing a realtime comet system for multiplayer games (Ajax, JSON, > > Rupy); so my perspective is a little different. > > > > Right now I'm trying to figure out how to make my XSS messaging system as > > cheaply scalable as possible; specifically how to transfer users from the > > lobby to a game room on another server and how to build a generic protocol > > for this. > > > > Comet is hard to build without session state since you communicate on two > > sockets with every client and in my case the session is used to tie these > > together. > > > > Anyhow I have a stateful client, now I just need to figure out the best > > way to synchronize clients and I think you are right; CPU goes before > > bandwidth in my case too. > > > > Maybe a "fullstate" monopacket protocol? > > > > Cheers, > > > > /marc > > > > On Wed, 21 Apr 2010, Tal Liron wrote: > > > >> REST services are only as chatty as however you define your resources. > >> > >> I've seen many REST architectures suffering from a failure of imagination: > >> the architects assume that "resource" has to have a one-to-one mapping with > >> "database row" or other concrete entity, when in fact there is not such > >> requirement. Resources should be use-specific, logical to the application, > >> not to its underlying implenetation. It's possible to devise resources that > >> are logical associations of various complex business logic, and do as much > >> as you do with a SOAP request. > >> > >> Also, I don't think REST has to be stateless. HTTP headers are used > >> specifically for passing state, and cookies are full-blown shared state. > >> > >> Why not implement sessions via cookies? Of course, there are potential > >> scalability issues with shared state and sessions, but these are general > >> problems and not specifically addressed by REST. > >> > >> My advice: > >> > >> 1) Use cookies, they are good, but -- > >> 2) Don't maintain heavy, persistent sessions on the server. Create a > >> lightweight scheme that lets you quickly do a secure operation per user. > >> 3) Think very careful about what you consider a "resource", and try to > >> bunch > >> as much functionality as you can into one request. This will also help you > >> in minimizing the costs of session access. > >> > >> -Tal > >> > >> On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt< > >> stephen.grouc...@gmail.com> wrote: > >> > >>> REST services are definitely chatty, especially when compared to SOAP > >>> webservices that might perform N operations in one shot. > >>> > >>> To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a > >>> client picks its way through multiple server resources via links that are > >>> present in the representations, to perform some task. Being bad on > >>> bandwidth seems to me to be an inherent part of the architectural style of > >>> REST. > >>> > >>> So, I think this just means that bandwidth has to be a consideration when > >>> you are deciding what architectural style fits your system's domain. > >>> > >>> > >>> On Wed, Apr 21, 2010 at 12:58 PM, Marc Larue<m...@rupy.se> wrote: > >>> > >>>> I'm just chiming in to this, so this means with REST you have to send the > >>>> whole state back and fourth between client and server on every > >>>> request/response. So what does REST say about bandwidth, it's not a > >>>> problem? > >>>> > >>>> Cheers, > >>>> > >>>> /marc > >>>> > >>>> On Wed, 21 Apr 2010, Thierry Boileau wrote: > >>>> > >>>>> Hi Matt, > >>>>> > >>>>> from what I see, the authenticator just have to check the presence of > >>>> the user principals (set by GAE) in the authenticate(Request, Response): > >>>>> !request.getClientInfo().getPrincipals().get(0). > >>>>> > >>>>> You can provide a verifier in order to check that the application knows > >>>> the user identified by the principal name (actually the user's mail) and > >>>> set > >>>> the clientInfo#user. > >>>>> Best regards, > >>>>> Thierry Boileau > >>>>> > >>>>> ------------------------------------------------------ > >>>>> > >>>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591291 > >>>> ------------------------------------------------------ > >>>> > >>>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591738 > >>>> > >>> > >> ------------------------------------------------------ > >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591936 > > ------------------------------------------------------ > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591952 > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2592758 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2592818
