On Tue, 25 Nov 2008 00:20:38 -0800 Mark Wedel <[EMAIL PROTECTED]> wrote:
> Also, I think re-joining existing servers may be more difficult. > If I'm in scorn and go off into a new building, and that building is > not currently active, it goes and forks off a new process and the > existing file descriptor lives OK. However, if that building already > has process associated with it (another player entered it), we can't > fork - instead, my client has to get directed to that other process. > And most likely, that means a different port (13329, 13330, ...) on > that server. > > That is doable, but does require yet some other process to monitor > all those forked processes out there to know what is available and > what to connect to. Also, for folks running servers behind firewalls > (probably most everyone) it means opening a potentially large number > of ports. Well a few comments on these aspects. I don't think we need to mess around with opening more ports. One option is the supervising process could just proxy the connections through IPC. If this isn't good enough and we want direct connections to the process, it actually IS possible under both *nix and win32 to my understanding, to transfer file descriptors, and hence TCP/IP sockets, to another process, without disruption/disconnection/etc. This could also be used, so really, new ports or client changes would *not* be needed at all to support a multi-process model. (Note that all this said, I'm not current which approach I'd consider best, but I'm noting that one way or another, we wouldn't need additional ports or messing with the client or any of that kind of stuff, to achieve a multi-process model) Alex _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
