Mark Wedel wrote: > - Very bandwidth intensive when player changes maps (have to re-send entire > inventory) >
I was thinking about this more, and inventory is only one of the issues. The server records a lot of information about what it has sent to the client (animations, faces, etc). In a multi process model, you either have to communicate all that between the processes, or have that proxy program take care of it. The problem with having the proxy take care of it is that the more it does, potential for more bugs and thus it crashing. Also, if it starts doing too much, then it can perhaps become a bottleneck itself. And on this topic, this also adds an extra complication to the multi server setup - how (or do you) deal with cases where those multiple servers have assigned different numbers to the images, etc. The multiprocess setup (running on same server and forked off) might not have this problem, since presumably all those processes started with same data files. But if running on different servers, then likely those are reading up arch data, etc, from local files, and could be different. Dealing with a case where grass image is 156 on one server and 158 on another is a new headache. You're almost better off in that case in not trying to hide it from the player - basically have some automatic redirection, but as far as the client is concerned, it is a completely new server and thus shouldn't rely on old image data. This is certainly an area that would need further thought for multi server support. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire