The control channel is ok untill someone grabs the library and starts sending multicasts down the channel. As I understand it SGS will then route that on to the selected clients without my game logic seing it. At least if my server sees it first, worst case is I can log it, best case I can block it. Stops a potential attack against the clients that is routed through the server.
Well, they need to get through validation before they can send anything.
If they can break through your validation and actually log on, well, then I agree there is an issue 'cause they can flood the other clients or even flood the server.
One possible route for breaking into the systenm woudl be by inetrcepting and spoofing packets. The nice thing about the pluggable transport layer though is that it letys you implement any kind of packet encryption or validation you want. We have a few experiments we want to try in that space, such as an SSL wrapper around the UserManager/UserManagerClient. We have rouetrs at Sun that will do the SSL on the server side for us.. the big unknown is how much it will cost in terms of client CPU...
The clients can send data to the server direct, but I guess I have to send the data to the clients on a channel. It's a shame I can't make them read only to clients so that no client can use it to send data on
Well you could open a channel per client, but Im not sure I entirely see the difference. The system makes it impossible for a client to spoof the server-- every packetarrives with a "from" ID and the server has an id which is uillgeal for clients. In fact, clients cant even spoof each other beause the ID is assigned on packet arrival on the server side depending on the connection the packet was receieved from...
The sectors are going to be GLOs, but that means that 2 users connected to 2 different hosts will force the hosts to share the data, at runtime between them.
Yes but the system is *designed* to do that. Its rather the point of our putting so much effort into making the ObejctStore blindingly fast and highly scalable. Objects float between slices. Dont worry, be happy, we deal with it.
.My plan was that a users state would be saved when they docked at some object, or warped in, effectivly removing them from the game area into a lobby area.
Again, your working too hard! we do that for you. Every task is a durable atomic transaction. So state is being constantly saved. (Now I dont gaurantee 100% durability in the case of a power failure... only durability up to the last few seconds and that what IS saved is referntially integrous. This allows me to decouple the very very fast in-memory operations from the long term disc storage.)
If the server fell over they got reverted to the last saved location/stats/inventory etc. This isn't ideal and I like the idea of if one server fails, another takes over. You are also correct that the load balancing is handled much better. Does this mean that every task that modifies a GLO results in a DB write?
Yup. Every task is a transaction and all object changes are comitted when the trasnaction completes.
As I say, this is why we worked so hard on and worry so much abou the ObjectStore. Its really the magic that makes the whole rest of the system possible!
Btw, the SDK object store is a compromise so you can run on a single system. Its an ini-memory database backing up to derby. Derbyis actually not terrbily fast at writing BLOBs so we have found that, if you really ebat on the server hard, you can get a fairly large "waiting" queue to build up for derby to process. We might replace derby in the SDK at soem point if I found a more performant pure-java database...