Description:
I see here: https://dev.mysql.com/doc/internals/en/x-protocol-lifecycle-lifecycle.html#x-protocol-life... a description about the maximum message sizes.
It looks to me like this should be in a section on Capabilities exchange.
Even so it's not clear which side is the sender or receiver (client or server?) .
When I do a CapabilitiesGet on 5.7.15 I get no message.maxSendLength or message.maxReceiveLength capability values.
I only get tls, authentication.mechanisms, doc.formats, node_type, plugin.version and client.pwd_expire_ok.
So where do these values come from. What values should I assume for these settings as a minimum value that can be used? Knowing this avoids me sending larger messages and thus triggering a mistake and given the documentation here triggering a disconnection.
There is an X plugin server variable mysqlx_max_allowed_packet but this variable seems to refer for both incoming and outgoing packets so this seems more confusing.
Should I assume on connection a minimum value of say 1 MB, and then use something like CapabilityGet/CapabilitySet to attempt to set it to a different value?
Documentation is clear "If the server receives a message that is larger than the current Max Message Length, then it MUST close the connection.". Yet it looks like the client will get no notification of this issue which is unfortunate.
How to repeat:
read the docs and try to figure things out.
Suggested fix:
If such disconnections happen as indicated in the current documentation:
* please ensure that it's possible to log this type of issue.
* please add global P_S counters, and host_cache counters so this type of event can be tracked.
Adding extra CapabilitiesGet/CapabilitiesSet messages is going to increase the time needed to send a query to the server, yet not doing this will mean that there's a chance of breakage if a message is sent which is too large.
As with other things like:
* setting session heartbeat timers to prevent unexpected disconnections and handle them better
* verifying character set used by the server
This specific setting seems to be something that needs to be handled by both sides of the connection and in as an efficient manner as possible. Handling this post-authentication could be done but it might require a couple of extra exchanges of messages and in any case won't actually tell the server anything about the client.
It would be good to clarify things in the current documentation. I'm confused.
It would also be good to consider documenting initial states of the things mentioned here, which need to be agreed between client and server to avoid errors, and also to have a mechanism to exchange information about the other side so that following a completed authentication it's possible to safely change settings in a pipelined manner.
My suggestion here would be to extend the current protocol by adding an extra field to the authentication messages which would allow clients that understand this to get the information offered from the other side. It would then be possible to change settings that need adjusting in a pipelined fashion without introducing extra delays.
