|Do you know where your variables are?|
Re^7: How to share complex data structure in threads ?by BrowserUk (Pope)
|on Dec 31, 2012 at 03:35 UTC||Need Help??|
This reminds me some yrs ago, I used threads shared hash for a simple chat server for our 20 something ppl dept, the hash queues unread messages... and what periodically happening was a Out of memory error, and the mesgs on the server and the server self gone.
Out of memory for a 20 person chat server? Then you wrote it wrong!
I have threaded servers (some posted here) that quite happily handle 100 (or even 1000, simple persistent) concurrent connections, shipping high volumes of data bidirectionally that will run forever without leaks or the memory problems.
What kills the idea of threading for your MMURPG is mostly down to your proposed architecture. RPG users expect to pick up where they left off the last time they logged on, which means you need to persist the state of their game at the point they left and reinstate it when they come back. Whether that's in 2 minutes or 2 years time. A shared state DB is inherently the wrong architecture for such an application.
The second is the possible future scale of the application. A 20-man dept. is unlikely to suddenly increase by 2 or 3 orders of magnitude over night; but a role playing game, if sufficiently compelling, easily could.
Were I writing your MMURPG, I would split the comms servers and the DB/FS servers into different processes as I outlined above; but I would still favour threads over an event driven architecture for both parts. This because the simple linear flows and local state of threaded code are easier to reason about, write, maintain and scale than the open-access, global state and having to break logically linear code into the iddy-biddy chunks that event-driven architectures require in order to ensure responsiveness.
But I wouldn't use one thread per connection. It is simple too wasteful of resources. A single foreground thread would receive inbound action requests and immediately queue them to a pool of threads that would talk to the background DB (via sockets for inter/intra-machine flexibility), to perform those actions on the DB. Replies to clients go directly from the pool threads to the clients. I'd uses a similar thread-pool architecture for the DB processes.
The benefit of this de-coupled, threaded architecture is that when the number of clients grow you have the choice of how to expand:
One scales easily and automatically; the other requires extensive re-development and testing as the underlying hardware changes. I prefer the former.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.