[ 
https://issues.apache.org/jira/browse/QPID-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14952808#comment-14952808
 ] 

Rob Godfrey commented on QPID-6784:
-----------------------------------

It depends on how you parse "max frame size"  ... It is possible to parse that 
as "the maximum value the size field of the frame may take"...  Certainly there 
was always confusion about whether the frame end octet was included.

I think that the only viable approach for the code from now on is to be 
lax(ish) in accepting frames that are max frame size + 8 bytes, while only 
sending frames where the total size including 7 octet header and 1 octet frame 
end marker does not exceed the agreed max frame size.

Anything else will lead to interop issues with any client which took a 
different interpretation (including our own client by the sounds of it).

> [Java Broker, Java Client] Client sends too large frames and broker does 
> wrong frame size validation on 0-9
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-6784
>                 URL: https://issues.apache.org/jira/browse/QPID-6784
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker, Java Client
>    Affects Versions: 0.17, 0.32
>            Reporter: Lorenz Quack
>            Priority: Blocker
>
> The Client does not include the frame attributes (except for 1 byte) in its 
> calculation of the AMQP Frame size thus creating frames which are 7 bytes too 
> large. This happens in 
> {{org.apache.qpid.client.BasicMessageProducer_0_8#calculateContentBodyFrameCount}}
>  and maybe other places.
> The broker on the other end does an incorrect validation (in 
> {{AMQDecoder#decodable}} at least) where it does not take any of the 
> attributes into account thus accepting too large frames.
> Besides not being compliant with the spec this causes problems in 
> {{NonBlockingConnectionPlainDelegate#processData}} where the frame does not 
> fit into a single networkBuffer.
> I did not investigate other protocol versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to