Have receivers enforce max-message-size if configured

[herfort]

Hi,
I tried to use the property MaxMessageSize. On my set up the property is bigger on the sender side as on the receiver side and I send message that is bigger as both properties.
I would expect that the sender checks the own and the RemoteMaxMessageSize and the receiver throws error if the message is bigger than MaxMessageSize.
See attached file:
SetMaxMessageSizeTest.java.txt

[gemmellr]

The setter/accessors only convey/access information to/from the remote peer in the link attach, there is currently no enforcement by the library itself, which like proton-j (and -c) itself leaves it to the using application code to handle and react to.

In hindsight, given it is actually the fully encoded message data which that size value governs, and not of just e.g the string body used in this case, it was a mistake exposing the setters/getters in vertx-proton without also considering that since the encoded message isn't directly seen by the using application code there (assuming it doesn't encode it itself just to check it). Handling it internally on the receiving side the way the spec indicates would be a little awkward. Need to think on how to address that.

[sophokles73]

I agree with your assessment, @gemmellr, that it is hard for the application layer to determine the total message size based on payload (and maybe headers). This should be left to the framework layer.
FMPOV this should be handled by both, sending as well as receiving, sides of the link. The sending side should refuse sending a message whose wire encoding is larger than the negotiated value, whereas the receiving side should refuse the reception of such messages and should be entitled to close the link with a corresponding error code (this should probably be configurable).

[sophokles73]

@gemmellr

Handling it internally on the receiving side the way the spec indicates would be a little awkward. Need to think on how to address that.

My understanding of both max-frame-size as well as max-message-size is that these properties can be used to implement a safeguard on the receiver side to prevent a sender from flooding the receiver with frames that would eat up the receiver's memory. Based on that assumption I think that the receiver side will have to enforce both property values in order to provide this safeguard. If this is deferred to the application layer (on the receiver side) then problem will already have occurred way before the receiving application first sees the incoming message. If I am not mistaken then proton-j already enforces the max-frame-size on the receiving end of a link but it doesn't limit the inbound message buffer based on the max-message-size, does it?

[sophokles73]

@gemmellr We are running into this problem again. Any thoughts regarding if and how to fix this at the vertx-proton and/or proton-j layer?
FMPOV this needs to be fixed at the proton-j layer as that is where the message is being assembled from the (multiple) transfer frames, right?

[sophokles73]

@gemmellr After having taken a closer look at the vertx-proton code, it seems that multi-transfer messages are being assembled at the vertx-proton layer. I have created a PR which should prevent receivers from accepting transfers that would result in exceeding the max-message-size.

[gemmellr]

Resolved via #116, pushed to master in 6955463 and backported to 3.9 in 4090c6f.