Potentially competing receiver links when using command and control API

Command and control API uses address control/${tenant_id}/${reply_id} for receiving responses in consumer applications. Users are free to choose ${reply_id}. If an application wants to receive all responses of one tenant, hono docs recommend to use an arbitrary (short) string as ${reply_id} without ${device_id} and to keep the receiver link open.

However, protocol adapters use a very similar addressing scheme to receive commands from applications in the form of control/${tenant_id}/${device_id}. If ${device_id} == ${reply_id} we now have two competing receiver links and messaging network can not distinguish if a message should be sent to protocol adapter or to the application.

One possible solution would be to change addressing scheme for responses to response/${tenant_id}/${reply_id}. Of course this would require an API change.

WDYT?

[calohmn]

@sophokles73 Yes, however that would apply only for the AMQP adapter endpoint.

For HTTP and MQTT adapters, we would just add new command endpoints: HTTP command response: /command/res/${commandRequestId} MQTT command response: command///res/${req-id}/${status}

[calohmn]

As suggested by @sophokles73, a solution that is easier to implement would be to keep the command response address pattern the same (“control”). For the command requests, the “command” prefix (instead of “control_request”) will be newly introduced.

The changes would then be:

• Next Hono milestone (M4):
  • Introduce new command/${tenant_id} endpoint for sending commands (with gateway-mapping feature).
  • The existing control/${tenant_id}/${device_id} endpoint for sending commands will still work, but will lack the gateway-mapping feature. It will be marked as deprecated.
  • The existing control/${tenant_id}/${reply_id} address for the command responses stays the same.
• Hono 1.0 or possibly later:
  • For Command sender links: Change control/${tenant_id}/${device_id} to control_request_internal/${tenant_id}/${device_id}. Only Protocol Adapter users shall get access to control_request_internal addresses then.
    • From that point on: Applications shall only use command/${tenant_id} as endpoint for sending a command, and control/${tenant_id}/${reply_id} for receiving command response(s).