[crossfire] C++/Qt server version

[Alex Schultz]

On Tue, 25 Nov 2008 00:20:38 -0800
Mark Wedel <mwedel at sonic.net> 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