[rabbitmq-discuss] a common-lisp amqp client

[james anderson]

good evening;

On 2010-02-17, at 23:06 , Matthias Radestock wrote:

> James,
>
> james anderson wrote:
>> the transcript did not indicate that there was any reframing.
>> the two frames with non-zero length were forwarded as published.
>
> 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.
>
>>> That is something a broker is permitted to do and in some cases   
>>> even has to do since the negotiated max frame size on the  
>>> publisher  connection and consumer connection may be different.
>> if that were to apply.
>> and where a writer and a reader agree on a frame size?
>
> 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.
>
>> anyway, it seems quite peculiar for a broker to muck with the   
>> clients' data without cause.
>
> 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.
>
> 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.
>
>> is there any way to turn it off?
>
> Not without changing the code. If you want to experiment with this,  
> the place to look is rabbit_binary_generator:build_content_frames,  
> iirc.
>

ok. if there were any other way to do this without incurring  
unnecessary overhead, i'd not be so vocal.
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.

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.

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?

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.

in any case, thank you for the pointer.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100218/f804393d/attachment.htm