[ASK] How to "pass" an MQTT RPC call

[koepalex]

Product

.NET SDK

Azure Iot Operations version

No response

What happened?

Using the AIO SDK, to write a handler that handles multiple MQTT paths
[CommandTopic("foo/bar/{method}")]

and not passing in method into the TopicTokenMap, so that the AIO SDK use the MQTT wildcard +. Will allow the user to read the actual used method used out of the extendedRequest.RequestMetadata.TopicTokens dictionary.

But how to avoid answering that call, if the method isn't something the current service is responsible for? How to tell the AIO SDK, that it should not respond to that call?

List the steps to reproduce

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[koepalex]

When I start two executors (because I have different Request and Response types), using the same MQTT wildcard path, it seems that always the first got the call, even other would be correct.

But up to now, I don't see a way to "hand over". This is serious blocker as we have to handle multiple (dynamic) MQTT actions, at the same time.

[timtay-microsoft]

Using the AIO SDK, to write a handler that handles multiple MQTT paths
[CommandTopic("foo/bar/{method}")]
and not passing in method into the TopicTokenMap, so that the AIO SDK use the MQTT wildcard +. Will allow the user to read the actual used method used out of the extendedRequest.RequestMetadata.TopicTokens dictionary.

We don't have any way for an executor to "pass" on responding to a command invocation it received. Generally, you should be passing in the topic token map to specify which {method} tokens this particular executor should handle. Is there a reason why you can't take this approach?

edit: Is the idea here that you want N command executors to be handling N separate command invocations in parallel where the {method} token value is largely irrelevant to who it should be routed to?

[koepalex]

Once I get a call, I will look up (dynamically) if that call is something I can handle, this is based on the OT device I'm connected to.
In my case, I might have 4-5 executors handling 5 - 500 methods.

[timtay-microsoft]

Is the wish here then that the RPC request would be received by all applicable RPC executors (but only one would respond), or for it to be received by a single RPC executor who then "passes it along" somehow (over MQTT?) to the "next" RPC executor?

[koepalex]

Single RPC executor with .Next() would be nice, or all RPC executors in parallel if they can decide to not handle that request

[timtay-microsoft]

or all RPC executors in parallel if they can decide to not handle that request

This approach seems designable from our side and should minimize bouncing the RPC call around over network calls from executor to broker to next executor to broker to etc.... Let me work on a design spec for this and get back to you

[timtay-microsoft]

For a bit more context here, are your executors in this scenario on the same device? Would they have a way to communicate with each other besides through MQTT?

But how to avoid answering that call, if the method isn't something the current service is responsible for? How to tell the AIO SDK, that it should not respond to that call?

And would it be sufficient if we just added the ability for a single executor to ignore a request, or do you also need the ability to forward that same request to a different executor?

[koepalex]

My executors are on the same pod but there can be 2P/3P connector running in another pod on the same device (k8s node) or another.

[timtay-microsoft]

But how to avoid answering that call, if the method isn't something the current service is responsible for? How to tell the AIO SDK, that it should not respond to that call?

And would it be sufficient if we just added the ability for a single executor to ignore a request, or do you also need the ability to forward that same request to a different executor?

[koepalex]

I have X executor all listen to same "same" topic, where the last part is wild card. Expectation is that all get the call and can figure out if they want to handle them. Two in that case would say "NotResponsible" and the third would normally handling it.

Expected cases:

• 1 handling the call
• None handling the call (timeout)

Is already planned to allow more than one executor to handle a call, e.g. for discovery?

[timtay-microsoft]

I have X executor all listen to same "same" topic, where the last part is wild card. Expectation is that all get the call and can figure out if they want to handle them. Two in that case would say "NotResponsible" and the third would normally handling it.
Expected cases:
1 handling the call
None handling the call (timeout)

Is it feasible for you to just have one command executor that dispatches the handling of each invocation to one (or none) of your handlers here?

Is already planned to allow more than one executor to handle a call, e.g. for discovery?

Not AFAIK, but @varunpuranik and @avishekpant probably have more visibility than me on that one.

[avishekpant]

@koepalex: No, there is no such plan for discovery as well. Can you follow what Tim suggested: have one command executor that dispatches the handling of each invocation to handlers?