On Mon, 24 Nov 2008 22:06:40 -0800 Mark Wedel <[EMAIL PROTECTED]> wrote:
> Shared strings: While perhaps no reason to get rid of them, I also > wonder how necessary they are now days. They do simplify > comparisons. And with C++ and proper class descriptions, they can be > made to be safe (have to use class functions to modify the name, > and it knows to do the right thing). But shared strings date back a > long time in crossfire, to when systems had much less memory and this > wasmore a concern. They certainly do still save space, but the amount > of space saved may not be worth the extra handling. It should > certainly be reviewed - many design decisions date back to when > computers where much less capable than they are now, and may not make > much sense. I'm note sure exactly how much space is saved, but I think there's a high chance they may still be desirable due to the shear amount of floor tile objects and such in CF if someone is running through a large number of large maps. Now it's possible the benefit might be small these days but in any case, I don't think that making decisions about shared strings can go much further without getting real data on how much space they save. <snip> > Distributed server archetype: Need more details - having redundancy > (client rerouting with minimal data loss) might not be worth the > effort - have to make sure you don't have two servers trying to > control the same area, recovery when one comes back on-line, etc. > But being distributed (this server is responsible for scorn region, > this one for navar city, etc) to reduce load may make sense, with > there being smarts to transfer character detail between those, etc. > In terms of server failure/crash, the client could improve that > experience - most servers restart when they crash, so it is really to > the client to pop up a window with something like 'connection lost - > trying to reconnect (with spinning disk or something)'. > > Multithread server: I think this is a must - computers are moving > more and more towards multiple cores, and less towards raw speed, and > for crossfire to make use of those really requires multithreading. I > always thought that multithreading at the map level would make the > most sense - this potentially lets one use many threads (and thus > cores) and is probably the simplest way to go. I was recently thinking about server multithreading, and now I'm thinking, why bother with threads? Why not do a model like one-process-per-every-few-maps instead of multithreading? It eliminates potential issues with mutexes and locking and such, transfering things between the processes could be done by IPC. The further advantage of going with a multi-process model instead of multi-thread model, is that much of the very same code could be adapted to make a distributed server possible if anyone ever thinks there's a need. I don't currently think there's a need for a distributed server system, but a multi-process model would lend well to adapting to distributed at a later date. Furthermore, a multi-process model would also make server crashes less disruptive because they'd usually just kill off a map or 3 instead of everywhere. Perhaps we should make a pros/cons chart to outline the merits of multi-process and multi-thread to compare? Alex Schultz _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
