[OSM-dev] what server next?

grahamjones139 at googlemail.com grahamjones139 at googlemail.com
Wed Sep 9 08:08:26 BST 2009


Tom,
I am surprised that you think reliability is the issue - I thought we could  
make it quite reliable by having multiple redundant servers.
I expected the criticism to be complexity - to make it work you need  
something along the lines of the following:
1. A 'master' which maintains a database of the available servers, whether  
they are alive or not, and how fast they are.
2. Some 'deputies' which synchronise themselves with the master and take  
over its duty if the master dies (the 'take over' bit is the bit I don't  
know how to do - will have to do something with DNS I suppose...).
3. When a request comes in the current master decides which sever to send  
the request to and passes it on.

Therefore I think the main issue is that this is rather complicated and may  
be difficult to maintain, rather than a reliability issue as such?
There is of course the additional processing step of choosing a server,  
which could slow things down, but I suppose it is just a scan through the  
bounding boxes of the various servers to see which ones can meet this  
request, so it might not add much onto the overall request.

Graham.

On Sep 8, 2009 8:46pm, Tom Hughes <tom at compton.nu> wrote:
> On 08/09/09 19:41, Graham Jones wrote:




> This would work for a single 'main' server, but I like the idea of it

> being distributed with lots of little ones (for example the computer in

> my attic could serve Northern England, someone else could do Belgium

> etc.). I don't know how to deal with re-directing the requests without

> a central main server though...any ideas?




> That kind of distribution is, in my opinion, a terrible idea. Such a  
> system will just never be reliable.



> Tom



> --

> Tom Hughes (tom at compton.nu)

> http://www.compton.nu/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090909/97079c17/attachment.html>


More information about the dev mailing list