Re: [mqtt] MQTT Connect Packet Format - extra 2 bytes?

[Nicholas O'Leary]

Hi Niall,

as you note, the Client ID is a UTF-encoded string in the payload. As
per section 2.5 of the spec
(http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#utf-8),
this means the string is written as two bytes to indicate the length
of the string, followed by the bytes of the string itself.

Does that clear it up for you?

Cheers,
Nick


On 7 February 2013 16:03, feabhas <niall....@gmail.com> wrote:
> I know there is going to be an easy answer to this. Some time ago I wrote a
> simple MQTT client for QoS0 pub/sub in C, really to get a handle on the
> protocol.
> I've come back to it after many months away (work getting in the way) and
> I'm puzzled by something. I'm currently reimplementing in in "pure" Python
> (using socket and bytearray).
> The CONNECT request is (assuming no Will message):
> Fixed header - 2 bytes
> Variable header - 12 bytes
> Payload - Client ID UTF-encoded string.
> But looking at my code I have the variable headers as:
> // variable header
> uint8_t var_header[] = {
> 0, // MSB(strlen(PROTOCOL_NAME)) but 0 as messages must be < 127
> strlen(PROTOCOL_NAME), // LSB(strlen(PROTOCOL_NAME)) is
> redundant
> 'M','Q','I','s','d','p',
> PROTOCOL_VERSION,
> CLEAN_SESSION,
> MSB(KEEPALIVE),
> LSB(KEEPALIVE),
> 0, // MSB(strlen(broker->clientid)) but doesn't work for > 127
> strlen(broker->clientid) // LSB(strlen(broker->clientid))
> };
> which has 14-bytes, as I have an extra 2 bytes on the end for the length of
> the client ID, before the Client ID string.
> I'm currently testing with mosquito and if I take those two bytes out it
> fails to connect, but I can't see in the Protocol Spec where the requirement
> for these extra two bytes is stated?
> Also, looking back at my original protocol analysis, I can see in the
> wireshark capture the same two bytes (this not based on my code):
> Frame 4: 89 bytes on wire (712 bits), 89 bytes captured (712 bits)
> Null/Loopback
> Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1
> (127.0.0.1)
> Transmission Control Protocol, Src Port: 61547 (61547), Dst Port: ibm-mqisdp
> (1883), Seq: 1, Ack: 1, Len: 33
> Data (33 bytes)
>
> 0000 12 1f 00 06 4d 51 49 73 64 70 03 02 00 14 00 11 ....MQIsdp......
> 0010 73 74 64 6f 75 74 2d 73 75 62 73 63 72 69 62 65 stdout-subscribe
> 0020 72 r
> Data: 121f00064d51497364700302001400117374646f75742d73...
> [Length: 33]
>
> Please can someone put me out of my misery???
>
> Thanks,
>
> Niall.
>
>
> --
> --
> To learn more about MQTT please visit http://mqtt.org
>
> To post to this group, send email to mq...@googlegroups.com
> To unsubscribe from this group, send email to
> mqtt+uns...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/mqtt
>
> ---
> You received this message because you are subscribed to the Google Groups
> "MQ Telemetry Transport" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mqtt+uns...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Roger Light]

Hi Niall,

> which has 14-bytes, as I have an extra 2 bytes on the end for the length of
> the client ID, before the Client ID string.
> I'm currently testing with mosquito and if I take those two bytes out it
> fails to connect, but I can't see in the Protocol Spec where the requirement
> for these extra two bytes is stated?

As you say, the extra two bytes are for the length of the client id
string. Section 3.1 of the spec, under Client Identifier says: "The
first UTF-encoded string." If you see in section 2.5, MQTT and UTF-8,
you'll see that the spec assigns a special meaning to the phrase
"UTF-encoded string", which is a string using UTF-8 encoding that has
two bytes at the start of the string to indicate its length. It's not
immediately obvious that is what "UTF-encoded string" means.

The connection

Cheers,

Roger

[feabhas]

Thanks for pointing that out, it was driving me nuts, but I just couldn't see the wood for the trees - also probably a "senior moment" ;-)

On Thursday, 7 February 2013 16:03:56 UTC, feabhas wrote:

I know there is going to be an easy answer to this. Some time ago I wrote a simple MQTT client for QoS0 pub/sub in C, really to get a handle on the protocol.
I've come back to it after many months away (work getting in the way) and I'm puzzled by something. I'm currently reimplementing in in "pure" Python (using socket and bytearray).
The CONNECT request is (assuming no Will message):
Fixed header - 2 bytes
Variable header - 12 bytes
Payload - Client ID UTF-encoded string.
But looking at my code I have the variable headers as:

 // variable header

        uint8_t var_header[] = {

            0, // MSB(strlen(PROTOCOL_NAME)) but 0 as messages must be < 127

            strlen(PROTOCOL_NAME), // LSB(strlen(PROTOCOL_NAME)) is redundant

            'M','Q','I','s','d','p',

            PROTOCOL_VERSION,

            CLEAN_SESSION,

            MSB(KEEPALIVE),

            LSB(KEEPALIVE),

            0, // MSB(strlen(broker->clientid)) but doesn't work for > 127

            strlen(broker->clientid) // LSB(strlen(broker->clientid))

        };

which has 14-bytes, as I have an extra 2 bytes on the end for the length of the client ID, before the Client ID string.
I'm currently testing with mosquito and if I take those two bytes out it fails to connect, but I can't see in the Protocol Spec where the requirement for these extra two bytes is stated?