'Tutorial'에 해당되는 글 1건

  1. 2009.07.29 Project Darkstar Server Application Tutorials (1) (3)
2009.07.29 14:24

Project Darkstar Server Application Tutorials (1)


Coding Project Darkstar Server Applications

This chapter presents the fundamental concepts of how to code game server applications in the Project Darkstar
Server (PDS) environment. Understanding these concepts is the first step on the path to building massively
scalable, reliable, fault-tolerant, and persistent network games.

Goals and Philosophy

In order to understand the Project Darkstar Server (PDS) coding model, it is useful to understand the system's
goals. The fundamental goals are as follows:

Make server-side game code reliable, scalable, persistent, and fault-tolerant in a manner that is
transparent to the game developer.

Present a simple single-threaded event-driven programming model to the developer. The developer
should never have his or her code fail due to interactions between code handling different events.
Applications coded to run in the PDS environment are called PDS applications.

Approach to Execution

Tasks and Managers

From the point of view of the PDS application programmer, PDS applications execute in an apparently
monothreaded, event-driven model. The code handling the event appears to the coder to have sole ownership of
any data it modifies. Thus, execution is both race-proof and deadlock-proof. Under most conditions there is no
need to synchronize application code and, in fact, attempting to use the synchronized keyword in Managed
Objects1 can cause subtle bugs.

In actuality, the system has many threads of control all simultaneously processing their own events. These
threads of control are called tasks. The system keeps track of what data each task accesses. Should a conflict
arise, one task is aborted and scheduled for retry at a later date so that the other task can complete and get out of
the way.

Tasks are created by PDS managers. a PDS application uses these managers to effect actions in the PDS
environment and the outside world.

There are three standard managers in the system. In addition, arbitrary managers may be coded and added to the
PDS environment. The standard managers are:

Task Manager
A PDS application can use the Task Manager to queue tasks of its own. Tasks can be queued for
immediate execution, delayed execution, or periodic execution. Tasks created from within other tasks
are called child tasks. The task that queued the child task is called the parent task. Multiple child tasks
queued by the same parent task are called sibling tasks.

Data Manager
A PDS application can use the Data Manager to create and access persistent, distributed Java objects
called Managed Objects. The PDS application is itself composed of Managed Objects.

Channel Manager
A PDS application can use the Channel Manager to create and control publish/subscribe data channels.
These data channels are used to communicate between groups of clients and the server.

A PDS application gets access to core PDS functionality through the AppContext class, which provides
methods to obtain references to the various managers.

Task Ordering

Tasks that handle events created by a client are guaranteed to execute in order. A task to handle a client event
that occurred later in time will not start executing until the tasks to handle all earlier events generated by the
same client have finished. A child task is ordered with regard to its parent task, but not with regard to its
siblings. This means that execution of a child task will not begin until execution of the parent has completed.
There are, however, no guarantees among sibling tasks as to order of execution.

Important: There are no other order guarantees in the system. In particular, execution of tasks to handle
events of different users are not guaranteed to start executing relative to each other in the order they
arrived at the server.2

Task Lifetime

Tasks must be short-lived so that they do not block access for an inordinate amount of time to resources that
might be needed by other tasks. The PDS is configured by its operator with a maximum task execution time (the
default is 100 milliseconds). Any task that does not finish within that time will be forcibly terminated by the
system.

If you have a task that runs too long, there are two approaches to reducing its execution time:

Split it up into a chain of child tasks, each of which handles one discrete portion of the problem, and
then queues the next task in sequence. This is known as continuation-passing style.

Move the time-consuming calculations into a custom manager that queues a result-task when the
calculations are complete.

Each approach has its advantages and disadvantages. The first is easier for simple problems that lend themselves
to serial decomposition. Care must be taken that each task ends with the data in a sensible and usable state,
because there is no guarantee as to exactly when the next step will be executed.

A special case of this approach is where parts of the problem are separable and handleable in parallel. In this
case, the time to complete may be reduced by launching parallel chains of tasks. These parallel chains, however,
have no guaranteed ordering in relation to each other, so the work they perform must really be independent of
each other.

The second approach is easier for problems that don't decompose well into small, discrete components; however,
it requires the writing and installation of a custom PDS manager. (Writing custom PDS managers will be
covered by a separate document explaining how to extend the PDS environment.)

A particularly important case is code that has to go into system calls that can block for more then the task
execution lifetime. These must be implemented through a custom manager in order to produce a robust PDS
application.


1 ) PDS applications are made out of Managed Objects, which are fully explained in “Managed Objects and Managed
References,” below.

2) This also implies that tasks generated by two different clients will not necessarily get processed in the relative order they w
ere created on the clients. In practice, this is generally not true in online games anyway unless special pains are taken to make it so, since simple variations in latencies in the two clients' net communications to the server can reorder their arrival.

Trackback 1 Comment 3
  1. Favicon of http://11219.jasonjordans.com/ghdau.html BlogIcon ghd 2013.07.19 05:24 address edit & del reply

    다른 남자 부르면서 울거면 나한테 이쁘지나 말던지

  2. Favicon of http://9330.saxbycoffer.com/oakleysunglasses.php BlogIcon Cheap Oakley sunglasses 2013.07.20 01:39 address edit & del reply

    눈을 감아봐 입가에 미소가 떠오르면 네가 사랑하는 그 사람이 널 사랑하고 있는거야.

  3. Favicon of http://6164.4secat.net/ugg.php BlogIcon ugg boots 2013.07.24 11:34 address edit & del reply

    사람들은 죽을걸 알면서도 살잖아 .사랑은 원래 유치한거에요