Main Loop

Client Main Loop

ProudNet's clients are polled, meaning that when a message is received or an event occurs, RMI call callbacks or event handler callbacks are only called on the thread that called the specific function in the game client main loop.

Unintended threaded behavior occurs mainly because game clients have fast-turning loops, and designing in the above way frees client developers from the burden of complex threaded programming.

Client Main Loop

Server Main Loop

- Receive and event callbacks

The game server utilizes all CPUs and utilizes Thread pooling to process reception for other clients while accessing the DB. ProudNet also operates in this manner and has the following features.

• When the server starts, it creates a separate Thread pool.

• The game client must call a function for incoming processing at regular intervals to handle the accumulated incoming messages, but the server does not need to make these calls.

• When an event or RMI reception occurs on the server, it will be callbacked from the thread pool that the Server has.

• Events or RMIs for the same client will not be called from more than one thread at the same time, but ProudNet will always call RMIs in order of arrival. Of course, events and RMIs for different clients will be callbacked simultaneously.

• If an RMI or event occurs while all threads are executing the callback routine, the callback will not occur immediately, but the callback will be queued until a thread completes the callback routine.

• Longer execution times for user-implemented callback routines will not break network communication, so there is no need to implement a separate thread pool for them.

The following image shows the status of clients A, B, and C as they are accommodated on the server and waiting in a queue on the server due to an RMI or event, respectively.

A1,A2,A3 -> Events or RMI for Client A B1,B2,B3 -> Events or RMI for Client B There are a total of 2 threads in the thread pool.

At that point, the rule will execute as follows.

• A1,A2,A3 will not run at the same time.

• B1,B2,B3 and C1,C2,C3 are also not executed at the same time.

• One of A1,A2,A3 and one of B1,B2,B3 and one of C1,C2,C3 can be executed at the same time.

• Since there are only two threads in the thread pool, two of A, B, and C are selected and called back, but the thread whose callback routine is completed first performs the RMI or event callback for the client that was not selected.

Example of running a thread pool

- Timer callback

Like game clients, game servers may also want to process something at certain intervals. In this case, you can have a simple loop like the one below.

while(1)
{
    do_something(); // Perform World Transition Operations
    Sleep(1); // Wait for a period of time
}

You can also use Proud.CTimerThread or Proud.CTimerQueue to run the above loop in a separate thread. However, we prefer to have the user-defined timer function called directly from the server thread pool.

For example, if the server has only one thread, the number of critical section accesses can be saved if the timer function and event callback are on the same thread. Please note that ProudNet also has these features built-in.