On Mon, 2008-06-23 at 14:43 +1000, Matt Palmer wrote: > You really want something a bit more reliable for your protocol. A pubsub > mechanism could work to do the updates, but the resync requirement is still > unsolved. The short answer is that data replication is a hard problem. > <grin> > > Assuming that there's a "state" that you want all machines to be in, you > could identify each state with a unique number, and send out "state updates" > that say "from state X, change <foo> to be in state Y". Then you send out > those updates to each client. Each client keeps it's own state data and the > ID of that state. If it sees a "from state X" message and it's on state Z, > then it goes "bugger, I probably missed one" and asks the server for a > complete state dump, which has all the data and the ID associated with it.
In my case it is not that hard. It is sport so there is an event or a match (magic number allocated from central server) and then there are actions (eg begin and end of game) which are numbered at the collecting the database. So there is pretty much a built in process. UDP is fairly simple. Tracking what has happened is fairly simple. I was going to fall back to TCP if I missed something then grab the whole lot from last message received to this message. So if I receive message 10 I will ask for 0 through 10, if I received 5 already 6-10, etc. the Actions will take relatively a long time at least seconds, and because I am in a local network order should not be a major issue, I hope. The main reason for UDP is the broadcast element, I want clients to just start receiving data no matter which machine is serving it up. There could be three scorers on slightly different locations at the same venue with different match id's and the central servers (yes plural) must accept all of them all at once. Nothing is to be centralised. It is all adhoc setup. Equipment, power and networks break all the time leaving damaged systems. It all has to hot swap. The tricky bit happens when the master connection goes down and a slave takes over then trying to reconcile inconsistent data from the two when the master comes back up. Not sure how I am going to handle this, yet. Probably either make one the master and hence win or reconcile manually (lots of stuff to code so probably not worth it for the risk) I took this job because it is fun and challenging. Ken _______________________________________________ coders mailing list coders@slug.org.au http://lists.slug.org.au/listinfo/coders
