If the protocol routes a COM_QUIT packet to the backend, it must not
generate a packet when it is shutting down. This could cause unexpected
write errors if the backend server managed to close the socket before the
write was done.
By deferring the closing of a DCB until the protocol tells that it's in a
stable state, we avoid closing the connection mid-authentication. This
makes sure that all connections have reached a stable state before they
are closed which in turn prevents the connections from counting towards
aborted connects (or failed authentications like it did with the old fix).
When a fake handshake response is generated for a connection that hasn't
received the server's handshake, the client's SHA1 would be used with a
static scramble. This, in theory, would weaken the authentication to some
extend so to completely prevent this, a null password is used. This
removes any possibility of the password being exposed.
The charset sent in the handshake is now done with the following
priorities:
* First Master server
* Last Slave server
* First Running server or Down server whose charset is known
The change is that server in the Down state to which we've successfully
connected to can also be used as the charset source. This, in addition
with an "empty" default charset, helps avoid the use of the default latin1
charset unless absolutely necessary.
The backend didn't expect AuthSwitchRequest packets in response to the
handshake response packets. This is allowed by the protocol and appears to
happen with at least MySQL 8.0.
If the client DCB of the session was passed into the function, it was
possible that the session pointer for it was already set to null. The
session pointer of an open DCB is never null but a client DCB's session
pointer can be null if accessed via the MXS_SESSION object.
By incrementing the counters when the session is created, we know that the
counter will always be decremented correctly. This does cause the listener
session to be counted as an actual session but this is already present in
the statistics calculations and is something we have to live with in 2.3
This change also makes it possible to overshoot the connection count
limitation as the session creation is delayed until authentication
fails. Both of these problems are fixed in 2.4.
This causes the connection failure to be counted as an authentication
failure instead of a connection error. The former never causes the host to
be blocked which effectively solves the problem for most cases. The only
case where this would not work is where the network buffer for a backend
DCB is full right after the connection is created.
The hangup and error handlers now have unique messages. Although the
behavior in the handlers is practically the same in both cases, the cause
of the error is not the same.
If a socket error is present, it is added to the error message. If an
error is present, it should clearly show the reason why the TCP socket was
closed.
The is_fake_event boolean helps distinguish fake events from real
ones. This makes figuring out the real source of hangup events easier.
The client count was incremented before authentication was complete, and
should be decremented if it fails. Otherwise service connection limit can
be easily reached.
If a query returned multiple resultsets and the connection was broken
between the resultsets, the backend would not know that parts of the
response were already sent. This is caused by the cyclic nature of the
state machine when multi-result responses are being processed.
To fix the problem, the result size is tracked to know how many bytes have
been sent to the client. This is a backport of the
MySQLProtocol::Result::size from 2.5(develop).
