[Free] Server features to be discussed

[john grden]

On 8 Sep 2005 16:49:01 -0000, grant at bluetube.com <grant at bluetube.com> wrote:

"You can handle this at the container/configration level so the "key" is 
validated on every call or at a predetermined session age or for certain 
components that require the identity of the user to be verified. The client 
will never do any decoding or decrypting it will just need to pass the key, 
kinda like how cookies work, the browser has them but the server actually 
reads the cookie."

that's perfect, I was thinking the client would have some work to do

"You can have session recovery where the "session" is persisted to a backend 
such as database/filesystem/database but you are talking about quite a 
sophisitcated feature which I'd be inclined to use a J2EE server for. The 
potential complexities when you have a server with 1000 clients that goes 
belly up and needs to restart all 1000 clients and restore their server 
state could be very difficult to implement, we can take a look at how much 
of that you'd want to implement. Session back/replication is expensive as 
every change to the users "session" that could restore to a previous state 
requires a write or change to a backing store and if replicated its 
duplicated across servers. What we generally do is if the server goes down 
the user is tranfered to another server but they have to restart their 
session (log back in) as session replication with 1000's of users it too 
expensive for the servers/network and the application architecture."

Yes, this makes sense. I don't know that I was thinking that every users's 
state/action would be stored, I was thinking more at the Room/application 
level. Users in a room really and maybe general properties that you 
designate as persistant to the room. I would think that would be a minimal 
write scenario to a DB/log, but then again, maybe not enough to justify as a 
part of the server. Maybe some hooks that allow this to happen if the 
developer wants this level of failover?

" what your asking for is built into a J2EE server, say you have an 
application packaged as an ear or war file, this application can be deployed 
to multiple servers setup as a cluster, so the room instance would exist on 
one or more servers but its physical location is transparent to the caller. 
If you want to deploy a room "application" to 1 server only you can target 
it as non clustered but then you have lost your failover ability."

ah ok, then, that's exactly what i was asking about, thanks for taking time 
on that one Grant, appreciate that.



Thanks Grant!


-- 
John Grden - Blitz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/free_osflash.org/attachments/20050908/3cc4f8ac/attachment.htm