Hono: Support gateway agnostic addressing of devices

[sysexcontrol]

Applications must be able to send commands to devices without knowing the particular gateway they may be connected to.

[calohmn]

To be achieved here is that the consumer application can send the command message only knowing the device id, not the gateway id.
However, on the side of the protocol adapter, the receiver link for receiving such commands may have been created with the gateway id in the address ("control/tenantId/gatewayId"), not the device id.
That means that either in the consumer application or somewhere between consumer application and protocol adapter, a mapping from device id to corresponding gateway id has to be applied.

The place, where such mapping data is kept (the "mapper component"), could be a new component or in the device registry for example. Whenever there is a new request from a device via a gateway, this mapping data could be updated.

As to the way this mapping can get applied so that the command request reaches the right protocol adapter, I see these alternatives:

1. Mapping applied in the consumer application:
   The consumer app first makes a request to the new mapping data component (via qpid) to get the current gateway id for the device and then uses that gateway id in the command request.
   This functionality could be encapsulated in the HonoClient and therefore be mostly transparent to the consumer app.

2. Define Qpid waypoint that applies mapping and redirects the request:
   Using the router feature of waypoints and auto-links, the command request with the device id from the consumer application is first handled by the "waypoint mapper" component (i.e. "mapper component", could be the same as the device registry). In this component the mapping is applied and the request gets redirected to the "control/tenantId/gatewayId" address to be consumed by the protocol adapter.
   Whether this approach is actually feasible and whether it would work together with EnMasse or a non-Qpid based AMQP messaging network remains to be seen.

3. Use an intermediate "control/tenantId" dispatcher component:
   With this approach, there is a new "Command dispatcher" (or "Gateway-to-device Mapper") component in between the protocol adapter and Qpid.
   This new component creates an AMQP receiver on "control/tenantId" addresses in connection with Qpid, so that it will receive the command requests from the consumer application.
   The device id of the received requests is mapped to the gateway id and the command request is sent to the protocol adapter.
   This means the protocol adapters create the receiver link on the "control/tenantId/gatewayId" address not with Qpid but with the new "Command dispatcher" component.

