[MUD-Dev] Event handling (was: request for comments)

[Vadim Tkachenko]

s001gmu at nova.wright.edu wrote:
> 
> On Fri, 9 Jan 1998, Vadim Tkachenko wrote:
> 
> > s001gmu at nova.wright.edu wrote:
> > >
> > > On Thu, 8 Jan 1998, Vadim Tkachenko wrote:
> > >
> 
> <original question dropped>
> 
> >
> > [skipped]
> >
> > > > - One thread per connection listener (it's possible to install more than
> > > > one protocol adaptor, and therefore, connection listener)
> > > > - One thread per incoming connection
> > >
> > > so... at least 2 threads per user?
> >
> > Of course not - connection listener thread just accept()s the incoming
> > connections and
> > spawns the controlling thread
> 
> ahhh... gotcha.   I believe I am heading towards a model like this, though
> if I understand what you mean by protocol adapter, I am only planning on
> using one.

As I hate to recreate the same things, I eventually came to the concept
of 'protocol adaptor' as entity which gets the same data on the client
end pushes it to the server, and response all the way back (may be also
symmetrical, client may become server and vice versa) regardless of the
implementation. The only method which generic protocol should implement,
as Java interface, is

Object processRequest( Object rq ) throws Throwable;

, period. 

Currently there are:

- SocketProtocolAdaptor
- ServletProtocolAdaptor (obviously, unidirectional)
- (next to-be) CorbaProtocolAdaptor or RmiProtocolAdaptor, as my
business will influence.

> > - You keep at least minSpare spare request handlers, just in case, so
> > first minSpare incoming
> > requests arriving simultaneously will be served really fast.
> > - After some requests are finished, you keep at most maxSpare spare
> > request handlers, terminating anything extra (variation: after they
> > expire by themselves).
> 
> I figgured it was something like that.  True, that does seem to localize
> most of the thread-creation cost to boot-time.  Especially if you pick a
> decent range and initial number of threads.

Not quite, the total number of threads is changing all the time. Also, I
don't know about PThreads, but my experience with threads in OS/2 and
Java shows that call like createThread() usually returns before first
operator in that thread is executed.

> > Also, there are two types of requests worth mentioning:
> >
> > - packet request
> > - channel request
> 
> have to read up a bit, but I think I gather the gist of the points.. :)

Packet switching is TCP/IP, channel switching is obsolete telephone
exchangers

> > > but when I tell my
> > > character to "cast fireball at bubba", it becomes trivial to implement the
> > > delay inherent to the action by scheduling the event to go off 3 ticks
> > > down the road.
> >
> > By the way, this is exactly the point where extra threads appear in my
> > model. Every time-based action is asynchronously handled by the separate
> > thread, which allows to handle effects like spell backfires,
> > concentration, partial force release, accumulation rules, side effects
> > with extreme ease.
> 
> *nod*  I think I see where you are going.. the event, "cast spell" is
> plunked on the queue, and handled as quickly as possible.  Handling means
> calling a method which may "sleep" for a while, to take care of the delay.
> If it's interrupted while sleeping (someone interrupts bubba casting the
> spell), you have some sort of 'interuppted' method which handles the
> results of someone busting up bubba's concentration.  Right?

You can put it this way, too.

> That being the case, I'd still prefer to let events spend their delay time
> on the queue, instead of in a thread.

Thus wasting more CPU cycles on event scheduling.

> > Just an idea: lycanthrops, whose properties change with a phase of the
> > moon[s]
> 
> mmm.. I dunno that that is really a valid concern... I am leaning more and
> more towards JC's Spoof/Watcher model, which allows for such things
> nicely (definately planning on spoofs.. still thinking about watchers..
> dunno if my design goals necessarily coincide with the ones you chose that
> lead to spoofs/watchers, JC).  W/O using watchers (to watch the phase of
> the moon), I would schedule an event to go off at the beginning of the
> time the lycanthrop should morph, to trigger the morph, and then one to go
> off at the end of the time, to morph the poor bastich back.  No real
> worries about multiple events targeting the same data at the same time, as
> the events would occure once a month!  :)

I missed the concept of spoof/watcher, but if I take your meaning, you
can say that there's really no need to keep the threads running all the
time, 'cause there are certain actions/events which require
consideration of, for example, phase of the moon.

But once again, I emphasize, the difference is between treating
everything as EVENTS and PROCESSES.

> <handling events in list at termination/reboot>
> 
>   <two options, handle at termination or save and handle at startup>
> 
>  <my response of "mm.. maybe best to just let them die at termination>
> 
> >
> > Bad thing for me, because I'll have a lot of asynchronous events for
> > each object - for example, I'm going to implement the algorithm of
> > applying the temporary changes, illustrated by example:
> >
> > - You get hit by the poisoned sword.
> > - Consequently, there are two state changes: your limb gets a wound
> > (let's make it a light one), and you get poisoned.
> > - Wound is going to heal by itself, slowly (asynchronous process, which,
> > in according to the abovementioned flexibility, may have variable rate
> > depending on your state, weather, nutrition etc.)
> > - Poison is going to continue to affect you (asynchronous process), once
> > again, with variable rate as above.
> 
> mmm.. so you handle all state changes, and resulting moves back towards
> the norm as an event-process?  (IE: each wound is treated as an event?)

No, as a process - even in case when, say, your limb got cut off -
there's an open wound, which may not kill you immediately, but,
nevertheless, real soon unless you move your ...

> I think I'd treat the situation as a whole, rather than each individual
> wound.  IE: there is one event logged (for each <thing> that is not at
> it's normal state) which takes care of moving that thing back towards it's
> normal state.  If I get a wound, it schedules the normalizer to go off
> whenever, to up my hp a bit and reschedule another normalizer event.

As an increment? Probably.

>  If I
> get another wound, the wound event wouldn't schedule a new normalizer,
> 'cause one is already pending for the previous wound.  how the normalizer
> is scheduled can be as complicated as you like.

Yes, modifiers of the same type are additive - there are few parameters:

- degradation factor
- damage factor
- cumulative factor
- timeslice  

Once again, it's all described on the project pages :-)

> -Greg

--
Still alive and smile stays on,
Vadim Tkachenko <VadimT at 4CS.Com>
--
UNIX _is_ user friendly, he's just very picky about who his friends are