<div dir="ltr">Hi ,<div><br></div><div>I am in the process using amqpc but in the mean time I thought to ask on my queries.</div><div>I did not particularly thought of just saturating the link but after checking most of my traces I found no packing so just asked about it.</div>
<div><br></div><div>I will write back once I do my analysis.�</div><div><br></div><div>Thank you again for writing back.</div><div><br></div><div>//P</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 20, 2013 at 1:16 PM, Michael Klishin <span dir="ltr"><<a href="mailto:mklishin@gopivotal.com" target="_blank">mklishin@gopivotal.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Priyanki Vashi:<br>
<div class="im"><br>
> 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 ?<br>
<br>
</div>Setting TCP_NODELAY on a socket disables Nagle's algorithm. See<br>
<a href="http://boundary.com/blog/2012/05/02/know-a-delay-nagles-algorithm-and-you/" target="_blank">http://boundary.com/blog/2012/05/02/know-a-delay-nagles-algorithm-and-you/</a><br>
and <a href="http://tools.ietf.org/html/rfc896" target="_blank">http://tools.ietf.org/html/rfc896</a>.<br>
<br>
Clients simply write data to a socket and are not aware of Ethernet framing.<br>
<div class="im"><br>
> 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 ?<br>
><br>
> My MTU size is set to 1500 bytes but I don't see that such agreegation happening.<br>
<br>
</div>"aggregation in a buffer" basically means that when you need to write 3 frames like this<br>
<br>
[basic.publish frame] [content header frame] [message payload frame]<br>
<br>
you serialize and concatenate them all in a buffer (or similar) and call socket.write<br>
(or similar) once instead of 3 times. This *may* help achieve the kind of framing you want but there are<br>
no guarantees and clients do not control that, the OS does.<br>
<div class="im"><br>
><br>
> 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)<br>
> Is this the expected behavior of rabbit server ?<br>
> 4) But I always see only individual frames (of individual methods) from client to server.<br>
<br>
</div>I will assume this discussion is a continuation to your earlier emails about trying to saturate<br>
a link with Pika and RabbitMQ.<br>
<br>
Have you tried using MulticastMain, amqpc or a custom Java program after all to see<br>
if it's any different? With the Java client, it is possible to tweak TCP_NODELAY<br>
setting and see if it produces any results.<br>
<br>
Also, if your link is not saturated, trying to pack multiple TCP segments<br>
into a single Ethernet frame won't make it saturated.<br>
--<br>
MK<br>
<br>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br></div>