Late-joining subscribers without keeping publisher alive?

[MusinDanil]

Hi, I'm working on a use case where a lot of messages are just state - bool flags, settings, configuration, calibration data, etc. I'd like late-joining subscribers to receive this state from history. Currently, this requires the publisher to periodically call update_connections() to deliver history to new subscribers. This creates a dependency where the publisher must actively participate in delivery, even though the data is already in shared memory via history_size.

Question: Is there a pattern or planned feature where history delivery happens without publisher-side action? For example, the publisher might have exited, crashed, or simply shouldn't need to know about new subscribers. I understand this could be done with a plain struct in shared memory, but iceoryx2 provides valuable features like synchronization via message timestamps and headers that would be lost with a manual approach. Is keeping publishers active for history delivery the intended pattern, or am I missing something? Thanks!

[elBoberido]

@MusinDanil Maybe not exactly what you want but did you look at the blackboard pattern? Once there is a reader, the writer can shut down and late joiner can open the blackboard to read the data. The only culprit is that there needs to be someone who keeps the blackboard service alive.

[MusinDanil]

Thank you for the answer!
I was aware of the blackboard pattern, but I was hoping to avoid the manual logic of copying data between pub-sub and blackboard services on every publish. I guess for now I'll either:

• Keep publishers alive with periodic update_connections() calls
• Implement a simple blackboard state store outside of pub-sub

Appreciate the help - looking forward to the C API for blackboard in the future!

[elfenpiff]

@MusinDanil, I want to give you just some more feedback. The issue you raised was also raised by others, but the current architecture has some restrictions that wouldn't allow us to realize this quickly - the publisher port and with it the process owns the publisher's data segment, and with it comes the responsibility to deliver the data (and history). If we could redesign it so that the data segment is owned by the service and a publisher could borrow it, we might be able to adjust the subscriber in a way that it actively acquires the history directly from the data segment. This would require some time.

Appreciate the help - looking forward to the C API for blackboard in the future!

FYI. The C-API is already fully available on the main branch, see: https://github.com/eclipse-iceoryx/iceoryx2/tree/main/examples/c/blackboard