View Issue Details

IDProjectCategoryView StatusLast Update
0000447LDMud 3.5Implementationpublic2012-07-12 21:10
ReporterlarsAssigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Summary0000447: Heartbeat interval should be configurable
DescriptionMudOS for example allows that.
TagsNo tags attached.

Activities

zesstra

2008-07-01 03:28

administrator   ~0000643

I assume, the intention is to allow individual HB intervals for objects, as the global interval is already configurable? Might then be something for 3.5 if we have to change the HB processing in the backend cycle, maybe to something similar to the callout processing.

zesstra

2012-06-09 10:04

administrator   ~0002137

On the other hand: maybe it is sufficient to just use callouts for the objects with different timings? I am not sure if benefit is worth re-working the HB mechanism...?

lars

2012-06-10 01:19

reporter   ~0002138

Opinion from the peanut gallery (yes, it exists): IIRC, the difference between heartbeats and call_outs is that heartbeats are executed only to fill up current polling interval. Any heartbeat not fitting into the current polling interval is pushed with priority into the next one; allowing the game to degrade gracefully under load. call_outs on the other hand are executed at their trigger time, no matter how long it takes.

To truly replace heartbeats with call_outs, you'd have to implement a 'BEST_EFFORT_TIMING' kind of flag.

(Again, I might be completely wrong - I'm writing from memory here. And if that is indeed the case, let me know, and I'll shut up :) )

invisible

2012-06-10 11:52

reporter   ~0002139

Depends on how much work it would be. If it's easily done, configurable
heartbeat might be a nice feature. OTOH the time may better be invested into
a more generic, HB-independent timer/event-system.

I agree it is feasible to solve this with call_outs though (I did it for
RoleMUD's dynamic attribute system).

@lars: if per-object HB-rate exists I guess most people would use it under the assumption of a somewhat 'reliable' interval (if HB is generated on a best-effort basis, and might or might not occur at the desired interval, why make it configurable at all?)

lars

2012-06-16 22:24

reporter   ~0002140

Making heart_beat time intervals configurable would give you best of both worlds: one the one hand, call_outs at guaranteed configurable times, and on the other hand, heartbeats at load-aware best-effort configurable times (plus, heartbeats automatically reoccur, call_outs don't).

In theory both could be unified into the same efun, but I'd make that step 2.

Gnomi

2012-07-12 21:10

manager   ~0002146

This feature can be implemented rather easily, because there is an object list sorted after their individual call schedules. (When using asynchronous heartbeats.) Two changes are required: Instead of storing the time of the last hb execution, store the time of the scheduled call. And instead of adding new objects to the end of the list insert it at the appropriate place for its schedule. (Bonus: When changing the interval, move the object to its new place.)

Issue History

Date Modified Username Field Change
2006-03-01 14:17 lars New Issue
2008-07-01 03:28 zesstra Note Added: 0000643
2008-07-16 16:27 zesstra Project LDMud => LDMud 3.5
2012-06-09 10:04 zesstra Note Added: 0002137
2012-06-09 10:04 zesstra Status new => feedback
2012-06-10 01:19 lars Note Added: 0002138
2012-06-10 01:19 lars Status feedback => new
2012-06-10 11:52 invisible Note Added: 0002139
2012-06-16 22:24 lars Note Added: 0002140
2012-07-12 21:10 Gnomi Note Added: 0002146