You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a result of splitting q_entity into multiple files, more entity
related functions are non-static and thus exported from the shared
library. To reduce the risk of name clashes, all exported symbols
related to DDSI entities are prefixed with ddsi_.
Signed-off-by: Dennis Potman <[email protected]>
Copy file name to clipboardexpand all lines: docs/dev/type_discovery.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -24,4 +24,4 @@ Note: In the current type discovery implementation a type lookup request is sent
24
24
25
25
The type discovery implementation introduces a number of additional checks in QoS matching in DDSI (function `qos_match_mask_p`). After the check for matching _topic name_ and _type name_ for reader and writer, the matching function checks if the type information is resolved for the type identifiers of both endpoints. In case any of the types (typically from the proxy endpoint) is not resolved, matching is delayed and a type lookup request for that type identifier is sent.
26
26
27
-
An incoming type lookup reply triggers the (domain scoped) `tl_resolved_cond` condition variable (so that the type lookup API function can check if the requested type is resolved) and triggers the endpoint matching for all proxy endpoints that are using one of the resolved types. This list of proxy endpoints is retrieved from the type lookup meta-data administration. For each of these proxy endpoints the function `update_proxy_endpoint_matching` is called, which tries to connect the proxy endpoint to local endpoints.
27
+
An incoming type lookup reply triggers the (domain scoped) `tl_resolved_cond` condition variable (so that the type lookup API function can check if the requested type is resolved) and triggers the endpoint matching for all proxy endpoints that are using one of the resolved types. This list of proxy endpoints is retrieved from the type lookup meta-data administration. For each of these proxy endpoints the function `ddsi_update_proxy_endpoint_matching` is called, which tries to connect the proxy endpoint to local endpoints.
Copy file name to clipboardexpand all lines: docs/dev/volatile_msg_secure.md
+7-7
Original file line number
Diff line number
Diff line change
@@ -92,7 +92,7 @@ It is also used to determine the gap information that is added to samples to a s
92
92
### Heartbeats
93
93
94
94
A writer is triggered to send heartbeats once in a while. Normally, that is broadcasted. But, for the volatile secure writer, it has to be send to each reader specifically. The heartbeat submessage that is send to each reader individually is encoded with a reader specific key. This key is generated from the shared secret which was determined during the authentication phase.
95
-
95
+
96
96
When a writer should send heartbeats, ```handle_xevk_heartbeat()``` is called. For the volatile secure writer, the control is immediately submitted to ```send_heartbeat_to_all_readers()```. This will add heartbeat submessages to an rtps message for every reader it deems necessary.
97
97
98
98
@@ -111,15 +111,15 @@ Notes</br>
111
111
112
112
The following elements are added to the data structures:
113
113
114
-
* struct wr_prd_match::lst_seq : Highest seq send to this reader used when filter is applied
115
-
* struct pwr_rd_match::last_seq : Reader specific last received sequence number from the writer.
116
-
* struct proxy_writer::uses_filter : Indicates that a content-filter is active
117
-
* struct proxy_reader::filter : The filter to apply for this specific reader
114
+
* struct ddsi_wr_prd_match::lst_seq : Highest seq send to this reader used when filter is applied
115
+
* struct ddsi_pwr_rd_match::last_seq : Reader specific last received sequence number from the writer.
116
+
* struct ddsi_proxy_writer::uses_filter : Indicates that a content-filter is active
117
+
* struct ddsi_proxy_reader::filter : The filter to apply for this specific reader
118
118
119
119
Functions added:
120
120
121
-
* writer_hbcontrol_p2p : This function creates a heartbeat destined for a specific reader. The volatile secure writer will use an submessage encoding which uses a distinct key for each reader. Therefor a reader specific heartbeat is needed.
122
-
* nn_defrag_prune : When a volatile secure reader is deleted then the defragmentation administration could still contain messages destined for this reader. This function removes these messages from the defragmentation administration.
121
+
* writer_hbcontrol_p2p : This function creates a heartbeat destined for a specific reader. The volatile secure writer will use an submessage encoding which uses a distinct key for each reader. Therefor a reader specific heartbeat is needed.
122
+
* nn_defrag_prune : When a volatile secure reader is deleted then the defragmentation administration could still contain messages destined for this reader. This function removes these messages from the defragmentation administration.
123
123
* volatile_secure_data_filter : The filter applied to the secure volatile messages which filters on the destination participant guid.
124
124
* write_sample_p2p_wrlock_held : This function writes a message to a particular reader.
0 commit comments