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 image. 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 firewalling. 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 number, - play ensues, - network link broken by some temporary routing problem, endpoints close, - 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 nowadays; 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 https://mailman.real-time.com/mailman/listinfo/vanilla-devel