ghostbust on login fix one, but more found

[James Cameron <quozl@us.netrek.org>]

Well, I found it was my fault, of course.  I've fixed on continuum the
problem that caused a disconnection by the server if the player does not
log in and choose a race within 30 seconds of connection receipt.  

Astute readers will have seen the CVS log.  Terribly simple.


Prelude: I have never seen ghostbust recovery work on the Vanilla server
in the past three or four years.  It always results in a KQUIT whydead,
with team selection boxes disabled.

Now, I have another problem I experience, and the sequence is as
follows;

a) client starts, logs in, gets ship, starts flying,
b) client suddenly reports;

	"Tried to write 5, 0xbffffae4, 12
	write: Transport endpoint is not connected
	gwrite failed."

c) client apparently issues a close() on the TCP connection, resulting
in the server reporting;

	F2: read() failed, Error 0
	F2: input() commences resurrection
	F2: start connect to gil-56k-163.tpgi.com.au:4023
	F2: user attempted to used old reserved.c

d) connection is fairly shortly accepted by the client, and the ship
explodes and the team selection boxes are greyed out due to KQUIT.  The
client's stdout/stderr shows;

	Waiting for connection (port 4058). 
	Got connection.
	Connection from server mage.real-time.com (0x5fd0ace)
	Yea!  We've been resurrected!
	RSA verification requested.
	OK, bye!


Now, a full log from the client side of this problem with udpDebug set
to 1 ...

# cow -h mage.real-time.com
Reading defaults file /root/.xtrekrc
Calling mage.real-time.com on port 2592.
Got connection.
***  socket 4087, player 0  ***
UDP: Local port is 4276
UDP: Bound to local port 4276 on fd 5
UDP: Sent request for UDP mode
UDP: Issuing recvfrom() call
UDP: LOCAL: addr=0x0, family=2, port=4276
UDP: timed out waiting for response
UDP: Sending TCP reset message
UDP: Received UDP reply 1
UDP: Got unsolicited SWITCH_UDP_OK; ignoring
UDP: Received UDP reply 0
UDP: Got SWITCH_TCP_OK while in TCP mode; ignoring
Receiving Short Packet Version 11
RSA verification requested.
Tried to write 5, 0xbffffae4, 12
write: Transport endpoint is not connected
UDP: LOCAL: addr=0x0, family=2, port=4276
gwrite failed.
Tried to write 5, 0xbffffae4, 12
write: Transport endpoint is not connected
UDP: LOCAL: addr=0x0, family=2, port=4276
gwrite failed.
Whoops!  We've been ghostbusted!
Pray for a miracle!
UDP: Closing UDP socket
Waiting for connection (port 4087). 
Got connection.
Connection from server mage.real-time.com (0x5fd0ace)
Yea!  We've been resurrected!
RSA verification requested.
OK, bye!

Now, "gwrite failed." only occurs in ping.c, in response to a ping
request, and it sets serverDead if gwrite() fails, forcing a close of
the TCP connection ... which then causes the server to start a
reconnection ... which then seems to work but fails on the RSA
re-verification.

So I'm guessing that the client is processing a ping request from the
server at the time that the UDP socket is being set up but it is not yet
fully set up, hence the "not connected."

Apart from reducing ping times at the server, can anyone suggest what is
going wrong here and how to fix it?  I see two problems;

1) the UDP negotiation fails and a ping gwrite() causes a ghostbust,
2) the ghostbust does not recover; RSA verification fails.


-- 
James Cameron                                      (quozl@us.netrek.org)

Linux, Firewalls, OpenVMS, 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.