Basically, RedDwarf Server allows the programmer to ignore the concept of threads in many ways. By adapting your server to the RedDwarf paradigm, you can create unique density and scaling possibilities.
Below is an except from part 2
When creating the server, the question always arises: how can I manage the connections and events of different clients in parallel? Did a thread for each client, a game thread or a thread pool ?
Thread pool or “thread pool”
And the answer to these questions is that the framework RedDwarf, you forget about it.RedDwarf gives an engine which is, indeed, multitasking and multithreading. But this core is hidden to the programmer to provide an environment that seems monofilament, as if they did not exist. If you want, you can forget everything learned in the past about the threads,or better yet, you can not learn to invest your time in the real logic of your game.
Behind, RedDwarf works on the Thread Pooldesign pattern, which creates a fixed number of threads or “workers” that are sent as packets of work tasks. The pool will manage the tasks and divide the work among the available threads. This is very important since this thread pool automatically determined based on the capabilities of our CPU the number of threads to create for running tasks in parallel. Come on, it will bring RedDwarf full advantage of your machine without you have schedule to worry about something that will surely bring you many headaches. To this we must add that if one day you decide to run your server on another PC different thread pool will adapt to the new CPU to boot the server. Like many frameworks for other things ( Grand Central Dispatch , Apple or Qt for example, Nokia, also free) have been marking the future of parallel programming are the tasks, not threads. I leave you a video that explains it very well, enforced at Grand Central Dispatch. Take this opportunity to recall that the GCD Podcast 4 spoke in the technology section.
Okay, perfect and wonderful. But how to use this pool in a server that uses RedDwarf? The manager that we will have to run TaskManager (Task manager could not have a better name), which will allow us to schedule tasks for execution based on a timeout. An example would be: “TaskManager, please begin to prepare a cup of coffee in about a second” or, of course, “right now”. Another utility that offers scheduling is periodic tasks that have to be repeated every so often (in a MMORPG, a good example would be the dawn and dusk, performed every 24 hours). We define the tasks to implement the Task interface, the which will force us to incorporate a run () method to our class. The pool of threads execute this method which, on completion, will indicate that it has completed the task (look at the picture above).
- Access to TaskManager: AppContext (). GetTaskManager ();
- TaskManager Services: schedulePeriodicTask () and scheduleTask ()
- Definition of defects: interface Task
I hope you found it interesting!