[MUD-Dev] Question about copyovers.

[Adam]

 --- Kwon Ekstrom <justice at softhome.net> wrote: >

> Sorry I haven't replied to this thread before, I had meant to, but
> I've got some pretty tight deadlines for a demo of software for
> work...

Ditto :)

> From: "Anderson, David" <david.anderson at tfp.com>
>> From: Tand'a-ur [mailto:tandaur at ix.netcom.com]
 
>>> You write the descriptor numbers and other info like player
>>> names into a file and then you run the mud again with some
>>> option that tells the mud to look for that file and load up the
>>> players from it.  Then the old instance of the mud is ended.
 
> Yup, that's exactly how it's done in Erwin's Copyover code.  A few
> problems in Java, from what I've noticed, you pick up the sockets
> in the child by referencing the descriptors/memory occupied by the
> descriptors... then failing to close them out on the original
> process giving the child process full control.
 
> You can't do this in java.  First, Java sockets don't allow you to
> access the descriptors directly.  Second, Java doesn't allow you
> to access the memory or file handles directly.
 
> It's the way java hides this to provide stable cross-platform
> compliance which causes your problems.  You have a variety of
> options.

We considered routing the network connections via an intermediary
java VM, which would act as a kind of buffer in this case. Works
fine, except that you get bonus latency all over the place, and
having your application running in multiple VMs is a PITA - thanks
to Sun *still* having not yet realised that it would be useful if
VM's could talk to each other in meaningful ways. (I'm still waiting
for "VM-local" and "localhost-local" keywords to go alongside the
"static" [which really means "class-local"] identifer and the
inferred (but not explicit) "method-local" identifier for
variables)).

Haven't tried benchmarking yet, but it has the feeling of jumping
through burning hoops to try and get Java to allow some basic
functionality - which IME tends to produce extremely hard to
maintain code.

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