[ 
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 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.

  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 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.


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to