- Subject: Re: What do you want when you ghostbust?
- From: James Cameron <cameron@stl.dec.com>
- Date: Mon, 22 Feb 1999 10:31:05 +1100
- Apparently-To: <cameron@ogg.stl.dec.com>
- Newsgroups: rec.games.netrek
- Organization: Netrek Vanilla Server Maintainer
- References: <7aeu2f$keh$1@msunews.cl.msu.edu> <36CB5F30.733DD8B9@openface.ca> <36CBABCA.2B7686CC@stl.dec.com> <36cd05eb.12819364@news.well.com>
- Sender: cameron
Okay, having reviewed what people have said about this so far, I propose
to change the server handling of the situation as follows;
1) pings will continue to be sent over UDP,
2) pings will continue to be received over UDP,
3) a loss of more than 75% of pings over a sample period will trigger a
ping-loss ghostbust (percentage and sample period to be configurable),
4) a ping-loss ghostbust will nuke the player, FREE THE SLOT, and
disconnect the client totally, with no attempt to restore service,
5) a failure of the TCP connection will cause a "tcp ghostbust",
6) a tcp ghostbust will allow continued play over UDP, but will initiate
a connection attempt back to the client, which will timeout after one
minute.
7) on callback failure, the total nuke option (4) above will be taken.
--
A bit more background on what network events I think we need to cope
with ... I'm sure I've written this up before, but I can't remember
where.
In what ways does a Netrek network connection fail, and what sort of
frequency of occurrence is involved? A good look at server logs may
help me find some of this.
There are two "connections", one over TCP and one over UDP.
The UDP connection fails in one of two ways ... (a) a slow increase in
packet drops, or (b) a total loss of packets. Both of these would be
handled by the ping-loss ghostbust. If we can't get UDP packets
through, chances are TCP won't work either. However we need to more
correctly handle an attempt to switch to UDP when the client is behind a
TCP only firewall ... currently it works badly.
The TCP connection fails in lots of interesting ways ...
(a) connection reset by peer, [ECONNRESET]
- another host boots nearby with identical IP address,
- client or server host reboots,
- connection was closed and another packet was received,
(b) connection closure, [read() returns zero]
- server process termination,
- client process termination,
(c) host unreachable, [?]
- router returns ICMP unreachable message to client or server,
These would be handled by a tcp ghostbust.
Discussion welcome.
--
James Cameron (cameron@stl.dec.com)
OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH,
COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers,
Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control,
Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband.
"Specialisation is for insects." -- Robert Heinlein.