Intra-process delivery
Several requirements, each with a section.
Identifying local endpoints
Endpoints on the same process have the same content on the first 8 octets of their GUID prefix.
GUID_t refactor
Provide methods
is_builtin()
,is_on_same_process_as(other_guid)
andis_on_same_host_as(other_guid)
Consider other improvements
Split Guid.h into three headers (guid, prefix and entity_id)
Converting EntityId_t to uint32_t
Use a union on GuidPrefix_t to efficiently compare parts of it
Getting pointers to local endpoints
Add methods on RTPSDomain to return a pointer to reader/writer given its guid
Should be aware of builtin endpoints
Intra-process reception
The processing of new data on the subscribers is performed by the thread writing the data.
This thread is in charge of copying the CacheChange_t
into the ReaderHistory
and calling NotifyChanges()
.
This decision was taken to maintain consistence with how currently operate the reception threads coming from transport
layer.
User’s documentation should make clear any user’s listener registered to be informed about new changes implies having
blocked both the transport’s reception threads and threads which write data.
Also should explain there is another mechanism to read samples, using the function wait_for_unread_samples()
from the
user’s thread and then taking/reading them.
Current Reader API will be used by local writers to deliver data. The local writer will call processDataMsg
directly.
Readers: management of local writers
When matching a writer, the reader should check if it is on the same process.
Considerations at destruction time
Until now a reader was safe to be destructed because we are sure that no thread will access it. This is possible because:
All events which use the reader were destructed first. Then the event thread will never access the reader.
The reader was deregistered from the
ReceiverResource
objects. Then any reception thread will never access the reader.
Now a reader can be accessed by a writer from the local process. But it was accessed if there was a match with the writer using discovery. Therefore, we should make sure there will be an unmatch with the writer using discovery before the reader is destructed. And this unmatch will be instantly because the EDP builtin endpoints will use intraprocess mechanism.
StatefulReader
No output traffic to local writers should be performed.
Changes on WriterProxy
remote_locators_shrinked
should return an empty vector for local writersTimed event
heartbeat response
should never be started for local writersTimed event
initial acknack
should directly callprocess_acknack
on the local writer
Writers: management of local readers
When matching a reader, the writer should check if it is on the same process.
No output traffic to local readers should be performed.
Samples are sent to local readers using
processDataMsg
.When a local reader is matched, and transient_local durability is used, the reader should automatically receive data with
processDataMsg
.
StatelessWriter
On ReaderLocator::start, no locators should be added when the reader is local
StatefulWriter
Samples sent to local readers are automatically acknowledged
Gaps sent to local readers should directly call
processGapMsg
Heartbeats sent to local readers should directly call
processHeartbeatMsg
Timed events should never be started for local readers, except for an
initial heartbeat
Discovery process
Participant discovery (PDP)
In order to keep the sepparation of domains while on the same process, we will leave participant discovery to the standard mechanism. No intraprocess delivery will be used for builtin PDP readers and writers.
Endpoint discovery (EDP)
We will leave endpoint discovery to the standard mechanism, but builtin endpoints will use the new mechanism to
send/receive WriterProxyData
and ReaderProxyData
to/from the ones on the local process.
Additional considerations
Security
If we rely on the comparison of the GUID to identify endpoints on the same process, those belonging to a secured participant will not be taken into account, as in that case the GUID is recalculated using a hash of the whole participant GUID.
Liveliness
No changes are necessary for the liveliness assertion mechanism, except that manual_by_topic assertions should directly call processHeartbeatMsg
on local readers.
Side effects
This design isolates all message traffic from the wire, that is, tools like wireshark™ will become useless. Given that most of our customers actually run intraprocess code, and report their issues using wireshark™ traces, these changes will create a support nightmare. A workaround may be to supply a flag to inhibits the intraprocess behavior for debugging purposes, stating clearly, that it should be turn off during performance test.
Once a shared memory transport is developed for interprocess purposes, an intraprocess mechanism would be pointless. That’s because the trade off between speed gain and source complexity would be very expensive. From memory consumption point of view using an interprocess discovery database would yield more benefits that having per-process discovery databases.