Currently the configurable streamer allows a configuration hierarchy like this (with some details omitted):
transports: {
zenoh: {
endpoints: [
{
endpoint: "endpoint_zenoh_1",
forwarding: [
"endpoint_mqtt_1",
"endpoint_zenoh_2"
]
},
{
endpoint: "endpoint_zenoh_2",
forwarding: [
"endpoint_zenoh_1",
]
}
]
},
mqtt: {
config_file: "MQTT_CONFIG.json5",
endpoints: [
{
endpoint: "endpoint_mqtt_1",
forwarding: [
"endpoint_zenoh_1",
]
},
]
},
This means there can only ever be a single transport for each protocol, that handles multiple endpoints. This is not enough for some topologies that we want to allow that explicitly require separate transport clients for the same protocol, for example in the case of an mqtt broker inside a vehicle and another one in the cloud.
Todo:
find a way to allow for multiple transports.
this could be done by making each transport a list in the configs and then probably adding some more loops to the broker code.
Ideally the resulting streamer config does not become a huge lot more complicated.
Currently the configurable streamer allows a configuration hierarchy like this (with some details omitted):
This means there can only ever be a single transport for each protocol, that handles multiple endpoints. This is not enough for some topologies that we want to allow that explicitly require separate transport clients for the same protocol, for example in the case of an mqtt broker inside a vehicle and another one in the cloud.
Todo:
find a way to allow for multiple transports.
this could be done by making each transport a list in the configs and then probably adding some more loops to the broker code.
Ideally the resulting streamer config does not become a huge lot more complicated.