March 1998
- Describe Concept Stephen Zepp
- Describe Concept Jon A. Lambert
- Describe Concept J C Lawrence
- Describe Concept Jon A. Lambert
- Describe Concept J C Lawrence
- Describe Concept Vadim Tkachenko
- Tutorial: Let's build a Compiler! - Part XI: Lexical Scan Revisited Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XII: Miscellany Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XIII: Procedures Jon A. Lambert
- Tutorial: Let's build a Compiler! Chris Gray
- VEIL Network Protocol Brandon Gillespie
- Tutorial: Let's build a Compiler! - Part XIV: Types Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XV: Back to the Future Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XVI: Unit Construction Jon A. Lambert
- For Ling's FAQ Koster, Raph
- MUD Ratings jlsysinc.ix.netcom.com@ix.netcom.com
- Random Generation Tools Ling
- ANNOUNCE: DB Robin Carey
- THE DARKWHOLE TESTS J C Lawrence
- Magic as Metaphor J C Lawrence
- Magic as Metaphor J C Lawrence
- Magic as Metaphor Jon A. Lambert
- Magic as Metaphor J C Lawrence
- CT - A Hypothetical Session (mid 1995) J C Lawrence
- 2Cyberconf: An article J C Lawrence
- (long) AnarchyMOO Primary Log J C Lawrence
- (short) AnarchyMOO parting salute J C Lawrence
- AnarchyMOO purpose J C Lawrence
- (fwd) CODE RELEASE: [client] Spod! (Java mud client) J C Lawrence
- (fwd) CODE RELEASE: [client]: lyntin (hacker's client) 1.1b Released J C Lawrence
- DarkWhole Test #1 J C Lawrence
- DarkWhole Test #2 J C Lawrence
- DarkWhole test #3 J C Lawrence
- DarkWhole test #4 J C Lawrence
- DarkWhole test #5 J C Lawrence
- DarkWhole test Identity Crisis J C Lawrence
- The Craft of Adventure J C Lawrence
- What in THE Hell was that? Stephen Zepp
- What in THE Hell was that? Ben Greear
- What in THE Hell was that? J C Lawrence
- What in THE Hell was that? Jon A. Lambert
- (fwd) Varying Time Commitment Levels: what's an admin to do? J C Lawrence
- Hello, and a brief intro cimri
- Hello, and a brief intro Ben Greear
- (no title) Time limits? s001gmu@nova.wright.edu
- (no title) Time limits? Justin McKinnerney
- (no title) Time limits? J C Lawrence
- Speaking of Avatars Jon A. Lambert
- Speaking of Avatars Jon A. Lambert
- Speaking of Avatars J C Lawrence
- Speaking of Avatars Jon A. Lambert
- Re: Vadim Tkachenko
- META: Broken mail headers coder@ibm.net
- META: Broken mail headers Alex Oren
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Alex Oren
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Chris Gray
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Caliban Tiresias Darklock
- META: Broken mail headers Chris Gray
- Turn-based MU*'s Sauron
- Balancing Addicts -> soft vs. hard enforcement cimri
- Balancing Addicts -> soft vs. hard enforcement Justin McKinnerney
- Balancing Addicts -> soft vs. hard enforcement J C Lawrence
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Ling
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Matt Chatterley
- Balancing Addicts -> soft vs. hard enforcement J C Lawrence
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Matt Chatterley
- Balancing Addicts -> soft vs. hard enforcement Adam Wiggins
- Balancing Addicts -> soft vs. hard enforcement Joel Dillon
- SfD: Clientside Caching Nathan F Yospe
- SfD: Clientside Caching Jon A. Lambert
- SfD: Clientside Caching Nathan F Yospe
- SfD: Clientside Caching Chris Gray
- SfD: Clientside Caching Jon A. Lambert
- (subject missing) J C Lawrence
- Balancing Addicts Ling
- Balancing Addicts Richard Woolcock
- Balancing Addicts Ling
- Balancing Addicts J C Lawrence
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Niklas Elmqvist
- Transport layer (UDP vs TCP) Jon Leonard
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Jon Leonard
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Chris Gray
- Transport layer (UDP vs TCP) Niklas Elmqvist
- Transport layer (UDP vs TCP) Jon A. Lambert
- Transport layer (UDP vs TCP) Ben Greear
- Time Limits? Jon A. Lambert
- META: topic and thread culling (was Balancing Addicts -> soft vs. hard enforcement ) J C Lawrence
- (subject missing) J C Lawrence
- XShipWars J C Lawrence
- (fwd) INFO: [client] Chaco looking for new parent for Pueblo J C Lawrence
- SIMULATING FUTURE HISTORIES: THE NAU SOLAR SYSTEM SIMULATION & MARS SETTLEMENT J C Lawrence
- (fwd) Functional Security J C Lawrence
- (fwd) Functional Security Ling
- (fwd) Functional Security Chris Gray
- (fwd) Functional Security Matt Chatterley
- (fwd) Functional Security Miroslav Silovic
- (fwd) Functional Security Felix A. Croes
- (fwd) Functional Security J C Lawrence
- SIMULATING FUTURE HISTORIES s001gmu@nova.wright.edu
- Character development [was ] Matt Chatterley
- Character development [was ] J C Lawrence
- Character development [was ] Matt Chatterley
- Character development [was ] Travis Casey
- Character development [was ] J C Lawrence
- Character development [was ] Travis S. Casey
- Character development [was ] Marian Griffith
- Character development [was ] Travis S. Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Travis Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Travis Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Marian Griffith
- Character development [was ] Vadim Tkachenko
- Character development [was ] Marian Griffith
- Character development [was ] s001gmu@nova.wright.edu
- Character development [was ] Marian Griffith
- Character development [was ] J C Lawrence
- Character development [was ] Cimri
- Character development [was ] J C Lawrence
- Character development [was ] s001gmu@nova.wright.edu
- Character development [was ] Caliban Tiresias Darklock
- Character development [was ] Caliban Tiresias Darklock
- Character development [was ] Vadim Tkachenko
- Character development [was ] Ben Greear
- Character development [was ] Matt Chatterley
- Character development [was ] J C Lawrence
- Character development [was ] Matt Chatterley
- Character development [was ] Travis S. Casey
- Character development [was ] J C Lawrence
- Character development [was ] Koster, Raph
- Character development [was ] J C Lawrence
- Character development [was ] Koster, Raph
- Character development [was ] Alex Bertoglio
- Character development [was ] J C Lawrence
- Character development [was ] J C Lawrence
- Character development [was ] John Bertoglio
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Chris Gray
- 3D engines for MUDs J C Lawrence
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Chris Gray
- 3D engines for MUDs Ling
- 3D engines for MUDs Koster, Raph
- 3D engines for MUDs Mike Sellers
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Koster, Raph
- 3D engines for MUDs Ling
- 3D engines for MUDs s001gmu@nova.wright.edu
- Dynamic Loading of Modules Niklas Elmqvist
On Thu, 19 Mar 1998, J C Lawrence wrote:
> On Tue, 24 Feb 1998 00:12:50 PST8PDT
> Niklas Elmqvist<d97elm@dtek.chalmers.se> wrote:
> > As I said earlier, I am aiming to decouple the actual core server
> > from the world processing routines. Ideally, the main server would
> > not even *know* it is running a MUD, it would be sort of a
> > general-purpose core...
>
> You have loosely described the general purpose network server espoused
> by such as the ColdX project. Cold is currently being used to server
> MUDs, web sites, as an SQL database frontend (for web) and otehr
> purposes.
Ahh, *that* is what Cold does. I've checked out cold.org a couple of times
but never really understood what it all was supposed to do -- it was so
very generic. Nice to see that one's thinking parallells that of other
people, though.
> > ...and all the functionality such as DB
> > management, socket I/O and AI would be implemented in free-standing
> > modules separate from the main executable (at least, I envisioned
> > this in the beginning).
>
> Which abstraction is deeper than Cold (or any other that I know of)
> has attempted.
Of course, this abstraction comes at a price. Since the modules are very
decoupled and don't know anything about each other's existence, I need a
decoupled way of allowing them to exchange information. I envision this
mechanism as a request chain on which the individual modules can put their
ear to and listen on (alternatively, register their interest in different
kinds of requests to a request manager or something). Whenever a request
comes along of the desired type, the module snags it and processes it
(this request may be a buffer of unprocessed text from the socket I/O
module, or a user command from the interpreter or whatever). The module
would then possibly emit a request on its own on the request chain to
pass along its processed information (a parser would emit parsed text, an
interpreter a user command, a magic module an area effect, etc). This way,
I have a decoupled intermodule communications chain.
As I said earlier, the problem I can see with all this is that it is not
going to be very computationally efficient -- but it is neat, IMO. That
is, for every command issued by the user, for example, I will need a
potentially large number of requests passed between different modules:
socket I/O => parser => interpreter => user command handler
and so on. Also, I expect that using C++ instead of C (like I did in my
earlier effort PirateMUD) will also decrease performance somewhat,
although I have no idea about how much. No matter. It all just means I'm
going to need a bigger server. <cough>
> > I mentioned this to a RL friend of mine, and
> > he pointed out that it all sounded very much like conventional OS
> > architecture, especially like the module system of Linux kernels.
>
> I should point out that the original version of Shades was written to
> run on a DEC PDP-11. In truth Hazeii hacked RMS to be the MUD (mainly
> the command interpreter) so that effectively the OS _was_ the MUD.
Sounds like fun. :) Hey, everybody, why don't we all take the Linux kernel
and modify it to become MudLinux! Or we could call it Mudix or
something...
> <bow> Cute. Note that the vtable handling could easily get very
> messy, especially if you abstract heavily, go for multiple
> inheritance, or any of the nastier virtual structures.
Well, the vtable handling is hidden from me by the compiler, so hopefully
I won't have to deal with that. I *do* have to deal with potential
performance loss, though, I expect.
> What platform/compiler BTW?
This on a x86 (Pentium II, as a matter of fact) running Linux 2.something
using the gcc/g++ 2.7.2.2 compiler... I've heard that gcc 2.8.0 and egcs
fixes some nasty problems in gcc 2.7.2.2 (especially when it comes to
templates, the STL string class header will not compile if it is not the
first STL #include in a source file, for example), so I am thinking about
upgrading. Furthermore, I have no idea whether the dynamic linking scheme
works on other platforms than Linux -- it *should* work on SunOS and
Solaris (and possibly other Unices) since the dl*() functions are derived
from Sun.
> > Incidentally, a
> > friend (the one mentioned above) later reported that this is
> > impossible in Windows-style DLLs.
>
> Yup. The features behind this working are that the name mangling and
> vtable manipulations remained consistent.
I actually ran into trouble with name mangling when I at first attached a
module to the core binary and tried to call a factory function called (not
surprisingly) foo() in the module which would return a bClass (a class
secretly inherited from aClass) object. Of course, g++ had mangled foo()
into something like foo_fV (I discovered this with the nm utility). By
instead doing
extern "C" aClass *foo(void)
I prevented this name mangling.
> > If the base classes are correctly
> > implemented, the core will never even have to be recompiled and thus
> > never rebooted (not accounting for fatal bugs, that is <g>)!
>
> You're going to need a very clean connect/disconnect model (and likely
> require single-threading unless you want to be excessively
> entertained) to ensure that no code points are in or about to enter a
> modeule which you wish to remove, or retain state data, or
> back-references (such as instances) for the about-to-be-removed
> module.
Haven't thought of this, but I was probably going to implement this
single-threaded nonetheless. As for the connect/disconnect model, this
will probably be handled by a special module handler which is part of the
core functionality of the server executable. This handler would ensure
that all references to a module are cleanly removed when disconnecting it.
Because of the decoupled module architecture, the core server is the
*only* part of the MUd which knows about a specific module and its
methods, and it only keeps a reference and knows the base class of the
module at that (which could be a class called BaseModule or something).
All data flow is handled through the request chain mentioned above, as
well as through events in the event list. Therefore, I would never have
any problems of having another module keeping invalid references to a
detached module -- the only effect of a detached module would be that it
would no longer catch requests on the request chain (possibly leading to
the request being unhandled, which of course would result in a system
error or something like that, but would not hang the server).
> J C Lawrence Internet: claw@null.net
> (Contractor) Internet: coder@ibm.net
> ---------(*) Internet: claw@under.engr.sgi.com
> ...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
-- Niklas Elmqvist (d97elm@dtek.chalmers.se) ----------------------
"You can't trample infidels when you're a tortoise. I mean, all you
could do is give them a meaningful look."
- Terry Pratchett, Small Gods - Dynamic Loading of Modules Greg Munt
- Dynamic Loading of Modules J C Lawrence
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Vadim Tkachenko
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Chris Gray
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Nathan F Yospe
- Parlez vous NPC? Matt Chatterley
- Dynamic Loading of Modules Niklas Elmqvist
- Dynamic Loading of Modules Chris Gray
- Dynamic Loading of Modules Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? Greg Munt
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? s001gmu@nova.wright.edu
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Ross Nicoll
- World Persistence, flat files v/s DB v/s ?? Ross Nicoll
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? s001gmu@nova.wright.edu
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Adam Wiggins
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Orion Henry
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Nathan F Yospe
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Greg Munt
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- Jukebox Vadim Tkachenko
- Another recruit for the list? Joel Dillon
- OT: Martin Keegan J C Lawrence
- Old code Joel Dillon
- Old code Michael Hohensee
- UML/Commercial v Free Muds Greg Munt
- UML/Commercial v Free Muds Nathan F Yospe
- UML/Commercial v Free Muds Jon A. Lambert
- Heightfield Terrain Rendering Paper Niklas Elmqvist
- (subject missing) J C Lawrence
- (fwd) Roleplaying J C Lawrence
- (fwd) Roleplaying s001gmu@nova.wright.edu
- (fwd) Roleplaying Katrina McClelan
- (fwd) Roleplaying Ling
- (fwd) Roleplaying J C Lawrence
- (fwd) Roleplaying Travis Casey
- Predicting future motion intelligently J C Lawrence
- META: New Mail server and ISP J C Lawrence
- (rec.games.mud.admin) Roleplaying (fwd) Nathan F Yospe
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. Jon A. Lambert
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. Chris Gray
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- UML & CORBA Greg Munt
- [MUD-Dev]: smoothing J C Lawrence
- [MUD-Dev]: smoothing J C Lawrence