[MUD-Dev] CORBA, RMI, threads

[Nathan Yospe]

On Thu, 22 Jan 1998, Marc Eyrignoux wrote:

:Hello
:I apologize for not saying very much on the list, but I don't think I
:would
:be helpful for anybody.
:I have some questions that I couldn't solve by myself, even by rereading
:all
:the mails on the subject:
:- If I chose to use CORBA or RMI for the communications between the
:clients and
:the serveur, I am afraid the generated traffic will be too important.

Speaking of which, someone (Chris L, I think) once posted several CORBA
URLs. I'd like to see them again, if you could grep the archives, please?

:The aim is to
:have efficient and quick communications, it doesn't matter for me if the
:programing
:is less easy.

I've doing client-server communications right now, both for my mud and
professionally. I think the first couple things that catch my eye are:

:- If I have a telnet client and a java serveur (or a java client and a
:C++ serveur), 

telnet client? Er... are you doing text output? And how much of the protocol
are you implementing? Whatever the case, if you do this, you haven't really
any need for Corba or RMI. And you are NOT getting what you say you want.
As for C++ server/Java client... RMI will work, CORBA will too, from what
I can see so far. Custom interfaces are also good. I'm using a lot of rpc
generated code for these...

:is it possible to use RMI? I know CORBA is programed on both platforms.
:- I intend to have a multi-threaded serveur, as the mails on the list
:seemed to
:prove it was the best way to program the evenemential part of the code.
:So my projects
:are:
:* one thread per connection, for listening

Usually a good idea. You might want to look into thread containers that
are capable of checking threads in and out of a pool as well.

:* the use of a multi-threaded database like postgreSQL or mySQL, which
:libraries are
:already threaded

Hmm. Databased mud. *frown* Am I the only guy here who thinks this is bad
design?

:* a thread for the time (in my mud, 3mn_real_life=1h_mud_life)

Whoa, whoa, whoa! What? Er... I think you'll find you are a lot better off
coordinating with a system clock or somewhat, instead of trying to make a
clock thread (which will go asynchronous, and screw you up royally.)

:* a mecanism based upon thread for the event handler.

OK. This'll take a lot more thought, but its the right way to go, IMO.

:So they are 3 points I would like to get clearer:
:+ even if the functions given in the database library are multithreaded,
:do I need to 
:thread the functions that call them?

Not quite reading you here. How are you storing functions in the database?

:+ are NPCs threads in your servers? or is there something like
:while (1)
:{ 
:	getTheListOfActiveMonsters();
:	for (monster = firstMonster(); monster = lastMonster(); monster++)
:		{ 
:		monster.act();
:		}
:}

NO!

Then again...

I use a "locational" heirarchy for both storage of references (OK, I confess,
there is a database or five on the client side, and a sort of a database on
the server for error checking.) and for my event/thread system. This means
that each player becomes the center of a flury of activity (observer
triggered resolution of quantum states. No, really, that was my model, and
I think I've actually managed to satisfy it for an optimal solution to a
lot of concurency issues, not to mention process concerns.) which controls
the behavior of any NPCs and other objects in the player's heirarchy.

:In the case monsters are threads, do you need to stock somewhere the
:list of active monsters?

Well, even in my system, instatiated (as opposed to potential) objects DO
have to be tracked.

:In this case, is there an accurate way of stocking them?

Hash table of instances, an instance is a collection of references to a
client-side database coupled with a server-side physical model and behavior
model. You won't find better than a well implemented hash table, believe me 
I tried. Dynamic trees are the next best thing.

:In fact, I intend to make the monsters act every 15 seconds. A thread
:that would sleep for 15 
:seconds and acts according to the situation at the moment it wakes up
:seems to be a good way
:for doing this. But I forget the case when the monster has to know
:something that happened 
:while it was sleeping. The question is: do I have to set in place a
:mecanism that warns the monster,
:or isn't it obliged? (in fact my question is: are monsters in your muds
:intelligent or not?

Oh, yes, they are quite intelligent. Of course, I don't have any of this
fifteen second sleep thing... and my _denizens_, whatever the form, are
rarely instantiated unless there is a player around. They often borrow 
some of their intelligence from players. I've posted on this before.

:have you programed that kind of things?)

Depends...

:+ I have read the structure of the event handler of people who explained
:them.
:In the case of an event queue, you stock the events in a structure
:handled by a class.
:But this class has to do something like
:while (1)
:{
:	getTheMostUrgentEvents();
:	executeEvent();
:	rescheduleOtherEvents();
:}
:Isn't it a lost of cpu time compared to:
:thread.sleep(n);

Yes and no. It is a lot easier on other resources, and thread.sleep(n) uses
a little bit of cpu that you won't see obviously. After all, it is usually
implemented as an event queue itself, or something similar. (stack queue)
It also makes a tremendous difference HOW you implement synchronization (Or
at least conflict resolution) between threads. I actually have a built in
mechanism that avoids the dragon's dinner problem altogether, at the
occasional cost of a little speed (but not much.) This lets me avoid ever
having to reschedule failed events.

:But in the case of totally threaded events, you have to create them,
:stock them in order to interrupt 
:them. 2 questions: is there a thread per possible event? is there a
:generic class eventThread which
:may contain any event? In this case, is there an accurate way of
:programing it?

Er... bad idea. You don't want your OS to choke on the threads; a lot of
Unix's will. Solaris and IRIX, for example...

:		   once again, is there an intelligent way of stocking
threads? I
:thing about a
:hashtable which value would be the thread, but what would be the key?
:Thanks in advance.

This, I can't answer.
--

"You? We can't take you," said the Dean, glaring at the Librarian.
"You don't know a thing about guerilla warfare." - Reaper Man,
Nathan F. Yospe  Registered Looney                   by Terry Pratchett
yospe at hawaii.edu   http://www2.hawaii.edu/~yospe           Meow