<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
good evening;<div><br><div><div>On 2010-02-17, at 23:06 , Matthias Radestock wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">James,</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">james anderson wrote:</div> <blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the transcript did not indicate that there was any reframing.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the two frames with non-zero length were forwarded as published.</div> </blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">That just means the re-framing in that case was sub-optimal - the broker only dropped the zero length frame but left the others unchanged. What version of rabbitmq are you running? In 1.7.2 the re-framing is more aggressive.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> <blockquote type="cite"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">That is something a broker is permitted to do and in some cases<span class="Apple-converted-space"> </span>even has to do since the negotiated max frame size on the publisher<span class="Apple-converted-space"> </span>connection and consumer connection may be different.</div> </blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">if that were to apply.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">and where a writer and a reader agree on a frame size?</div> </blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Even if the publisher and consumer connection happen to have the same negotiated frame size, the server is still entitled to re-frame the content.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> <blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">anyway, it seems quite peculiar for a broker to muck with the<span class="Apple-converted-space"> </span>clients' data without cause.</div> </blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">You are conflating layers here, which admittedly aren't particularly well-defined in the AMQP specs. Framing is a transport-level concern; it does not appear at the application level. Think of the framing as the same kind of thing your tcp stack does when deciding how to split up a data stream into packets.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Now, atm AMQP only defines one transport, but that will change. In fact RabbitMQ already exposes AMQP over other transports like HTTP and SMTP, and we have gateways to STOMP, etc. Most of these have no notion of framing.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> <blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">is there any way to turn it off?</div> </blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Not without changing the code. If you want to experiment with this, the place to look is rabbit_binary_generator:build_content_frames, iirc.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#0000DD"><br></font></font></div></blockquote><br></div><div>ok. if there were any other way to do this without incurring unnecessary overhead, i'd not be so vocal.</div><div>problem is, as you note above, the layers are less than clear, and, in fact all thrown into the clients lap to disambiguate. in the process of which, i had gathered the following from the specifications.</div><div><br></div><div>i had read the passages at the bottom of amqp0-9-1.pdf/page 35 to imply that, if frames are strictly sequential, they would also continue to exist. frames sent as 1,2,3 and arriving as 1,3 don't fall in my classification of a strict order. it is difficult to think about a strict ordering between sets with - as you describe, disjoint constituents. if the intent is to specify an order for the content of the body frames, the specification could be rephrased to say that.</div><div><br></div><div>the next paragraph on that page implied that there might be an alternative to using a zero-length frame to carry early termination information, but i could not make out any command which could be sent proactively to actually have the described effect without additional disruption. what kind of termination was this passage intended to imply?</div><div><br></div><div>i had read the last paragraph of 3.1.1 on page 26 to limit, if not preclude, the actions which you describe. yes, there is a possible conflict between that paragraph and the passage at the close of 4.2.6.2 on page 36, but the "MUST NOT"s in the earlier passage are neither lightweight nor contingent stipulations, and, as demonstrated, the practice most certainly removes information.</div><div><br></div><div>in any case, thank you for the pointer.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></body></html>