[MUD-Dev] Question about copyovers.

[Smith]

From: fred at clift.org

>>> Basically, you need to keep your vector of Sockets (the users
>>> who are still connected, I have a big vector of sockets
>>> basically) and completely startup a new copy of your mud, and
>>> somehow copy those sockets over to your new running mud.  Anyone
>>> know how to do this?

> I dont know how to do it in java, but in C you have a couple of
> options.

I'm not sure it _can_ be done in java in a similar way, but even
more important, I'm pretty sure that I _wouldn't_ do anything
remotely like that in java.

Right now (admittedly, somewhat new to the java.nio package, but
excited, damn excited) I'd say that the "Right Way (TM)" to do it
would be to design a system such that the component talking to users
on sockets (likely via some sort of telnetish protocol) was dumb
wrt/ the "back end" code (which would likely be the stuff you end up
having to restart in a "copyover" scenario). So you'd have a system
diagram somewhat like

  (user: bob, on his copy of tintin)
  <-comm. protocol: telnet (mostly)->
  [system component: telnet server]
  <-comm. protocol: RMI/CORBA/etc.->
  [system component: game logic server(s)]
  <-comm. protocol: JDBC over RMI/CORBA/etc.->
  [system component: database]

Which is a poor, text only, top-down diagram of a system design.

So the scenario is this. The admins want to restart/replace the
[system component: game logic server(s)] to effect some change in
the behavior of the game (this may, btw/ just mean that there are
changes to the database pending only a commit, and that then need to
be refreshed into the live game data by the restarted components.

The system does the following:

  1. Notes to bob that game services will pause for restart

  2. Notes to [system component: telnet server] that all game
  services are shutting down for restart and that input bound for
  the game services should be buffered.

  3. Serializes all data about "in world" objects to storage

  4. Restart the [system component: game logic server(s)]

  5. [system component: game logic server(s)] request from the
  telnet server required information to reconstruct the player
  objects.

  6. [system component: game logic server(s)] unserialize all data
  about "in world" objects from storage

  7. [system component: game logic server(s)] begin accepting
  (possibly buffered) data from the telnet server

  8. The game continues, bob keeps playing.

Now, I know that doesn't answer a _bunch_ of details, but it does
eliminate the requirement that you pass a system handle to a new
process from an old process, which, I'm still not sure you can
actually _do_ in Java.

Additionally, it implies an N-tiered framework for the game system,
which means a _lot_ of the plumbing could probably be done by an EJB
application server like JBoss. The less plumbing to write, the less
code to write, the fewer bugs to find later.

<grins evilly> Plus ;) it makes my little black OOP'rs heart twitch
in excitement.

-dave
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev