[rabbitmq-discuss] Question on packing of Bytes into Ethernet Frame for AMQP protocol
mklishin at gopivotal.com
Tue Aug 20 12:16:08 BST 2013
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the rabbitmq-discuss