[rabbitmq-discuss] Question on packing of Bytes into Ethernet Frame for AMQP protocol

Priyanki Vashi vashi.priyanki at gmail.com
Tue Aug 20 11:56:30 BST 2013

Hi All ,

Thank you for your replies.

I still have following question on them.
It might be basic but I want to thoroughly understand what is the
difference between pika-client and other client (like .net or erlang, Java)
when it comes to such packing.

1) As I learnt now Pika, Erlang , Java and .net clients all set TCP_NODELAY
flag, which means that there is no intelligence within this clients to pack
bytes together to make almost equal to MTU. Is it correct ?

2) And then in case of some clients like Erlang, Java and .net, the
aggregation happens in buffer prior to hitting the O/S network layer so
then why it's not the behaviour in pika-clients ?

My MTU size is set to 1500 bytes but I don't see that such agreegation

3) I can see that server does such packing while sending to consumer but
still it does not fill till MTU limit. In my case I see it's just fill
maximum of 204 bytes from server to consumer ( showing basic-deliver,
content-body and content-header)
Is this the expected behavior of rabbit server ?

4) But I always see only individual frames (of individual methods) from
client to server.

Best Regards,

On Mon, Aug 19, 2013 at 5:58 PM, Matthias Radestock
<matthias at rabbitmq.com>wrote:

> On 19/08/13 16:54, Laing, Michael wrote:
>> pika sets TCP_NODELAY and does not provide an option to change it. Hence
>> you may have small packets by design.
> The server and the clients I mentioned set TCP_NODELAY too; the
> aggregation happens in buffers prior to hitting the O/S network layer.
> Matthias.
> ______________________________**_________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130820/334674e0/attachment.htm>

More information about the rabbitmq-discuss mailing list