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

[Michael Klishin]

Priyanki Vashi:

> 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 ?

Setting TCP_NODELAY on a socket disables Nagle's algorithm. See
http://boundary.com/blog/2012/05/02/know-a-delay-nagles-algorithm-and-you/
and http://tools.ietf.org/html/rfc896.

Clients simply write data to a socket and are not aware of Ethernet framing. 

> 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 happening. 

"aggregation in a buffer" basically means that when you need to write 3 frames like this

[basic.publish frame] [content header frame] [message payload frame]

you serialize and concatenate them all in a buffer (or similar) and call socket.write
(or similar) once instead of 3 times. This *may* help achieve the kind of framing you want but there are
no guarantees and clients do not control that, the OS does.

> 
> 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.

I will assume this discussion is a continuation to your earlier emails about trying to saturate
a link with Pika and RabbitMQ.

Have you tried using MulticastMain, amqpc or a custom Java program after all to see
if it's any different? With the Java client, it is possible to tweak TCP_NODELAY
setting and see if it produces any results.

Also, if your link is not saturated, trying to pack multiple TCP segments
into a single Ethernet frame won't make it saturated.
--
MK

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130820/4e16e981/attachment.pgp>