include agent protocol in topic (MQTT)

[AlvaroVega]

Currently topics used by iotagent-json and iotagent-ul are the same.
/<apikey>/<device_id>/attrs
There is no way to know if a topic (MQTT) is for UL or JSON agent.

Topic is fixed in agent source code:

• https://github.com/telefonicaid/iotagent-json/blob/master/lib/bindings/MQTTBinding.js#L45
• https://github.com/telefonicaid/iotagent-ul/blob/master/lib/bindings/MQTTBinding.js#L46

Topic is knowed by ACL files:

• https://github.com/telefonicaid/iotagent-node-lib/blob/master/docker/Mosquitto/aclfile#L3
• https://github.com/telefonicaid/rabbit-topic-acl/blob/master/docker/aclfile#L2

Possible solution: extending topics
/<protocol>/<apikey>/<device_id>/attrs
but is not backward compatible

[fgalan]

Topic root should be configurable. For instance:

config.mqtt.topicRoot = '/UL'

Anyway we should be very careful with this changes, as it could break backward compatibility in existing integrations.

[fgalan]

Do we have a "twin" issue for IOTA-JSON?

[AlvaroVega]

twin issue telefonicaid/iotagent-json#374

[manucarrace]

Keeping in mind that the root problem is that IoTA-UL agent is receiving IoTA-JSON mesaures and vice versa ...
In order to assure backwards compatibility I propose to set the subscripción to mosquitto just after the group is created. This way, IoTA JSON will receive only messages from its apikeys.

[AlvaroVega]

Using rabbitMQ instead of mosquito, communication between agent and broker is done through AMQP, so the solution for this issue should be reconsidered.
In AMQP binding is done by queues:
https://github.com/telefonicaid/iotagent-ul/blob/master/lib/bindings/AMQPBinding.js#L224
And acl for MQTT is:
https://github.com/telefonicaid/rabbit-topic-acl/blob/master/docker/aclfile

[AlvaroVega]

Using shared subscriptions from https://blog.codecentric.de/en/2017/11/hello-mqtt-version-5-0/ implemented in mosquito 1.6+

Shared Subscriptions

With support of shared subscriptions, Client Load Balancing is now included in MQTT. The message load of a single topic is distributed amongst all subscribers (this was already supported by HiveMQ for MQTT 3.1 & MQTT 3.1.1).

A Shared Subscription is identified using a special style of Topic Filter.

The format of this filter is:

$share/{ShareName}/{filter} 

$share – is a literal string that marks the Topic Filter as being a Shared Subscription Topic
{ShareName} – is a character string that does not include “/”, “+” or “#”
{filter} – is the remainder of the string has the same syntax and semantics as a Topic Filter in a non-shared subscription.

[AlvaroVega]

PUB: (like currently is done)
pub> mosquitto_pub -h localhost -t '/9n4hb1vpwbjozzmw9f0flf9c2/test2/attrs' -m '{"v": 55}' -u iota -P 'XXX' -d

SUB: (like insternally ot-agent does)
agent-ul-1> mosquitto_sub -h localhost -t '$share/ul//+/+/attrs' -u iota -P 'XXX' -d
agent-ul-2> mosquitto_sub -h localhost -t '$share/ul//+/+/attrs' -u iota -P 'XXX' -d
agent-json-1> mosquitto_sub -h localhost -t '$share/json//+/+/attrs' -u iota -P 'XXX' -d
agent-json-2> mosquitto_sub -h localhost -t '$share/json//+/+/attrs' -u iota -P 'XXX' -d

Only only one iot-agent-json is going to receive message each time, not both like until now. This way several iotagent of same protocol does not receive duplicated messages.
Aditionally on iot-agent-ul is going to receive message each time, but is not going to be delivered to app level, since apikey is not in that agent. (50% reduce of noise)

[fgalan]

Implemented by PR #401

Can this issue be closed? Or is anything pending?