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

[Priyanki Vashi]

Hi ,

I am in the process using amqpc but in the mean time I thought to ask on my
queries.
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.

I will write back once I do my analysis.

Thank you again for writing back.

//P


On Tue, Aug 20, 2013 at 1:16 PM, Michael Klishin <mklishin at gopivotal.com>wrote:

> 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
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> 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/3a66fddd/attachment.htm>