Hi Simon,
On 8/20/21 10:39 AM, Simon Riggs wrote:
>> Yeah, but it is a change to the protocol which means that the client
>> drivers and middleware ecosystem needs to be updated to support that
>> message.
>
> No, because FE messages don't need to be handled by the client, they
> just send them.
Yes, but the middleware need to parse them in order to send a response.
> It is the server that needs to be updated to
> understand that these messages might be received and to ignore them,
> which is simple enough.
>
> If a client doesn't know about a message it COULD send, but doesn't,
> then there is no update required.
>
Agreed.
>> So, if the message was added to the protocol we could add another
>> message with the response to the request and make the protocol stricter, say
>>
>> FE/M
>> Int32 - Length
>> Int16 - Request type (0 == Query capability, 1 == Execute capability)
>> Int32 - Capability type (0 == Failover, 1 == ..., ...)
>
> This much detail is optional. It is up to the middleware to define if
> it supports capability requests, or how it handles requests that it
> cannot satisfy.
>
> I'm trying to come up with something generic that people can use for
> decades to come, not restrict their choices to a very small subset
> based upon our current vision.
>
>> BE/?
>> Int32 - Length
>> Int32 - Capability type
>> Byte - Support (0 == No, 1 == Yes)
>> Byten - Additional information
>
> If we add a new message from BE, then yes, we need to modify all
> drivers, which would be an immediate fail for this proposal.
>
> The message replies you foresee are optional; they are not required by
> all middleware.
>
> I've already suggested you use NoticeResponse, which is already
> defined to ignore unknown field types, so is suitable and extensible.
> We could add a new field type of 'm' to represent a message sent from
> middleware to the client.
>
When doing the PoC just keep in mind that middleware acting on a 'M'
message on a user authenticated connection could lead to a DoS attack.
Best regards,
Jesper
