mctrivia: I think there would be a problem there - how to ensure synchronization between the database in Europe with the DB in America?

pauloaguia: Syncronizing servers is a very common task and happens all over the world. The two servers would have to comunicate back and forth any changes that are made. This I am sure would be a lot of data but still a lot less then the data used by everyone using the same server since no graphical data is sent in these exchanges

mctrivia: The big thing is it takes time to code the syncronization algorithms and having a second server farm is not a cheap thing when you are talking this much bandwidth and space. It would though also act as a redundant system. Should one go down everyone can use the one that is still operating.

mctrivia: Actually, it would not be impossible if it's only a master-slave architecture because it could work even with a data copy delay. However, to host two full featured BrainKings would require a full two-ways fast Europe-America replication and that, uh, that would be a real problem. For example, consider a situation when a user in Europe accepts a public invitation but another user in USA accepts the same invitation at the same time. So the European server sends a message "hey, mark this invitation as accepted!" and, in a few seconds, it receives a message "it is already accepted by another player!". Bang! A replication conflict.

Fencer: It may be true that some things like accepting games could have problems with a complete clone but playing them would have no problem at all. If I am playing you I can get the game off the US server(It is cheaper there then Canada) and then submit it back to the US server. You can pick up the game some time in the next week off your local server.

Even board are not that time sensitive since you are not using a real time model like on my server. If someones post shows up 1 or 2 sec late we
can chock it up to just not refreshing at the right time to see that reply before responding.

Things that are really time sensitive like game accepting could be left all on one server so you don't have the update error problems

Just pictures is a workable start. Often I will have a board slow down because of pictures and I have a huge cach.

mctrivia: After reading what was below, you said what I was thinking.

It would take some planning, but first you could figure out what is time sensitive vs. what is not.

Waiting room & such can be time sensitive, so if someone was hooked with the #2 server, it would take a little extra time to perform those operations since it would need to check with #1 server first.

Things like discussion boards are not. That is lets say someone posts a message on a discussion board on server #2. At first, give it a temp # (so you don't get a message on both servers with the same ID), then server #2 sends that over to server #1 where it gets the "real" post #. So possible at the most there would be a deal of 10 seconds or so between time the post is made and is viewable to everyone on both servers - but that would not be an issue. (live chat might be - but we don't have that here)

Most games would not be an issue - even though I could see a small issue with those who like to try to play "live" games with very short time limits like 1 hour total time with Fischer clock and such.

Thing is, 95% of the things most players do (play games, read discussion boards) do not require that the main server know about it immediately. That is most everything could be played on the #2 server while it is updating itself with the main #1 server in the background. It could work - but some good planning would be needed.

coan.net: To fix the fisher clock problem you could give users the option of chosing witch server they are on instead of making it automatic. So if you know you are going to play a 1 hour game you will pre arange to both use the same server. Most people are just going to use witch ever is closest and ideally that would be done automatically for them with the overide option for those rare cases were people are playing super fast games.

mctrivia: I appreciate the feature,I really do,but is there any way to do away with the explanation in the messege box?
People think I'm hawking a product.

Jim Dandy: do you mean the auto player setting? You need to uncheck the box on his website when you log in.

Eriisa: If you are speaking of mctrivia's version,yes

Jim Dandy: yep. that's where.

Eriisa: I don't log in seperately.I guess I should find a way to access it

Jim Dandy: By default the ad feature is turned off. To log in go to: http://www.mctrivia.com/autoplayer/login.php there is a check box for the ad feature uncheck it then press update.

mctrivia: I just did,but hats off to you for the feature,you're a bright guy

Jim Dandy: thanks it has been a fun project but I can't wait for the day it is no longer needed. Fencer can you please implement it before I move to the middle of no were. You got 3 to 4 years.

mctrivia: if only you had said 3 to 4 months...

pauloaguia: you would most likely be stuck with no autoplayer from both then.

mctrivia: I meant Fencer might be more pressured to improve the site's autoplayer in that case...
But yes, I understand what you mean. The AutoPlayer / AutoPass / AutoMover was never a project Fencer was much interested in...

pauloaguia: Maybe you just need to give him more of an assentive. Try getting the names of 10 people willing to become black rooks if he will implement a autopass/automove system that does not require the oponent to also use.

mctrivia: You read my mind. But the database replication is the main problem. Unless we want two isolated BrainKings which could share the list of users but not the table of games and moves.