why don't subscribe to any topic for sink from any module? about iot-edge-v1 HOT 8 CLOSED

Hello @Kevin0626, we debated different forms of representation for how to route messages through the gateway. The objectives for routing in the gateway was:

• Allow the gateway architect to clearly specify the flow of messages through the gateway.
• Modules shouldn’t know about consumers.
• Multiple consumers can operate on a message.
• Modules may publish without a destination.
• Remove the ambiguity of which modules process any given message, to reduce developer confusion when constructing a gateway.

None of this precludes publishing to a topic. However, we started with a "pipeline" story, that Module A routes messages to Module B, which routes to Module C, and so on. We saw this as the best fit for our objectives as well as the expected common use case for our gateways.

We do have a PBI for routing by topic in the backlog, and the initial description in the PBI is very similar to your suggestion. Depending in the implementation, we can avoid having the sender send back to itself.

So, it was a case of meeting our objectives and expected needs over any technical issues. Are there any more questions?

from iot-edge-v1.

Thanks for the answers!

I was trying to quickly create a point to point message sending function based on the publish API. It seems no quick path based on current design.

Yes, we can use filter on property. I am just concerned the performance overheard with that approach.

We want to design a data processing flow so multiple modules can handle data in sequence.

from iot-edge-v1.

I think the current gateway can support your needs, but let me clarify what we can do right now.

Suppose we have 3 modules, A, B and C. In the application, all messages generated by A must be received by B, then C will get the results from B. That would be easy enough by setting up the links as such (elided):

{
"modules" : [
  { "module name" : "A", {...} },
  { "module name" : "B", {...} },
  { "module name" : "C", {...} }
]
"links" : [
  { "source" : "A", "sink" : "B" },
  { "source" : "B", "sink" : "C" }
]
}

This configuration will guarantee module B will only see messages from module A, and module C will only see messages from module B. This makes a pipeline from A->B->C.

Of course, it's not limited to just establishing a pipeline. We can make more complicated routes by adding more links. For example, if multiple sensor modules all need their data adjusted in a similar fashion, multiple modules may be a source for a single module, an example of this is our simulated device cloud upload sample .

I hope this explanation makes sense and is helping you to understand if this will meet your requirements.

Thanks,
Dave

from iot-edge-v1.

We want a bit more flexibity on the scenario as you described.

We hope the module is self contained. That means a data processing (dp) module doesn't know other dp module. and a final module will post data to cloud, We don't want It post repeated data to cloud.

We want to design such a scenario: A -> B, B->A,A->C,C->A,A->D,D->Cloud. Only A has the entire process chain info.

from iot-edge-v1.

Interesting, could you elaborate on the scenario you’re trying to accomplish? I’ll try to analyze this technically but it would be useful to discuss it in terms of the problem you’re trying to solve.

It looks like you have three stateless dp modules (B, C, D) and one stateful orchestrator (A) that doles out work to the DP modules. What is the role of A, keeping track of a message’s progress in the pipeline from start to finish? If it always distributes work in the same order then this could be represented as a pipeline. Is it possible that the order in which B, C, and D process data may change and A is responsible for this?

from iot-edge-v1.

in the message back from B, C to A, It can indicates stopping further processing, It can aslo contain a calibrated data. That controls the processing flow.

We have developed an iot system for mushroom customer. We are exploring feasibility of porting to this open source for building a more flexible mechanism to support data processing. for example We want different modules to handle calibration, intelligent control, filter data to cloud, cache data for Internet disconnect etc.

from iot-edge-v1.

Thanks for the additional details. Could you send me an email to [email protected]? I'd like to find some time to talk with you about your scenario.

from iot-edge-v1.

No activity...closing.

from iot-edge-v1.