Use different message types or different mboxes?

[jcarrano]

I'm quite impressed by SObjectizer and I want to convert my application to use it. However, at the moment I'm having problems to understand the design I should follow when defining messages and mboxes:

When should I use different message types and when should I use the same types on different mailboxes?

My application controls a number of identical devices (the devices are not known until start-up). Most of the messages to and from the devices are of the same basic type (a triplet of real numbers), although they mean different things. My idea is to have several actors which listen to messages from all devices and do some state estimation and a few which consume both estimations and observations and act a controllers.

In my message broker (MQTT) I have one topic per device (e.g. "device1/measured", "device1/setpoint", "device1/status") because that's the way MQTT is supposed to be used, but I don't believe it is a good idea to have one mbox per device in the application.

I guess my options are:

1. One generic "board" mbox, with different message subclasses to identify the topic of the message (eg, define "Measured", "Setpoint", "Status", and derive both "Measured" and "Setpoint" from the same class).
2. One mbox per topic, use the same class for messages whose data is essentially the same (e.g. have a "Measured" and "Setpoint" mboxes, and publish the same type of objects to both).
3. A combination of (1) and (2): several mboxes and different message classes too.

Regards,

Juan.

[eao197]

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.

[jcarrano]

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.

[eao197]

I usually use the approach with a base class with empty subclasses, just like you showed in the code example.

[jcarrano]

@eao197 Thank you very much.