[crossfire] multithread vs multi process

[Mark Wedel]

Alex Schultz wrote:
> On Wed, 26 Nov 2008 21:22:41 -0800
> Mark Wedel <mwedel at sonic.net> wrote:
> 
>> Multiple process cons:
> <snip>
>> - Would need client (and protocol) updates in addition to server
>> updates.
> 
> I don't have much comment right on the other points, they make sense.
> However I strongly disagree on this one point. No protocol/client
> changes would really be needed at all unless it was distributed over
> separate physical servers (which I don't think is necessary to
> support). Like I said in another email, it's not hard for one process
> to "hand-off" TCP-IP sockets to another process while keeping it open.

  The issue is related to the connection, the issue is related to objects and 
tagging.

  For example, process A has used tags 1-1000.  Some items in the players 
inventory also uses those tags.  Player moves from whatever map to what process 
A is now using.  Those items in the players inventory needs to be retagged.

  Now in fairness, this could be done by deleting everything in players 
inventory and then re-sending it (and would be easiest), but that isn't 
especially bandwidth friendly.  A more narrow case would be to delete and 
re-send those objects.

  But in the simplest case, all objects in the players inventory would get 
re-tagged (unique tags for process A) - process A would most similarly act as if 
a new player logged in, as that is effectively what has happened, so all those 
get_object calls would almost certainly not have the same tags as before.

  Now you could come up with some mechanism like 'get_object_but_prefer_tag..()' 
- the problem is that right now, other than searching through every object, you 
don't know if that tag is in use.  And doing that search for a few hundred 
objects might be slow.  And you still have to cover the case where items do get 
retagged.

  And you probably don't want that to be slow - you don't want process A to slow 
down whenever a new player joins it, since the most likely scenario for this is 
player returning to the various towns.

  So in fairness, you don't need protocol changes, and instead replace it with 
this con:

- Very bandwidth intensive when player changes maps (have to re-send entire 
inventory)

There are also other solutions - you could have some central process responsible 
for handing out unique tags to all objects on all the servers, but I have a 
feeling the performance hit (due to needing to do IPC on that) probably wouldn't 
be tolerable.