Alex Schultz wrote: > On Wed, 26 Nov 2008 21:22:41 -0800 > Mark Wedel <[EMAIL PROTECTED]> 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. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
