Bob Tanner wrote: > > Easily solved. Simpliest solution is have the picture servers in a round-robin > DNS setup. Just need to make sure the client, timesout quickly and tries the > next IP. > > A more complex setting, but vastly more reliable, would be using Linux Virtual > Server (LVS) ( http://www.linuxvirtualserver.org/ ) with multiple directors using > Virtual Servers via IP Tunneling (VS-TUN). To me, thats the biggest issue - time. Even with just caching, players saying that seeing the ? for a few ticks is potentially too long - that could be a nasty monster that kills you before you know what it is. I only see the addition of seperate picture servers making this longer (have to dns lookup server, connect to it, then get the image). > > > 2) Simplicity - setting up a new crossfire server now requires the potential > > that you add new images to the picture server. This now requires > > authentication of some sort. > > Maybe use a DNS analogy here. Couldn't the client look in its local cache for > the image. If not, ask the server it's connected to, if not forward the request > the picture server? But given that case, the request would never get beyond the server it is connected to - in some sense, the server connected to must have the images (if it doesn't, whats the likelihood that a picture server would?) The idea of picture servers came up to reduce server load. Sending images doesn't really load the server, it loads the network. The amount of processing it takes to send an image isn't that much. Note that a seperate picture server does not help if the limitation is really the bandwidth at the client end of the connection (ie, playing at the end of an isdn or dialup modem line). A separate picture server really only helps if the crossfire server is otherwise using all of its bandwidth. In this case, a picture server only helps if it is not using the same shared connection as the crossfire server. To give a real example: If there was pictureserver.real-time.com in addition to metalforge.real-time.com, this gains no benefit over metalforge.real-time.com doing everything like it does right now. while metalforge may do 1% less work by not having to serve images, the bandwidth to/from real-time would still be the issue