[
https://issues.apache.org/jira/browse/PROTON-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16393248#comment-16393248
]
Andrew Stitcher commented on PROTON-1786:
-----------------------------------------
One thing to be very clear about is the using the word "frame":
The 16k/64k "frames" are *TCP* frames - the sending client has limited control
over the size of the *TCP* frames - it largely controls the size of the *AMQP*
frames. The proton-c code will send a single *AMQP* frame in a single write
operation, whether the AMQP frames are sent individually or combined will
depend on the precise scheduling of the writes.
Another important point to note: The underlying MTU size (in other words the
"frame" size for the actual link-level networking) will often be much smaller
in any case - The ethernet MTU is 1500 bytes (jumbo frames would be 64k, but
are not used widely). If you use loopback then you will get an MTU of 64k
bytes, but this is not the value for _real_ networking.
> Multiframe transfer wire traffic patterns differ substantially
> --------------------------------------------------------------
>
> Key: PROTON-1786
> URL: https://issues.apache.org/jira/browse/PROTON-1786
> Project: Qpid Proton
> Issue Type: Task
> Reporter: Kim van der Riet
> Priority: Major
> Attachments: dispatch.multiframe.07.pcapng
>
>
> This is not a bug (although it could become one), but rather an observation
> of large message transfer patterns observed using Wireshark while running
> Qpid Interop Test's amqp_large_content_test.
> The test sends large messages through a broker (in this case, dispatch
> router) of size 1MB and 10MB.
> I hope to add other observable patterns from other clients and/or brokers if
> they are significant. If there is consensus that this is a potential large
> message transfer efficiency issue, then this Jira can be a placeholder for
> this issue.
> See the attached file for an example. In this test, the receiver is using
> TCP port 59806 and the sender port 59808. The router is using the standard
> AMQP port.
> h2. C++ client:
> The client in this case uses the Proton C++ API and is based on the
> SimpleSender.cpp example. To isolate the traffic from this client, use the
> following filter in Wireshark:
> {noformat}
> amqp.performative == transfer && tcp.srcport == 59808{noformat}
> It can be seen that although there is a large message being sent, the sender
> appears to be restricted to a single transfer of 16kB or a 64kB frame
> containing 4 transfers (very occasionally, 2, 3 or 5 transfers) - for example:
> {noformat}
> 35 1.972620 ::1 ::1 AMQP 16470 transfer
> 1177 2.032878 ::1 ::1 AMQP 65550 transfer transfer
> transfer transfer
> {noformat}
> h2. Dispatch Router:
> This uses Proton through its native C interface. To isolate the traffic from
> the router to the receiver, use the following Wireshark filter:
> {noformat}
> amqp.performative == transfer && tcp.dstport == 59806{noformat}
> The traffic for this broker looks very different. Each frame contains only a
> single transfer, and the size of the transfers differ widely, from 196 bytes
> to the full 64kB max. I am assuming that the router is sending on message
> content it has received as soon as it becomes available no matter the size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
