This topic is an off-shoot from another, on which I Made a Mistake :) As Neil Gaiman says... "If you're making mistakes, it means you're out there doing something."
The upshot of the pertinant bit of the discussion was what happens when KEEP_LAST is set to some arbitrary N, the Writer side cache is filled with unacknowledged samples, and the application calls .write(...) on that writer. My (imperfect) understanding (alas!) was that the writer would block until a slot was available (gray used to indicate incorrect information).
The writer doesn't hold on to keep_last data, even if it wasn't acknowledged... unexpected. I guess I assumed "keep_last" semantics were "Keep the last, unacknowledged, instances". Turns out that the semantics of KEEP_LAST are exactly that. If your application has a KEEP_LAST == 1 then exactly 1 will be kept, and then replaced on the next .write(...), because the previous is now no longer relevant.
Reading through the protocol, RTPS would in this event (eventually) send a gap submessage (8.3.7.4) to indicate that the dropped sequences were no longer relevant, which is different from sending a heartbeat to indicate that the sample is no longer available. My assumption here is that the heartbeat, which includes information about what samples are available, would show that the sample was no longer available and that the reader should react accordingly.
The consequence is that a reader then only has a window of opportunity to request a missed instance.
What happens on the Reader side... when a gap submessage is sent, will the reader's state/callback on_sample_lost get called? If the underlying key concept is relevance (gap == sample was no longer relevent, heartbeat == sample is no longer available), then assumption is that on_sample_lost is NOT called, because the sample was not relevant according to the writer. A quick test validates the behavior: Reliable, keep_last 3, send sequence #0-4, artificial pause on the reader before reading, only sequence #2-4 are displayed, and no on_sample_lost.
Feel free to continue the discussion below.
rip
Hi Rip,
If a sample in the history cache is replaced with bacause the History kind is set to
KEEP_LASTand newer samples are written then those 'replaced' samples are not considered lost.The setting of
KEEP_LASTwas telling theDataWriterthat it is not important to communicate every single change to a particilar instance. Rather the important thing is to communicate the 'latest values'. This is actually quite helpful in situations where samples are written faster than certainDataReaderscan handle. TheDataWritercan just keep and send the most recent/relevant data per instance rather than of delaying the writer, or consuming a lot of memory saving the intermediate values. Of course this is only sensible for certain kinds of data, like samples of continuous data signals. It is not appropriate for messages such as alarms. Those other types of data where all samples must be delivered should set HISTORY kind toKEEP_ALL.As you suggested, at the wire protocol those samples replaced due to history result in RTPS
GAPmessages. As you also said theGAPtells theDataReaderthat those samples are not relevant to theDataReader. This does not indicate the samples were lost so theon_sample_lostis indeed not called. Incidentally, this mechanism is also used for writer-side content filtering. Samples that are filtered by theDataWriterfor a specificDataReaderresult onGAPmessages to theDataReaderand are also not considered 'lost'.Gerardo