On Thursday 27 November 2003 17:31, Jeremy Friesner wrote: > Hi Marius, > > This is easy enough to do. Make your own subclass of the > StorageReflectSession class, and your own subclass of ReflectSessionFactory > that you can attach to your server to tell it to use your subclass (as > described in the "How to make a Custom Server" document on the MUSCLE web > site). Once that is set up, you can override the > StorageReflectSession::MessageReceivedFromGateway() method in your > StorageReflectSession subclass, so that it does the authentication, and > only passes the method call up to the superclass if the "authenticated" > flag is set. So this means I will store state data in a separate tree and control access independently from the existing mechanisms in MUSCLE. Sounds easy enough to do. > >Holding server state data is similar. In any card game, and lots of other > >games, some information is "public" (table cards, game board) and other > >information is "private" (private cards, event cards etc.). My software > > will allow disconnected clients to reconnect and "resume" where they left > > off, which means server side state data (except possibly authentication > > data as explained earlier) will be stored _outside_ the > > IP-address/session trees for each client (since these trees are lost when > > clients disconnect). So I am probably going to be creating a similar tree > > to the IP address/session trees which does not go away when the client > > disconnects, so that on a client reconnect event the server will be able > > to figure out where the client left off. Each client will get full access > > to its state data after successful authentication. > > I've found that the best way to do this is to create a seperate "game > state" session object (i.e. another subclass of StorageReflectSession, one > object of which is instantiated and added to the server, but that has no > IOGateway object attached to it, and thus no TCP connection to any client > associated with it). This state-session gets added to the server as part of > the server's setup, and stays attached to the server indefinitely. This > session can then handle all the stuff you describe above, publish nodes, > handle any global logic, etc. See the document on how to create a custom > server, and the FoxRabbitCarrot article/example for details. Yes, this is how I figured it should be done. But differently from FoxRabbitCarrot, not all state is public in my example, which means it is less straightforward. But by implementing some "custom" access control mechanisms (e.g. "client read only" branches where server is the only one able to write to certain branches, and "visible only to this one authenticated client" branches) it should be easy enough to do. Thanks, Marius K.