Quoting Jeffrey Nowakowski <jeffno at ccs.neu.edu>:

> > >   if (ping_allow_ghostbust && me->p_status == PALIVE && ping_ghostbust >
> > >
> > > Isn't it possible they bust in some other state?  Shouldn't that be
> > > "!= PFREE"?
> >
> > It would be redundant and in some cases harmful.
> >
> > Each of the other states already has explicit ghostbust behavior.
> > (they're all at either 3 or 6 minutes for outfit and login, respectively)
> > PALIVE is the only indeterminate length state that we care about
> > ghostbust in.
> 
> How would it be harmful?

Ok, I didn't think that through.  Yes, not getting any pings during
the other states should shorten the process.

> Consider that most people who bust get killed.

And that's generally where the GB code finally kicks in.  In the 3
minute POUTFIT window.

>  And what about observers?

They have their own problems, one of which is someone walking away
from the terminal.

> In short, I think we need robust ping-ghostbust code that handles all
> cases.

That's what this thread is for....

> Sending ping requests down TCP: Perhaps it would be better to
> ghostbust clients having TCP trouble, perhaps not.

I still have reservations.  That's why I want to try it out on one of
the servers.  I'm worried about false positives.

> So for now I say make ghostbust code robust, and think about sending
> ping via TCP later on.

Umm.... I'm trying to make it more robust by moving it to TCP.  I'm
trying to increase the odds of the GB code detecting a hosed link in
either direction.

Right now all we have is ping and refit/login timeouts.  And currently
ping is on the very forgiving UDP link.

The only other thing I can think of is switching GB code to threshold
on loss percentage or rtt.

> I guess I could modify a client to not send ping requests back.

That works too.  And you can synthesize data in the ping packet
response as well.


-------- this should be separate thread--------

> And while we're on the subject of pings, wouldn't it be useful to have
> a ping stat for the last minute?

Shorten the running average or have another field?  Currently its
lifetime average/std.dev. that's reported by '!'

Clients usually calculate their own ping stats and can print out
instantaneous pings.

But really, are ping stats really important?  There are only 2 cases
where I've seen ping stats being used.  The first is at the end of an
INL game report, and the 2nd is for offence scummers to find someone
to pick on.  We'll there's 3.  I use it to see how my network is
doing, but I use instantaneous pings for that, not the running
average.

--Carlos V.