CORBA, RMI, threads

[s001gmu at nova.wright.edu]

On Mon, 26 Jan 1998, Marc Eyrignoux wrote:
>
> > Speaking of which, someone (Chris L, I think) once posted several CORBA

attribution?

> > :* 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.)
> May I know how the code has to look like?

The major issue in dealing with a game clock that runs faster than real
time is adjusting in-game delays to the new scale.. IE: if 3 rl minutes ==
1 mud hour, and you have a spell that lasts 1 hour, it has to wear off in
3 minutes real time.  An easy way to do this might be to write a simple
function that converts a real time value to game time... something like:

time_struct real_to_game_time(time_struct &rt);

and use it like so:

time_struct t;
...
t.hours = 1;
...
event_diver.schedule(new event(real_to_game_time(t)));

or some such.

For time events, (IE: rising of the moon, setting of the sun, etc), you
can just use an event chain with delays set appropriately.

> > 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 the case of a Hashtable, how can you store 2 identical monsters?
> I think that 2 orks have the same server-side models. Is the difference
> made at the client-side refernces? (I take the case where 2 orks are at
> the same location, have the same number of lifepoints...)

I would us something other than location, lifepoints, or creature type as
the primary key.  typically, a unique object id assigned at creation of
the object.  Counters work well, unless you have a high turnover rate, at
which time you'd need to adopt some recycling method.

more generally, there are lots of methods for dealing with hash-tale
collisions.  as long as collisions should be infrequent (IE: you have a
sufficiently large hash table), you can get away with the entries in the
table being a linked list of all colliding entries.  with lengths of one
or two in the list, the cost is minimal.

[in response to one thread / connection, I presume]
> > 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...
> As my teachers give me unlimited access to every resources I want, my
                         
must be nice... ;)

> server will run alone on a Linux PC.

Linux thread libs are the same libs as for Unix systems... just compiled
under linux.  They suffer from the maximum thread count imposed on Unix
systems too.  I don't recall exactly why there is a max number, but it has
to do with some system defined limit that the thread libs can't get
around.  so far.  AFAIK, one thread using a select() statement should work
well to manage all the input streams from the sockets.  DIKU, all it's
faults aside, does not seem to have any undue lag resulting from it's
method of input management, and it uses select().

-Greg