Comments (4)
Hi!
From my experience, one of the biggest problems in a case when you have to receive the same information from different sources (aka devices like sensors) is the identification of the source for an incoming message.
It's good when you can include some ID into a message. Something like:
struct msg_current_value : public so_5::message_t {
sensor_id_t id_;
value_t val_;
...
};
In that case just one mbox for all messages is enough.
But if you can't include the device's ID into a message then you can use a separate mbox for every device. In that case you can bind the ID with an incoming message during the subscription. Something like:
so_subscribe(unique_device_mbox)
.event( [this, unique_device_id]( mhood_t<msg_current_value> cmd) {
on_current_value(unique_device_id, std::move(cmd));
});
...
So I think that you have to consider the usage of different mboxes in case when you can't put device ID into your messages. If you can do that then the single mbox for all messages can be a simpler solution.
There is yet another factor that you can consider: separate mboxes are often used when you have to create and remove your subscriptions in run-time. For example, at some moment of time an agent wants to receive messages from device_A -- it creates a new subscription to the unique mbox of that device. When the agent decides that it doesn't want to receive messages from that device then the subscription from the device mbox is just dropped. And that doesn't affect subscriptions to mboxes of other devices.
If you want such a possibility then you can consider the usage of different mboxes. But if not then the use of the single mbox can be a simpler solution.
Hope that will be useful information for you. If not, feel free to ask more.
from sobjectizer.
Thanks for the prompt response. I think a single mailbox for all devices is good, because the MQTT translation code can extract the device name from the topic name and embed that into the message. So the question regarding how to handle the devices is solved.
What remains is how to handle the different message types, i.e., if the devices send and receive different parameters which could in principle be represented by the same class (e.g. "device1/measurementA", "device1/measurementB", "device1/setpoint", "device1/limit"). If I were to use the same class for those messages, then I would need to use different mboxes (e.g "AllDevices/measurementA", "AllDevices/measurementB", etc). On the other hand, I could create "dummy" subclasses and that would allow me to use the same mbox for all parameters.
e.g. I could do something like:
struct base_sensor_message : public so_5::message_t {
sensor_id_t id_;
value_t val_;
};
struct measurement_a : public base_sensor_message {};
struct measurement_b : public base_sensor_message {};
struct setpoint : public base_sensor_message {};
..etc..
Since I'm not familiar with the library, I don't know which one is the better approach.
from sobjectizer.
I usually use the approach with a base class with empty subclasses, just like you showed in the code example.
from sobjectizer.
@eao197 Thank you very much.
from sobjectizer.
Related Issues (20)
- Asynchrony of register_coop HOT 4
- Documentation for message_holder_t has to be extended HOT 1
- A usage example for agent_t::limit_then_redirect method in API Reference HOT 1
- [Design] Your opinion on expressing agent intent HOT 2
- Deprecation of coop_t::deregister and coop_t::deregister_normally methods HOT 1
- [idea] An emergency stop of SOEnv on an exception in noexcept context HOT 1
- `so_evt_finish` not called until `so_evt_start` is running? HOT 2
- Should agent_t::so_drop_subscription* methods be marked as noexcept? HOT 1
- Should delivery filters be checked for noexcept-ness?
- bind_and_transform HOT 10
- so_5::details::make_message_instance_impl metafunction doesn't set message mutability flag properly HOT 1
- limit_then_transform for mutable messages HOT 1
- Allow `const auto &` as an argument for delivery filter in single/multi_sink_binding HOT 1
- Should there be agent_t::so_disp_binder() and agent_t::so_coop_default_disp_binder() methods? HOT 2
- [idea] Make so5extra's revocable timers the default implementation for timers in SObjectizer
- Another constructor for wrapped_env_t that waits completion of init-function HOT 1
- Use of message limits and state_t::time_limit
- Optional name for an agent? HOT 2
- New method `as_string_view` for so_5::stats::prefix_t and so_5::stats::suffix_t HOT 1
- SO_5_TYPE shouldn't be used for so_5::stats::messages::quantity
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sobjectizer.