History if already connected

[jasperdekeuk]

Is the historyCapacity and historyRequest only relevant for the startup of the client, or can this also be used when already connected?

If we would have

• a publisher running at a cycle time of 10ms and
• a subscriber running at a cycle time of 5ms,

the subscriber will have "NO_CHUNK_AVAILABLE" every 2 cycles.

Would it be possible at that point to call for the previous chunk?
The subscriber should do a cycle every 5ms, making use of the latest data. If no new data has been published, the previous data should be used.

I'm guessing this is more an application for the client/server mechanism, but the history settings made me wonder for such an implementation :)

[elfenpiff]

@jasperdekeuk First thing I think the example here explains some of those questions: https://github.com/eclipse-iceoryx/iceoryx/tree/master/iceoryx_examples/iceoptions

Now to your question. As far as I understand it, the publisher sends always 2 samples in a given time frame and the subscribers acquires only one. This should not lead to NO_CHUNK_AVAILABLE since the subscriber has a safely overflowing queue behind the scenes and the size can be set with the queueCapacity option. If the queue is full the publisher recycles the oldest sample with the newest one.

All the samples stored in the internal queue of the subscriber are always available for the subscriber.

Lets say you have a subscriber queueCapacity size of 3 and send the samples a, b, c, d, e. Then the publisher will override a with d and b with e.
The subscriber is able to acquire now the samples c, d and e.

I hope this clarifies it a bit.

Now to the NO_CHUNK_AVAILABLE thing. This only happens when the underlying mempool of the whole roudi broker has no more chunks left. (here you see how to configure it: https://github.com/eclipse-iceoryx/iceoryx/blob/master/doc/website/advanced/configuration-guide.md#configuring-mempools-for-roudi)
This has in the end nothing to do with the subscriber alone. But if you have multiple services which are using chunks of the same size with a lot of subscribers and those subscribers have filled queues it can happen that your system runs out of chunks. One quick solution is to provide a custom mempool config and increase the amount of chunks for the used size.
Another thing you can do is to reduce the subscribers queue capacity.

Did this answer your question a bit?

[jasperdekeuk]

@elfenpiff thank you very much for your reply!

I was actually thinking the other way around, the publisher sends 1 sample and the subscriber should acquire it 2x.

The publisher publishes a new sample every 10ms -> e.g a,b,c,d,..
The subscriber has a queueCapacity = 1 and checks every 5ms -> a,EMPTY,c,EMPTY,d,..
If the subscriber has at the moment of checking no new data from the publisher, he should take the previous one.
this would result for the subscriber in -> a,a,b,b,c,c,d,d,...

The idea is for the subscriber to always have the "latest snapshot" of the publisher data, independent whether it be new data or not.
It is probably a bit contradictory for the pub-sub mechanism and can (and probably should) be solved with the client-server mechanism.
But the historyCapacity made me wonder, that the chuncks that have already been used are always still available so could maybe be called multiple times by the same subscriber. But this is probably buffering on publisher side and only transferred to subscriber buffer on connect.

[elBoberido]

@jasperdekeuk you are right, the history is only for subscribing. In your case it would indeed be done on the user side. You could for example do the following. Disclainer: this probably does not compile just to get the idea

// container for the latest sample
iox::cxx::optional<iox::popo::Sample<MyType>> latestSample;
// obtain the latest sample; if there is no sample, the old one is still available
subscriber.take().and_then([&] (auto& sample) {
    latestSample = sample;
});

// to access the data do either
latestSample.and_then([&](auto& sample) {
    // do something with the data
});

// or
if (latestSample) {
    auto& sample = latestSample.value();
    // do something with the data
}

You always have the latest sample but need to check whether the optional contains a value anyway for the edge case that you run the subscriber application before the publisher application. Once you have a sample you will always have the latest sample.

[jasperdekeuk]

@elBoberido Thanks! This is indeed what I was looking for.