Reduce number of Command & Control receiver links

Currently there is one Command & Control receiver link for each device, opened from the protocol adapter instance to the AMQP network. This link is on the address control/$tenant/$device (or control/$tenant/$gateway respectively).

It would be good if we could reduce that potentially large number of links.

As proposed by @sophokles73, we could use receiver links for each protocol adapter instance (containing an instance uuid in the address) instead.

Taking on the example illustration from #930 this means replacing the red control/$tenant/$gateway links with just one for each protocol adapter instance, e.g. control_internal/$tenant/$protocolAdapterUUID.

Whenever a device/gateway subscribes to a protocol adapter for receiving Command & Control messages, we will store the mapping of device/gateway ID -> protocol adapter instance via the new Device Connection API. We will also make sure there is a receiver link control_internal/$tenant/$protocolAdapterUUID on that protocol adapter instance. Upon receiving a command on the tenant-scoped receiver link, the protocol adapter will query the Device State API to get the corresponding protocol adapter uuid and forward the command message to control_internal/$tenant/$protocolAdapterUUID.

---

Concerning when to implement this: we currently have 2 kinds of receiver links in the protocol adapters:

• control/$tenant (tenant-scoped link with gateway-mapping feature)
• control/$tenant/$device (legacy command link, also used now for forwarding the gateway-mapped commands internally)

The 2nd control/$tenant/$device link will be made into an only-used-internally kind of link at some point, removing the backwards compatibility for applications to send commands on that link. When we do this, we could change the control/$tenant/$device link into the new control_internal/$tenant/$protocolAdapterUUID link. That way, we don’t have to deal with 3 kinds of receiver links at the same time.

[calohmn]

Another thought on this:

Should we include the tenant id in the adapter-instance specific command link or should we use just command_internal/$adapterInstanceId? => IMHO, adding the tenant id could add some flexibility concerning tenant based limits, so I would opt for including the tenant id.

Can you give an example for when including the tenant ID would be helpful? FMPOV it only makes things more complicated than necessary. I particularly liked the idea of having just a single command receiver link per adapter instance …

Theoretically, using just command_internal/$adapterInstanceId would allow a (misbehaving) custom protocol adapter instance to open such a consumer link with an $adapterInstanceId already used by another protocol adapter instance, thereby potentially getting command messages not targeted at that adapter. With an added tenant ID in the address, consumer creation of a custom protocol adapter could be restricted to addresses only containing specific tenants. On the other hand, if we mandate usage of a UUID for the $adapterInstanceId, with a new UUID used with every adapter instance restart, the above shouldn’t be a problem. So I think we can stick to a single command receiver link per adapter instance.

[sophokles73]

IMHO it makes sense to work on this after we have removed the old control endpoint from the north bound C&C API (#1328), otherwise we will still have the old device scoped receiver links opened by the adapters …