[
https://issues.apache.org/jira/browse/PROTON-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated PROTON-1786:
-------------------------------------
Description:
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 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.
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.
was:
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 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.
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 transfers 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.
> 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 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.
> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
