Unsubscribing from zero topics?

[jonesmz]

Right now, mqtt_cpp does not check the number of topic patterns being unsubscribed from.

It is possible that the end-user might try to unsubscribe from 0 topics.

In this case, I believe a packet is still sent, which is a protocol error.

3.10.3 UNSUBSCRIBE Payload

The Payload for the UNSUBSCRIBE packet contains the list of Topic Filters that the Client wishes to unsubscribe from. The Topic Filters in an UNSUBSCRIBE packet MUST be UTF-8 Encoded Strings [MQTT-3.10.3-1] as defined in section 1.5.4, packed contiguously.

The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic Filter [MQTT-3.10.3-2]. An UNSUBSCRIBE packet with no Payload is a Protocol Error. Refer to section 4.13 for information about handling errors.

What do you think about just calling the async handler function straight away, instead of queueing a packet to send?

[redboltz]

I think that if user tries to send unsubscribe with empty topics then throw protocol_error() is good.

From the server side, if unsubscribe packet that has empty topics then call_protocol_error_handlers() should be called.

I think that this rule should also be applied to subscribe.

[jonesmz]

Throwing an exception is fine.

I think suback, and unsuback as well?

3.11.3 UNSUBACK Payload

Non-normative comment

There is always one Reason Code for each Topic Filter in the corresponding UNSUBSCRIBE packet. If the Reason Code is not specific to a Topic Filters (such as 0x91 (Packet Identifier in use)) it is set for each Topic Filter.

[redboltz]

Yes but v3.1.1's unsuback is not error.

I sum up as follows:

version	subscribe	unsubscribe	suback	unsuback
v3.1.1	x	x	x	- (no payload)
v5	x	x	x	x

x: empty payload is protocol error.