[
https://issues.apache.org/jira/browse/AMQ-6680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019778#comment-16019778
]
ASF subversion and git services commented on AMQ-6680:
------------------------------------------------------
Commit bf395fcdb3d63a3af48494cbec86734ed8867a90 in activemq's branch
refs/heads/activemq-5.14.x from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=bf395fc ]
https://issues.apache.org/jira/browse/AMQ-6680
Fix handling of incoming MQTT binary data over WS. The handler should
use the MQTTCodec to ensure that partial or packed frames are fully
processed
(cherry picked from commit e69367fbc329aa66a90e33a917b0d4ccd86c015e)
> MQTT over WebSocket doesn't work when WebSocket data frame contains partial
> or multiple MQTT control packets
> ------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-6680
> URL: https://issues.apache.org/jira/browse/AMQ-6680
> Project: ActiveMQ
> Issue Type: Bug
> Components: MQTT, Transport
> Affects Versions: 5.14.5
> Reporter: Marco Geri
> Priority: Critical
> Labels: mqtt, patch, websocket
> Fix For: 5.15.0, 5.14.6
>
> Attachments: MQTTSocket-patch.txt, MQTTWSConnection-patch.txt,
> MQTTWSPartialFrameConnection.java, MQTTWSPartialFrameTest.java
>
>
> I tried to use the MQTT.js library in a browser but it didn't connect to
> ActiveMQ using MQTT-WebSocket transport.
> Debugging MQTT.js and ActiveMQ I found that the
> org.apache.activemq.transport.ws.jetty9.MQTTSocket class (in activemq-http
> module) assumes that a single WebSocket data frame +always+ contains a single
> MQTT Control Packet.
> This is the cause of MQTT.js failure because MQTT.js makes several send over
> WebSocket for a single MQTT Control Packet (header, length etc).
> Accordingly to MQTT OASIS specification (
> http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718127
> ):
> ??A single WebSocket data frame can contain multiple or partial MQTT Control
> Packets. The receiver MUST NOT assume that MQTT Control Packets are aligned
> on WebSocket frame boundaries.??
> And RFC 6455 ( https://www.ietf.org/rfc/rfc6455.txt ):
> ??The WebSocket message does not necessarily correspond to a particular
> network layer framing, as a fragmented message may be coalesced or split by
> an intermediary.??
> So I think that ActiveMQ should be fixed to be compliant to the WebSocket and
> MQTT specifications.
> I attached the diff patch file for MQTTSocket which fixes the problem and a
> new activemq-http module MQTT-WebSocket unit test for this issue (the same of
> MQTTWSTransportTest but which splits MQTT Frame Packet in multiple WebSocket
> frames):
> MQTTWSPartialFrameConnection.java
> MQTTWSPartialFrameTest.java
> When writing the unit test I found also a bug in the class
> org.apache.activemq.transport.ws.MQTTWSConnection.java.
> All the occurrences of:
> {code:java}
> ByteSequence payload = wireFormat.marshal(command.encode());
> connection.getRemote().sendBytes(ByteBuffer.wrap(payload.data));
> {code}
>
> should be replaced with:
> {code:java}
> ByteSequence payload = wireFormat.marshal(command.encode());
> connection.getRemote().sendBytes(ByteBuffer.wrap(payload.data,
> payload.offset, payload.length));
> {code}
> That is because of the payload.data bytes array buffer in ByteSequenze is
> bigger than the real MQTT frame packed bytes size, so sending all the
> payload.data bytes array, ActiveMQ receives much more extra zero-extra bytes.
> With the current implementation, those extra zero-bytes are ignored and this
> makes wrongly passes the test (while it should fail because there are "extra
> bytes" which doesn't respect the MQTT protocol).
> I attached also the diff patch file for the MQTTWSConnection file.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
