On Tue, Jun 08, 2004 at 08:13:54PM +0200, E. Hietbrink wrote:
> My current understanding of ghostbust detection is that the server lets
> someone ghostbust if for a defined number of ticks no ping information
> is received. right? 

Yes, that's kinda how it works.  There's a counter that is moved by the
daemon, and reset by the per-client ntserv process.  Once the counter
hits the limit, the daemon clears the slot.

But that's the technique that is used to prevent ghost ships, it's the
server's ghost buster.

The term "ghostbust" is very ill-defined.  From the users' perspective,
the term has been used to describe simulation freeze, screen update lag,
loss of client window, loss of contact, console messages, and the babes

The server does have code in it to attempt to reconnect back to the
client, over TCP.  This only covers certain types of ghostbust causes,
and only when such a connection will be propogated through any

Half the job of the server's ghostbust logic is there to reduce the
utility of a forced death by terminating the client.  If the user kills
their client, we want them to die to a player ... we don't want them to
simply disappear off the galactic.

If we didn't want that feature, then as soon as the network connection
dies we could remove the ship from the game and clear down the slot.

Also, if they are carrying, or a starbase about to be ogged, we'd like
to give them another chance ... it's only fair.

The reconnect feature works like this;

- client opens a port and listens,
- client calls the server, makes connection, passes the listening port
- play ensues,
- network link broken by some temporary routing problem, endpoints
- server calls client on client's listening port,
- connection is re-established, further play ensues.

Therefore, it depends on two critical factors that are not very true

a) that the server is informed by ICMP or TCP RST that the connection
must close due to some network problem,

b) that the client is reachable by return connection from the server.

Without (a), the server won't initiate the process.

The situations it does not cover are;

- total IP packet loss between client and server, such as is caused by
  temporary internet route hop failures,

- total IP packet loss, such as is caused by dial-up user disconnection,

- reconnection of a consumer ADSL service with a new IP address.

> No what if you do the following: if someone logs on a second time, check
> if the old slot has above MIN_TICKS_GHOSTBUSTED (say 10?) failed ping
> stats (which is still *far* below the I think 60 ticks that are necessary
> to do a normal ghostbust), make the server ghostbust the old slot
> immediately.

That sounds appealing.  I'd be happy to give that a try; once I
understand the change and the impact.

> The next thing you can do is two things:
> 1) Give the now opened slot to the first player from the waitqueue, or:
> 2) Give the slot to the WQ32 player, thus potentially bypassing people
>    in the normal waitqueue.
> Personally I prefer option 2. If he actually ghostbusted, he'd like to
> get back in instead of joining at the end of the waitqueue.

I agree, option 2 is more appropriate; the user did not intend to loss
his connection.

But I don't want to make self immolation in third space easier.  ;-)

James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/

vanilla-devel mailing list
vanilla-devel at us.netrek.org