savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-hackers] savannah.gnu.org: submission of Modular Object Framew


From: planet10
Subject: [Savannah-hackers] savannah.gnu.org: submission of Modular Object Framework Organizer
Date: Tue, 04 Dec 2001 21:28:36 -0500

A package was submitted to savannah.gnu.org.
This mail was sent to address@hidden, address@hidden


M.C. Lewis <address@hidden> described the package as follows:
License: gpl
Other License: 
Package: Modular Object Framework Organizer
System name: mofo
This package does NOT want to apply for inclusion in the GNU project

The framework for what will eventually be a so-called MMORPG.

I am (planning on) moving the Planet 10 project from SourceForge to Savannah.

http://planet10.sourceforge.net

I am reworking the server code to be much more modular.  It should actually be 
usable as the basis for almost any program.

The client is already available and I will start putting new server code into 
CVS on Savannah right away.

(I also have to change web pages as sometimes I refer to the Linux kernel only, 
and other times the operating system in general, which I\'d imagine Savannah 
wants referred to as GNU/Linux.)


Here\'s some server info:



 Version control: The Server keeps track of different versions of
   the core code and loadable modules (DLLs).  This is used in:


 Crash Protection: When the server crashes, a watchdog process notes
   the version number and marks that version as Unstable.  It then
   starts up the most recent stable version listed in version
   control.  The new main process then reattaches to the persistent 
   memory store where all data is kept, resulting in almost no 
   downtime.


 Snapshotting (Checkpointing):  The Server periodically creates a
   snapshot of its entire memory space.  This is done instantly as a
   memory-to-memory copy.  The snapshot image is then written to disk
   as a background process.  This allows:


 Completely coherent backups: The entire cluster can be snapshotted
  simultaneously.  A broadcast message is sent to all nodes, which 
  pause, verify that all nodes are paused, and then all nodes 
  snapshot and unpause.  The duration of the pause is negligible, as 
  a high-priority message is sent on a separate network interface to 
  synchonize nodes.  Backups can be done quite often; saving to disk 
  is very rapid as one large binary piece of data is written to disk 
  with no parsing.  This allows:



 Cluster-wide coherent restores from saved gamestate:  If data
   corruption or loss indicates that a reversion to a previous 
   gamestate needs to take place, all nodes can reload a previous 
   memory image from disk.  This is true even after a reboot, as the 
   image will be mapped into the same virtual address space.  All 
   nodes then proceed just as they did when that snapshot was 
   originally created -- unpausing and continuing.

   
   In game terms, coherency means no unique item duplication errors,
   and no mismatches where incremental backup saved a tough NPC
   right before a fight and some party members during and after
   (restoring would then put the wounded party right next to the
    healthy monster).






reply via email to

[Prev in Thread] Current Thread [Next in Thread]