Option 1 is probably the most straightforward to implement but introduces further complexity on non-HonoClient based consumer applications.
With Option 2 it is unclear, how this could work exactly and how support would look like with EnMasse or a non-Qpid based messaging network.
Option 3 seems the most flexible to me. (I'm not sure yet about all the implications, though.)

Thoughts on this?

[sophokles73]

Option 1 is probably the most straightforward to implement but introduces further complexity on non-HonoClient based consumer applications.

I agree, this might prove useful as a fallback solution if do not come up with something more convenient.

With Option 2 it is unclear, how this could work exactly and how support would look like with EnMasse or a non-Qpid based messaging network.

based on the personal discussion I had with @calohmn, it looks as if this is not reasonable to do based on auto links and waypoints because we would need to create auto links for at least each tenant. However, we could still use the concept of the mapper component but connect it in a different way to the existing infrastructure. The mapper component instances could connect to the AMQP Messaging Network using a receiver link with a source address of, say, control/requests. The applications would then send their one-way commands and command request messages to the AMQP network over a sender link with target addess control/requests (regardless of the tenant and/or device) but would need to set the message's to property to the proper device address, i.e. control/$tenant/$deviceId.
The mapper instances would then compete for the command messages and whenever one of them gets a command message, it replaces the deviceId in the to property with the device ID of the gateway, if necessary, and sends the command to a Hono internal Qpid Dispatch Router network over a link using the message's mapped address as the target address.
The protocol adapter instances would work as the did before, i.e. they would still open consumer links with a source address of control/$tenant/$deviceId. The only difference would be that they no longer connect to the AMQP Network but to the internal Dispatch Router network.

Option 3 seems the most flexible to me. (I'm not sure yet about all the implications, though

IMHO this will require us to implement a lot of the functionality that is already present in the Dispatch Router. In particular, we would need to implement routing between the multiple instances of this Command Dispatcher component because you do not know to which of the instances the protocol adapter instances will connect.

[calohmn]

The applications would then send their one-way commands and command request messages to the AMQP network over a sender link with target addess control/requests (regardless of the tenant and/or device) but would need to set the message's to property to the proper device address, i.e. control/$tenant/$deviceId.

Thinking about a scenario where Hono is used with EnMasse, usage of the control/requests target address would cause authorization issues on the side of the senders here. When a non-empty target address is used, Qpid will check that address against the address permissions map received via the Keycloak auth service plugin. The to property of the message won't be checked in that case. That would mean, we can't define tenant-specific permissions here - the applications would be able to send commands to all devices of all tenants (of course provided the devices are actually listening).

The alternative would be to let the application use a sender with an empty target address and the proper address in the to property of the message.
But that would require Hono to open receiver links on all kinds of tenant id / device id combinations. So that's not an option.

[calohmn]

To mitigate this, we could let the application open the sender link on the control/requests/$tenant address and use the control/requests/$tenant/$device address in the To property.

In Hono, we would create the receiver link on the control/requests/$tenant address in the protocol adapter instance, that has gotten the subscription request by the gateway device. Over time, multiple protocol adapter instances could possibly open such a link for the same tenant, but it doesn't matter which instance actually receives the command message.
The reason is that the protocol adapter then applies the device -> gateway mapping to the address in the To property and forwards the message to a new Qpid instance in Hono itself.
And with this Qpid instance, the _actual_ protocol adapter to which the target gateway is subscribed has opened a control/requests/$tenant/$gateway receiver link.

That means, the difference to the above approach is using control/requests/$tenant instead of just control/requests for the application sender link address and integrating the mapper component logic in the protocol adapters.

--
To a previous concern towards combining protocol adapter and mapper components, that was based on custom protocol adapters then having the ability to open receiver links on _all_ command messages: With the control/requests/$tenant address pattern, the user used for authorizing access from the custom protocol adapter to the AMQP network (e.g. EnMasse) should only be given read permissions on the control/requests/$tenant addresses with the tenant that the custom protocol adapter should have rights on.
To be resolved still in this respect: How to authorize access to the new Hono Qpid? Possibly with the Qpid auth plugin in connection with the Hono Auth component.

[calohmn]

Actually, I think we don't necessarily need the new extra Hono-internal Qpid. It would be beneficial from a performance point of view if the AMQP network is in another VPC.
But as long as the new gateway mapping logic sends the mapped message on an address, that the command-sending application doesn't have permissions on (e.g control/internal_requests/$tenant/$gateway), it should also work sending it to the AMQP network again and letting the protocol adapter receive it from there.
It would be much easier to start out with this approach.

[calohmn]

The architecture and the steps towards setting up the links as well as the command flow is illustrated here:

Steps that happen here are (yellow circles):

(1) A gateway device subscribes to command messages. The request ends up at protocol adapter instance 1.

(2) The protocol adapter instance will create

• receiver link on control/requests/$tenant (could be already there)
• receiver link on control/internal_requests/$tenant/$gateway
  (in the case that a directly connected device is involved here with no gateway, $gateway would be the device id here)

with the AMQP network.
If the subscription from the gateway is done on behalf of an actual device, getting the registration assertion from the device registry will trigger an update of the device->gateway mapping in the device registry.

(3) To send commands, the application in the solution tier opens a sender link on control/requests/$tenant
and sends the command message with a To address control/requests/$tenant/$device.

(4) All the protocol adapters that have a receiver link on control/requests/$tenant compete for receiving the message.
In this example, let's say protocol adapter instance 2 gets the message.

(5) Applying device->gateway mapping information provided from the device registry, the protocol adapter finds the gateway id corresponding to the device id from the To property of the message.
(If there is no gateway found, meaning thate the device is connected directly, the device id from the To property is used as $gateway from here on).
The protocol adapter checks whether it already has a command receiver on the mapped control/internal_requests/$tenant/$gateway address.
If yes (as would be the case if adapter 1 had gotten the message), the adapter can send the message to the gateway device.
If no (as illustrated above), the adapter sends the message on a sender link (with the anonymous relay as target) with the To property control/internal_requests/$tenant/$gateway to the AMQP network.

(6) From there, the protocol adapter 1, having a receiver on that address, gets the message and can send the message to the gateway device.

[BobClaerhout]

As discussed in the call, the address to post commands on will probably change. This is fine by me. However I have a concern on the address. Is following assumption correct?
To send a command to the device I'm using control/requests/$tenant/$device as the To property on the message. This is used for sending a message directly to the device as well as for sending a message through the gateway. This surely is what we want because we do not want the business application to know whether the device is behind a gateway or not.
If this is correct, it is possible that the "wrong" protocol adapter receives the message when I want to send directly to a device. Is this addressed somewhere in the solution?

[calohmn]

Yes, the To property value of control/requests/$tenant/$device is the same if the target device is behind a gateway or if it is directly connected to the protocol adapter.
In case it is directly connected, i.e. there is no device->gateway mapping, the receiving protocol adapter should forward the message to the control/internal_requests/$tenant/$device address (ie. $gateway is $device from the To property here).
On that control/internal_requests/$tenant/$device address, the actual protocol adapter instance (that the device is connected to) will have a receiver link.
I've updated the text above to reflect that.

[calohmn]

The solution above relies on the fact that protocol adapters open receiver links on control/requests/$tenant and control/internal_requests/$tenant/$gateway.
In the cases of MQTT and HTTP protocol adapters this would be triggered by incoming requests/subscriptions on that tenant and gateway.

But what about a protocol adapter like a LoRaWAN adapter where there is _no such trigger_ (at least not necessarily)?
This kind of adapter should be able to receive commands without having gotten requests from gateways/devices before. That means, such an adapter actively forwards the commands as _requests_ to the gateways/devices, not as a response to an incoming request from the gateways/devices.

To receive the commands, the protocol adapter would have to open receiver links for _all_ tenants and _all_ gateways relevant for this adapter.
This would mean that the adapter would have to be pre-configured with these tenant ids (or there would be a new method to query these in the device registry) so that corresponding links can be initialized on adapter startup. That doesn't look very practical.

In the case of the LoRaWAN adapter for example, it would be preferable for the adapter to be preconfigured just with the gateways (ie. the LoRa Network Server Gateways of the network providers).
These gateway ids could be handled/registered as pseudo tenants, so that the adapter opens receiver links on addresses like control/requests/$gateway_pseudo_tenant and control/internal_requests/$gateway_pseudo_tenant/$gateway.

For such a setup, the device->gateway mapping mechanism would also have to map from the actual customer tenant to the pseudo gateway tenant. That is because the application in the solution tier still sends the command using the _actual_ customer tenant (sender link on address control/requests/$tenant).

How to receive these commands without opening receiver links on _all_ the actual tenants, having no triggers from the gateways/devices?

Idea:
We could let the applications in the solution tier open the sender links directly with the Hono protocol adapters via a Qpid dispatch router that forwards the link attachment frame (as configured by an outgoing linkRoute definition with the "control/requests/" prefix). This Qpid dispatch router is either the one already used as part of the AMQP network or it is a new separate router instance.
With this approach, the protocol adapters get all "control/requests/" messages - without having to open tenant-specific receivers.

This leads to the following architecture (applicable for an AMQP network with a Qpid dispatch router with an appropriate linkRoute config):

Steps that happen here are (yellow circles):

(1) A gateway device subscribes to command messages. The request ends up at protocol adapter instance 1.

(2) The protocol adapter instance will create

• a receiver link on control/internal_requests/$tenant/$gateway
  (in the case that a directly connected device is involved here with no gateway, $gateway would be the device id here)

with the Qpid dispatch router of the AMQP network.
If the subscription from the gateway is done on behalf of an actual device, getting the registration assertion from the device registry will trigger an update of the device->gateway mapping in the device registry.
In case of a LoRaWAN (or similar) adapter, such a link (with $tenant set to the network/gateway id) will be created for all preconfigured networks/gateways on adapter startup.

(3) To send commands, the application in the solution tier opens a sender link on control/requests/$tenant/$device with the Qpid dispatch ruoter and sends the command message.

(4) All the (non-custom) protocol adapters are potential receivers of command messages.
In this example, let's say protocol adapter instance 2 gets the message.

(5) Applying device->gateway mapping information provided from the device registry, the protocol adapter finds the gateway id (and tenant id) corresponding to the device id from the command request.
(If there is no gateway found, meaning that the the device is connected directly, the device id from the To property is used as $gateway from here on).
The protocol adapter checks whether it already has a command receiver on the mapped control/internal_requests/$tenant/$gateway address.
If yes (as would be the case if adapter 1 had gotten the message), the adapter can send the message to the gateway device.
If no (as illustrated above), the adapter sends the message on a sender link (with the anonymous relay as target) with the To property control/internal_requests/$tenant/$gateway to the AMQP network.

(6) From there, the protocol adapter 1, having a receiver on that address, gets the message and can send the message to the gateway device.

---

In case the AMQP network doesn't contain a Qpid dispatch router whose config can be adapted with the appropriate linkRoute definition, the setup would include a new Qpid instance.

This Qpid instance instance would be the one that the application in the solution tier has to target (would mean a separate target endpoint for the command messages).
The challenge here would be to adopt the corresponding authentication and authorization rules from the AMQP network messaging endpoint.
Or the specific AMQP network can be configured to do the same kind of forwarding of command messages as Qpid, whereas the application would again use the AMQP network endpoint as target.

Or: The introduction of the extra Qpid here is motivated by the wish for providing _one_ command&control endpoint for the application in the solution tier, i.e. the same endpoint for sending the commands as for receiving the command replies.
If we deviate from that, we could declare two endpoints to be used by the applications like:

• messaging_in for sending command requests
• messaging_out for consuming telemetry/event and command responses.

Then we could skip the extra Qpid instance and let the messaging_in endpoint be directly provided by the protocol adapters. Authentication and authorization could be done by the protocol adapters via creating a corresponding link to the AMQP network with the received SASL handshake credentials (if link creation succeeds, authorization is successful).

[BobClaerhout]

I like the proposed solution concerning the internal_requests. I think it doesn't have any downsides. I do have some remarks/questions:

• Isn't hono always depending on an external AMQP network? Is it really necessary to have the ability to include an own Qpid instance? Is somebody deploying hono without an external AMQP network?
• I think you are adding a requirement which is not needed. According to the documentation of actility/LoRaWAN (https://dx-api.thingpark.com/dataflow/v021/product/Processor-Documentation/Connectors/GenericMQTT/remarks.html) the mqtt address looks like accountPrefix/things/deviceEUI/uplink. This is also the case for AMQP connections, maybe this is not the case for HTTP publishers? I can't find any information on the messages published there and I do not have any experience with it. However, for AMQP and MQTT, the address contains both the tenant (account) and the device. This allows the adapter to extract both paramaters from the address and thus enabling to subscribe to the correct address and saving the gateway-device mapping as described in your proposal.
• Concerning the devices which haven't send any messages yet: this isn't any different from other adapters. If a device from a certain tenant has never sent a message to the MQTT adapter or the HTTP adapter, you do not know through which gateway the device will connect to hono. FMPOV I think you're adding a requirement which has nothing to do with the core of this issue. Therefore I suggest to not take this extra requirment into account. This will complicate the implementation a lot.
• A small remark which may not be forgotten during implementation (although I think you've probably already thought about this): a device should be able to roam between gateways. This means that specific mapping should be overwritable.

[calohmn]

Isn't hono always depending on an external AMQP network? Is it really necessary to have the ability to include an own Qpid instance? Is somebody deploying hono without an external AMQP network?

Yes, the architecture of Hono explicitly states the AMQP network to be external to Hono, so that one is flexible to attach Hono to a preferred messaging solution (be it a self-managed Qpid+Artemis, EnMasse or e.g. an Azure based messaging solution).
In that sense the first illustration in the comment above with the AMQP network consisting of a Qpid specially configured to connect to the Hono Protocol Adapters could be rather an unusual one (albeit the easiest to show the idea). Indeed, the main point of the above idea would be to find the solution for the case where we see the AMQP network as a black box (I've added another illustration for that).

I think you are adding a requirement which is not needed. According to the documentation of actility/LoRaWAN (https://dx-api.thingpark.com/dataflow/v021/product/Processor-Documentation/Connectors/GenericMQTT/remarks.html) the mqtt address looks like accountPrefix/things/deviceEUI/uplink. This is also the case for AMQP connections, maybe this is not the case for HTTP publishers?

I was indeed looking at the scenario, where the LoRaWAN adapter is doing HTTP requests to the gateways (e.g. a Kerlink gateway). That would be a case where there was no preceding info coming from the gateways. With AMQP / MQTT indeed that would be different probably.

So, the main question is here: Do we want/need to add support for such protocol adapter scenarios, not requiring prior triggers from the gateways?
If not, we could choose the first approach above.

Concerning the devices which haven't send any messages yet: this isn't any different from other adapters. If a device from a certain tenant has never sent a message to the MQTT adapter or the HTTP adapter, you do not know through which gateway the device will connect to hono.

The difference would be the case of a LoRaWAN adapter, sending commands via HTTP to the gateways. There, the knowledge of to which gateway the device is connected to could potentially be configured in the device registry, not requiring the devices to have sent a messages to the gateway yet.

a device should be able to roam between gateways. This means that specific mapping should be overwritable.

Yes.

[calohmn]

So, the main question is here: Do we want/need to add support for such protocol adapter scenarios, not requiring prior triggers from the gateways?
If not, we could choose the first approach above.

Any opinions on this?

The new HTTP based LoRa adapter (see PR #1078) currently only supports a preconfigured list of commandEnabledTenants.
With the above 2nd approach (not requiring triggers by the gateways), this limitation could be removed.

Therefore, I would rather opt for that approach with the following setup as shown above:

If the AMQP network is able to forward command requests to the protocol adapters, the command&control endpoints for the solution tier applications can remain in the AMQP network (the protocol adapters don't have to forward SASL credentials to the AMQP network in this case).

[BobClaerhout]

The difference would be the case of a LoRaWAN adapter, sending commands via HTTP to the gateways. There, the knowledge of to which gateway the device is connected to could potentially be configured in the device registry, not requiring the devices to have sent a messages to the gateway yet.

If the HTTP LoRaWAN is able to retrieve the tenant, gateway and deviceId from the messages being sent to that adapter, I would implement the predefined list in another iteration. IMO this is not needed for a first version to address the problem discussed here.

With the above 2nd approach (not requiring triggers by the gateways), this limitation could be removed.

Can you clarify this? What are the exact triggers by the gateways you are talking about? Are those triggers devices message flowing through the gateways to the adapter?

I think my opinion was already clear to use an external AMQP network and without a pre-configured list mapping of devices/gateways. The part of your thoughts about those triggers is not entirely clear to me so I might be missing your request for input on that one.

[calohmn]

With the above 2nd approach (not requiring triggers by the gateways), this limitation could be removed.

Can you clarify this? What are the exact triggers by the gateways you are talking about? Are those triggers devices message flowing through the gateways to the adapter?

With the 1st approach (the very first illustration image above), the current command&control scenarios with the HTTP and MQTT adapters can be realized.
These adapter either receive a "subscription" request (MQTT) or a request with a ttd param (time til disconnect - the device waits that long for a command) (HTTP) from the devices (or gateways).
That would be the trigger that I meant, enabling the adapter to create a receiver link on the corresponding tenant.

In the case of a HTTP LoRaWAN adapter, devices/gateways don't necessarily signal their intent to receive commands in such a way.
I mean we theoretically could create the command receiver link on the corresponding tenant in the adapter when telemetry/event messages are received.
But what if a device didn't send such a message, _or what if the adapter was restarted at some point after that (the receiver link being gone after that)_.
In these cases commands should still reach the devices.

In the LoRa adapter implementation given in PR #1078, the adapter is ready to receive commands directly after startup (without device requests) by means of having a preconfigured list of commandEnabledTenants.
For these tenants, the command receiver links are created on startup.

To mitigate this limitation of the LoRa adapter, not requiring the fixed list of tenants, the 2nd approach above can be used.

See this paragraph above:

In the case of the LoRaWAN adapter for example, it would be preferable for the adapter to be preconfigured just with the gateways (ie. the LoRa Network Server Gateways of the network providers).
These gateway ids could be handled/registered as pseudo tenants, so that the adapter opens receiver links on addresses like control/requests/$gateway_pseudo_tenant and control/internal_requests/$gateway_pseudo_tenant/$gateway.

For such a setup, the device->gateway mapping mechanism would also have to map from the actual customer tenant to the pseudo gateway tenant. That is because the application in the solution tier still sends the command using the actual customer tenant (sender link on address control/requests/$tenant).

This leads to the 2nd approach above where the main point is that Hono introduces a command endpoint for all command messages, not requiring the establishment of the receiver links for all actual customer tenants.

I think my opinion was already clear to use an external AMQP network and without a pre-configured list mapping of devices/gateways.

My thoughts here also included devices that don't need to send messages before potentially receiving commands. For these devices, a pre-configured mapping is needed.
In any case, we could update the device/gateway mapping whenever a message from a device is received.

[sophokles73]

@calohmn @BobClaerhout
Thanks for the great discussion of the subject so far :+1:
Of course, teach of the proposed/discussed approaches have their pros and cons. However, I do have to admit that I would rather not rely on Qpid being part of the AMQP Messaging Network nor introducing it to Hono as a required component. The reason for that simply is that the former assumption would drastically restrict the choice for AMQP Messaging Network implementations while the latter would add another component to the already complex system landscape that we would need to configure, operate and scale. That said, I do like the initially proposed approach, where all (standard) protocol adapter instances compete for outbound command messages and participate in the mapping of the message address.

My understanding is that we can already use this approach for those cases where a gateway/device triggers the establishment of the device specific receiver link. The only open issue seems to be, if, and if so, how we would support cases where there is no such trigger.

The only occurrence of this pattern currently seems to be LoRa network providers acting as gateways for LoRa devices which use HTTP to forward telemetry to our adapter and which expose an HTTP endpoint for receiving upstream commands for devices.

As @BobClaerhout pointed out, many (if not all) of these network providers also support (or prefer?) connecting to clouds via MQTT (or AMQP) instead of using HTTP. May be we can simply restrict Hono's support for LoRa to such providers? Then we would not have the problem outlined by @calohmn at all, right?

If we do need to support this use case, then we might also be able to use the initial approach proposed by @calohmn with a small addition being made. In all such cases, it is not important which protocol adapter instance forwards the command to the network provider endpoint. So, all instances of the corresponding adapter type could open an additional, type specific receiver link for outbound commands. The HTTP adapters could use e.g. hono-http/control/out.

When doing the mapping of the message address, all the protocol adapter instances would then determine the type of protocol adapter that the device uses based on information contained in the Device Registration service. If a specific adapter type is registered, then the address is mapped to the corresponding address pattern, e.g. ${adapter-type}/control/out and forwarded via the anonymous sender link as outlined in @calohmn initial proposal. If no specific adapter type is registered, then the standard mapping is done, i.e. just mapping the device ID to the gateway ID.

In both cases, the mapped command message would need to contain the tenant and device ID of the device that is the subject of the command, so that the protocol adapter can use this information when forwarding the command to the network adapter.

[calohmn]

When doing the mapping of the message address, all the protocol adapter instances would [...]

The question would be here, how the protocol adapter instances would be able to receive the command messages from the applications in the first place (before doing the mapping).
In my initial proposal, the trigger (ie. subscription/ttd request) from the gateways/devices contains the tenant id for which the protocol adapter instance will open the control/request/$tenant receiver link.

With no such trigger, there is no certainty that such a receiver link has been created (we can't practically create such links for all tenants).
On the other hand, applications are required to use a tenant specific address like control/request/$tenant for sending the commands because the whole authorization mechanism in the AMQP network relies on that.

A solution for that was a main point of my 2nd approach, allowing the protocol adapters to receive all commands, like doing a wildcard match on all tenants, by letting the applications connect directly to the protocol adapters (or letting them connect to a Qpid instance that does link-routing of all such requests to the protocol adapters).

[sophokles73]

right, I totally forgot about that ...

[calohmn]

TLDR;:
The main question above was:
As part of a solution here, do we need/want to support a scenario where protocol adapters should be able to get commands for gateways, that haven't connected to the adapter yet? Example would be a HTTP based LoRa adapter, configured for a set of LoRa network provider gateways, to which commands are actively forwarded via HTTP.

Such a scenario requires a rather complicated solution that either introduces a separate command endpoint for the applications in the solution tier or requires the AMQP network to be able to forward all control/* requests to the Hono protocol adapters.

Preferred solution:
In an offline discussion with @sophokles73 we came to the conclusion that we better not add such complexity to Hono. For cases like the above mentioned LoRa adapter, alternative solutions, e.g. requiring MQTT, not HTTP, should be used. Therefore we recommend the first, simpler solution for the overall issue, as presented in the first illustration above.

@ctron, @dejanb:
Would you agree here? Or do you have other things to add here regarding some specific gateway types or protocols?

[calohmn]

An outlook towards improving the steps (5) and (6) in this illustration

where the mapped commands get routed back via the AMQP network in order to reach the specific protocol adapter instance connected with the gateway.

Instead, we could setup a cluster among the protocol adapters, handled via a Vert.x cluster manager. With this, the mapped command message can be sent directly from the receiving protocol adapter instance to the target protocol adapter instance.

From a development point of view we can start out with the first approach and then migrate the internal transport of the mapped command to the cluster setup.

[BobClaerhout]

Instead, we could setup a cluster among the protocol adapters, handled via a Vert.x cluster manager. With this, the mapped command message can be sent directly from the receiving protocol adapter instance to the target protocol adapter instance.

What's the advantage of this? Why is this preferred?

[calohmn]

What's the advantage of this? Why is this preferred?

The mapped message would travel directly from the receiving adapter to the target adapter instead of taking the extra 2 hops to and from the AMQP network. This could be especially relevant if the AMQP network components are located in another physical network compared to the hono protocol adapters. It would also save us from creating the extra AMQP sender/receiver links for this communication with the AMQP network.

And it would offer us the possibility of maybe introducing a distributed cache in the adapters for device registry responses later on. Just as an idea.

[calohmn]

Done.
In Hono 1.0 M4 still using the Device Registry for storing the gateway mapping.
In Hono 1.0 M5 using the new Device Connection API.