[crossfire] multithread vs multi process

[Mark Wedel]

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.