Ah wait (dumb database concept aside for now) what I was thinking through last night was that with a webserver the speed of the establishment of connection is of paramount importance (thus the original drive to multithreaded servers, which as they grew in complexity and modularity grew unstable... so the apache MPM solution... which is appealing... )
Anyway, the point is that with gaming it does not really matter how long it takes to establish the initial connection (within reason here, were talking milliseconds to seconds here - not minutes or anything...), thus the overhead of process creation on the server (regardless of platform) is not so much an issue with a game server as it is with a web server. So what if it takes a few milliseconds more for a connection to be established, what matters is the efficiency of communication throughout the session.. thus the issue of process creation vs thread creation overhead is moot. As a result of using a multiprocess approach we can focus on game logic and let the operating system handle system resources as it is intended/designed to do.
I half expect that a multiprocess server would be more efficient on a multi processor machine than a multithreaded app... BUT... here's the big one, shared data... that is where the efficiency of a multiprocess approach may fall down with large player numbers... thus I keep coming back to the idea of ALL the logic running on the client and noting but a "database" server side.
(leaving out a master server list application of course... or is there a better approach on that? No, No... focus bonk, focus, just some network connection code for now, gotta start somewhere...)
Topic: Multithreaded vs Multiprocess (Read 3022 times)