On 11.11.22 23:28, Jacob Champion wrote:
Consider the case where the server sends a
NegotiateProtocolVersion with a reasonable length, but then runs over
its own message (either by sending an unterminated string as one of the
extension names, or by sending a huge extension number). When I test
that against a client on my machine, it churns CPU and memory waiting
for the end of a message that will never come, even though it had
already decided that the maximum length of the message should have been
less than 2K.
Put another way, why do we loop around and poll for more data when we
hit the end of the connection buffer, if we've already checked at this
point that we should have the entire message buffered locally?
Isn't that the same behavior for other message types? I don't see
anything in the handling of the early 'E' and 'R' messages that would
handle this. If we want to address this, maybe this should be handled
in the polling loop before we pass off the input buffer to the
per-message-type handlers.
