|
RTI Connext Java API Version 7.6.0
|
<<extension>> QoS related to the reliable writer protocol defined in RTPS. More...
Inherits Struct.
Public Attributes | |
| int | low_watermark |
| <<extension>> When the number of unacknowledged samples in the current send window of a reliable writer meets or falls below this threshold, the com.rti.dds.infrastructure.StatusKind.StatusKind.RELIABLE_WRITER_CACHE_CHANGED_STATUS is considered to have changed. More... | |
| int | high_watermark |
| <<extension>> When the number of unacknowledged samples in the current send window of a reliable writer meets or exceeds this threshold, the com.rti.dds.infrastructure.StatusKind.StatusKind.RELIABLE_WRITER_CACHE_CHANGED_STATUS is considered to have changed. More... | |
| final Duration_t | heartbeat_period |
| <<basic>> <<extension>> The period at which to send heartbeats. More... | |
| final Duration_t | fast_heartbeat_period |
| <<basic>> <<extension>> An alternative heartbeat period used when a reliable writer needs to flush its unacknowledged samples more quickly. More... | |
| final Duration_t | late_joiner_heartbeat_period |
| <<basic>> <<extension>> An alternative heartbeat period used when a reliable reader joins late and needs to be caught up on cached samples of a reliable writer more quickly than the normal heartbeat rate. More... | |
| final Duration_t | virtual_heartbeat_period |
| <<extension>> The period at which to send virtual heartbeats. Virtual heartbeats inform the reliable reader about the range of samples currently present, for each virtual GUID, in the reliable writer's queue. More... | |
| int | samples_per_virtual_heartbeat |
| <<extension>> The number of samples that a reliable writer has to publish before sending a virtual heartbeat. More... | |
| int | max_heartbeat_retries |
| <<extension>> The maximum number of periodic heartbeat retries before marking a remote reader as inactive. More... | |
| boolean | inactivate_nonprogressing_readers |
| <<extension>> Whether to treat remote readers as inactive when their NACKs do not progress More... | |
| int | heartbeats_per_max_samples |
| <<extension>> The number of piggyback heartbeats sent per max send window. More... | |
| final Duration_t | min_nack_response_delay = new Duration_t() |
| <<extension>> The minimum delay to respond to a NACK or NACK_FRAG. More... | |
| final Duration_t | max_nack_response_delay = new Duration_t() |
| <<extension>> The maximum delay to respond to a NACK or NACK_FRAG. More... | |
| final Duration_t | nack_suppression_duration |
| <<extension>> The duration for ignoring consecutive NACKs/NACK_FRAGs that may trigger redundant repairs. More... | |
| int | max_bytes_per_nack_response |
| <<extension>> The maximum total message size when resending rejected samples or data fragments. More... | |
| final Duration_t | disable_positive_acks_min_sample_keep_duration |
| <<extension>> The minimum duration a sample is queued for ACK-disabled readers. More... | |
| final Duration_t | disable_positive_acks_max_sample_keep_duration |
| <<extension>> The maximum duration a sample is queued for ACK-disabled readers. More... | |
| boolean | disable_positive_acks_enable_adaptive_sample_keep_duration |
| [DEPRECATED] <<extension>> Enables dynamic adjustment of sample keep duration in response to congestion. More... | |
| int | disable_positive_acks_decrease_sample_keep_duration_factor |
| [DEPRECATED] <<extension>> Controls rate of contraction of dynamic sample keep duration. More... | |
| int | disable_positive_acks_increase_sample_keep_duration_factor |
| [DEPRECATED] <<extension>> Controls rate of growth of dynamic sample keep duration. More... | |
| int | min_send_window_size |
| <<basic>> <<extension>> Minimum size of send window of unacknowledged samples More... | |
| int | max_send_window_size |
| <<basic>> <<extension>> Maximum size of send window of unacknowledged samples More... | |
| final Duration_t | send_window_update_period |
| <<extension>> Period in which send window may be dynamically changed More... | |
| int | send_window_increase_factor |
| <<extension>> Increases send window size by this percentage when reacting dynamically to network conditions More... | |
| int | send_window_decrease_factor |
| <<extension>> Decreases send window size by this percentage when reacting dynamically to network conditions More... | |
| int | multicast_resend_threshold |
| <<extension>> The minimum number of requesting readers needed to trigger a multicast resend More... | |
| boolean | enable_multicast_periodic_heartbeat |
| <<extension>> Whether periodic heartbeat messages are sent over multicast More... | |
| boolean | disable_repair_piggyback_heartbeat |
| <<extension>> Prevents piggyback heartbeats from being sent with repair samples More... | |
<<extension>> QoS related to the reliable writer protocol defined in RTPS.
It is used to configure a reliable writer according to RTPS protocol.
The reliability protocol settings are applied to batches instead of individual data samples when batching is enabled.
| int low_watermark |
<<extension>> When the number of unacknowledged samples in the current send window of a reliable writer meets or falls below this threshold, the com.rti.dds.infrastructure.StatusKind.StatusKind.RELIABLE_WRITER_CACHE_CHANGED_STATUS is considered to have changed.
This value is measured in units of samples, except with batching configurations where it is measured in units of batches.
The value must be greater than or equal to zero and strictly less than high_watermark.
The high and low watermarks are used for switching between the regular and fast heartbeat rates (com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.heartbeat_period and com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.fast_heartbeat_period, respectively). When the number of unacknowledged samples in the queue of a reliable com.rti.dds.publication.DataWriter meets or exceeds high_watermark, the com.rti.dds.infrastructure.StatusKind.StatusKind.RELIABLE_WRITER_CACHE_CHANGED_STATUS is changed, and the DataWriter will start heartbeating at com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.fast_heartbeat_period. When the number of samples meets or falls below low_watermark, com.rti.dds.infrastructure.StatusKind.StatusKind.RELIABLE_WRITER_CACHE_CHANGED_STATUS is changed, and the heartbeat rate will return to the "normal" rate (com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.heartbeat_period).
[default] 0
[range] [0, 100 million], < high_watermark
| int high_watermark |
<<extension>> When the number of unacknowledged samples in the current send window of a reliable writer meets or exceeds this threshold, the com.rti.dds.infrastructure.StatusKind.StatusKind.RELIABLE_WRITER_CACHE_CHANGED_STATUS is considered to have changed.
This value is measured in units of samples, except with batching configurations where it is measured in units of batches.
The value must be strictly greater than low_watermark and less than or equal to a maximum that depends on the container QoS policy:
In com.rti.dds.domain.DomainParticipantQos.discovery_config:
For com.rti.dds.infrastructure.DiscoveryConfigQosPolicy.publication_writer
high_watermark<= com.rti.dds.infrastructure.AllocationSettings_t.max_count in com.rti.dds.infrastructure.DomainParticipantResourceLimitsQosPolicy.local_writer_allocation
For com.rti.dds.infrastructure.DiscoveryConfigQosPolicy.subscription_writer
high_watermark<= com.rti.dds.infrastructure.AllocationSettings_t.max_count in com.rti.dds.infrastructure.DomainParticipantResourceLimitsQosPolicy.local_reader_allocation
In com.rti.dds.publication.DataWriterQos.protocol:
For com.rti.dds.infrastructure.DataWriterProtocolQosPolicy.rtps_reliable_writer,
high_watermark<=com.rti.dds.infrastructure.ResourceLimitsQosPolicy.max_samples if batching is disabled. Otherwise,
high_watermark<=com.rti.dds.infrastructure.DataWriterResourceLimitsQosPolicy.max_batches high_watermark<=com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.max_send_window_size
[default] 1
[range] [1, 100 million] or com.rti.dds.infrastructure.ResourceLimitsQosPolicy.LENGTH_UNLIMITED, > low_watermark <= maximum which depends on the container policy
| final Duration_t heartbeat_period |
<<basic>> <<extension>> The period at which to send heartbeats.
A reliable writer will send periodic heartbeats at this rate.
[default] The default value depends on the container policy:
[range] [1 nanosec,1 year], >= com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.fast_heartbeat_period, >= com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.late_joiner_heartbeat_period
| final Duration_t fast_heartbeat_period |
<<basic>> <<extension>> An alternative heartbeat period used when a reliable writer needs to flush its unacknowledged samples more quickly.
This heartbeat period will be used when the number of unacknowledged samples in the cache of a reliable writer meets or exceeds the writer's high watermark and has not subsequently dropped to the low watermark. The normal period will be used at all other times.
This period must not be slower (i.e. must be of the same or shorter duration) than the normal heartbeat period.
[default] The default value depends on the container policy:
[range] [1 nanosec,1 year], <= com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.heartbeat_period
| final Duration_t late_joiner_heartbeat_period |
<<basic>> <<extension>> An alternative heartbeat period used when a reliable reader joins late and needs to be caught up on cached samples of a reliable writer more quickly than the normal heartbeat rate.
This heartbeat period will be used when a reliable reader joins after a reliable writer with non-volatile durability has begun publishing samples. Once the reliable reader has received all cached samples, it will be serviced at the same rate as other reliable readers.
This period must not be slower (i.e., must be of the same or shorter duration) than the normal heartbeat period.
A reliable writer will use whichever heartbeat period is faster, the current heartbeat period being used for other reliable readers or the com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.late_joiner_heartbeat_period, to service the late joining reader. This means that if the com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.fast_heartbeat_period is currently being used and is faster than the late_joiner_heartbeat_period, then the fast_heartbeat_period will continue to be used for the late joiner as well.
[default] The default value depends on the container policy:
[range] [1 nanosec,1 year], <= com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.heartbeat_period
| final Duration_t virtual_heartbeat_period |
<<extension>> The period at which to send virtual heartbeats. Virtual heartbeats inform the reliable reader about the range of samples currently present, for each virtual GUID, in the reliable writer's queue.
A reliable writer will send periodic virtual heartbeats at this rate.
[default] The default value depends on the container policy:
[range] > 1 nanosec, com.rti.dds.infrastructure.Duration_t.DURATION_INFINITE, or com.rti.dds.infrastructure.Duration_t.AUTO
| int samples_per_virtual_heartbeat |
<<extension>> The number of samples that a reliable writer has to publish before sending a virtual heartbeat.
[default] com.rti.dds.infrastructure.ResourceLimitsQosPolicy.LENGTH_UNLIMITED
[range] [1,1000000], com.rti.dds.infrastructure.ResourceLimitsQosPolicy.LENGTH_UNLIMITED
| int max_heartbeat_retries |
<<extension>> The maximum number of periodic heartbeat retries before marking a remote reader as inactive.
When a remote reader has not acked all the samples the reliable writer has in its queue, and max_heartbeat_retries number of periodic heartbeats has been sent without receiving any ack/nack back, the remote reader will be marked as inactive (not alive) and be ignored until it resumes sending ack/nack.
Note that piggyback heartbeats do NOT count towards this value.
[default] 150
[range] [1, 1 million] or com.rti.dds.infrastructure.ResourceLimitsQosPolicy.LENGTH_UNLIMITED
| boolean inactivate_nonprogressing_readers |
<<extension>> Whether to treat remote readers as inactive when their NACKs do not progress
Nominally, a remote reader is marked inactive when a successive number of periodic heartbeats equal or greater than com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.max_heartbeat_retries have been sent without receiving any ack/nacks back.
By setting this com.rti.dds.infrastructure.true, it changes the conditions of inactivating a remote reader: a reader will be considered inactive when it either does not send any ack/nacks or keeps sending non-progressing nacks for com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.max_heartbeat_retries number of heartbeat periods, where a non-progressing nack is one whose oldest sample requested has not advanced from the oldest sample requested of the previous nack.
[default] com.rti.dds.infrastructure.false
| int heartbeats_per_max_samples |
<<extension>> The number of piggyback heartbeats sent per max send window.
When a DataWriter is configured with a fixed send window size (com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.min_send_window_size is equal to effective max_send_window_size), a piggyback heartbeat is sent every [(effective max send window size/heartbeats_per_max_samples)] number of samples written.
Otherwise, the number of piggyback heartbeats sent is scaled according to the current size of the send window. For example, consider a com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.heartbeats_per_max_samples of 50. If the current send window size is 100, a piggyback heartbeat will be sent every 2 samples. If the send window size grows to 150, a piggyback heartbeat will be sent every 3 samples, and so on. Additionally, when the send window size grows, a piggyback heartbeat is sent with the next sample. (If it weren't, the sending of that heartbeat could be delayed, since the heartbeat rate scales with the increasing window size.)
The effective max send window is calculated as follows:
Without batching:
min (com.rti.dds.infrastructure.ResourceLimitsQosPolicy.max_samples, com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.max_send_window_size)
With batching:
min (com.rti.dds.infrastructure.DataWriterResourceLimitsQosPolicy.max_batches, com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.max_send_window_size)
If heartbeats_per_max_samples is set to zero, no piggyback heartbeats will be sent.
If current send window size is com.rti.dds.infrastructure.ResourceLimitsQosPolicy.LENGTH_UNLIMITED, 100 million is assumed as the effective max send window.
[default] The default value depends on the container policy:
[range] [0, 100 million]
heartbeats_per_max_samples<= com.rti.dds.infrastructure.ResourceLimitsQosPolicy.max_samples if batching is disabled. Otherwise:
heartbeats_per_max_samples<= com.rti.dds.infrastructure.DataWriterResourceLimitsQosPolicy.max_batches
heartbeats_per_max_samples<= com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.max_send_window_size
| final Duration_t min_nack_response_delay = new Duration_t() |
<<extension>> The minimum delay to respond to a NACK or NACK_FRAG.
When a reliable writer receives a NACK or a NACK_FRAG from a remote reader, the writer can choose to delay a while before it sends repair samples/fragments or a heartbeat. This sets the value of the minimum delay.
Delaying repairs can lower the amount of duplicate repair data sent to the remote reader. If the writer receives the same NACKs or NACK_FRAGs back-to-back within this wait time, it will combine them into one repair action.
[default] 0 seconds
[range] [0, 1 day], <= max_nack_response_delay
| final Duration_t max_nack_response_delay = new Duration_t() |
<<extension>> The maximum delay to respond to a NACK or NACK_FRAG.
This sets the value of maximum delay between receiving a NACK or a NACK_FRAG and sending repair samples/fragments or a heartbeat.
[default] The default value depends on the container policy:
[range] [0,1 day], >= min_nack_response_delay
| final Duration_t nack_suppression_duration |
<<extension>> The duration for ignoring consecutive NACKs/NACK_FRAGs that may trigger redundant repairs.
A reliable writer may receive consecutive NACKs/NACK_FRAGs within a short duration from a remote reader that will trigger the sending of redundant repair messages.
This specifies the duration during which consecutive NACKs/NACK_FRAGs are ignored to prevent redundant repairs from being sent.
A redundant NACK is a NACK that requests the same or lower first sequence number (SN) than the last NACK from the same reader.
A redundant NACK_FRAG is a NACK_FRAG that requests the same first fragment number for a sample as the last NACK_FRAG from the same reader.
The suppression duration applies separately to NACKs and NACK_FRAGS. For example, replying to a NACK_FRAG message in between receiving two NACK messages will not cause the second NACK message to be suppressed if the two NACK messages are received more than the suppression duration apart.
[default] 0 seconds
[range] [0, 1 day]
| int max_bytes_per_nack_response |
<<extension>> The maximum total message size when resending rejected samples or data fragments.
As part of the reliable communication protocol, DataWriters send heartbeat (HB) messages to their DataReaders. Each HB message contains the sequence number of the most recent sample sent by the DataWriter.
In response, a DataReader may send a negative acknowledgement (NACK) message, indicating what sequence numbers it did not receive, if any. If the samples were fragmented, it can also send a NACK_FRAG requesting the fragments of a sample that did not arrive. If the DataReader is missing some samples or fragments, the DataWriter will send them again.
max_bytes_per_nack_response determines the maximum size of the message sent by the DataWriter in response to a NACK or NACK_FRAG. This message may contain multiple samples or fragments. The DataWriter will always send at least one message, even if the size of that message exceeds the max_bytes_per_nack_response value.
If the total size of all samples or fragments that needs to be resent is larger than max_bytes_per_nack_response, the remaining samples or fragments will be resent the next time a NACK or NACK_FRAG arrives.
Note: If com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.min_nack_response_delay and com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.max_nack_response_delay are both com.rti.dds.infrastructure.Duration_t.ZERO (which means repairs are processed immediately), this limit applies separately to NACKs and NACK_FRAGs: repairing a NACK in this case does not affect the maximum size of a NACK_FRAG response and vice versa. Otherwise, the limit applies to the total size of the response, including received NACKs and NACK_FRAGs.
[default] The default value depends on the container policy:
[range] [0, 1 GB]
| final Duration_t disable_positive_acks_min_sample_keep_duration |
<<extension>> The minimum duration a sample is queued for ACK-disabled readers.
When positive ACKs are disabled for a data writer (com.rti.dds.infrastructure.DataWriterProtocolQosPolicy.disable_positive_acks = com.rti.dds.infrastructure.true) or a data reader (com.rti.dds.infrastructure.DataReaderProtocolQosPolicy.disable_positive_acks = com.rti.dds.infrastructure.true), a sample is available from the data writer's queue for at least this duration, after which the sample may be considered to be acknowledged.
[default] 1 millisecond
[range] [0,1 year], <= com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_max_sample_keep_duration
| final Duration_t disable_positive_acks_max_sample_keep_duration |
<<extension>> The maximum duration a sample is queued for ACK-disabled readers.
When positive ACKs are disabled for a data writer (com.rti.dds.infrastructure.DataWriterProtocolQosPolicy.disable_positive_acks = com.rti.dds.infrastructure.true) or a data reader (com.rti.dds.infrastructure.DataReaderProtocolQosPolicy.disable_positive_acks = com.rti.dds.infrastructure.true), a sample is available from the data writer's queue for at most this duration, after which the sample is considered to be acknowledged.
[default] 1 second
[range] [0,1 year], >= com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_min_sample_keep_duration
| boolean disable_positive_acks_enable_adaptive_sample_keep_duration |
[DEPRECATED] <<extension>> Enables dynamic adjustment of sample keep duration in response to congestion.
For dynamic networks where a static minimum sample keep duration may not provide sufficient performance or reliability, setting com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_enable_adaptive_sample_keep_duration = com.rti.dds.infrastructure.true, enables the sample keep duration to be dynamically adjusted to adapt to network conditions. The keep duration changes according to the detected level of congestion, which is determined to be proportional to the rate of NACKs received. An adaptive algorithm automatically controls the keep duration to optimize throughput and reliability.
To relieve high congestion, the keep duration is increased to effectively decrease the send rate; this lengthening of the keep duration is controlled by com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_increase_sample_keep_duration_factor. Alternatively, when congestion is low, the keep duration is decreased to effectively increase send rate; this shortening of the keep duration is controlled by com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_decrease_sample_keep_duration_factor.
The lower and upper bounds of the dynamic sample keep duration are set by com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_min_sample_keep_duration and com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_max_sample_keep_duration, respectively.
When com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_enable_adaptive_sample_keep_duration = com.rti.dds.infrastructure.false, the sample keep duration is set to com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_min_sample_keep_duration .
[default] com.rti.dds.infrastructure.true
| int disable_positive_acks_decrease_sample_keep_duration_factor |
[DEPRECATED] <<extension>> Controls rate of contraction of dynamic sample keep duration.
Used when com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_enable_adaptive_sample_keep_duration = com.rti.dds.infrastructure.true.
When the adaptive algorithm determines that the keep duration should be decreased, this factor (a percentage) is multiplied with the current keep duration to get the new shorter keep duration. For example, if the current keep duration is 20 milliseconds, using the default factor of 95% would result in a new keep duration of 19 milliseconds.
[default] 95
[range] <= 100
| int disable_positive_acks_increase_sample_keep_duration_factor |
[DEPRECATED] <<extension>> Controls rate of growth of dynamic sample keep duration.
Used when com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.disable_positive_acks_enable_adaptive_sample_keep_duration = com.rti.dds.infrastructure.true.
When the adaptive algorithm determines that the keep duration should be increased, this factor (a percentage) is multiplied with the current keep duration to get the new longer keep duration. For example, if the current keep duration is 20 milliseconds, using the default factor of 150% would result in a new keep duration of 30 milliseconds.
[default] 150
[range] >= 100
| int min_send_window_size |
<<basic>> <<extension>> Minimum size of send window of unacknowledged samples
A com.rti.dds.publication.DataWriter has a limit on the number of unacknowledged samples in-flight at a time. This send window can be configured to have a minimum size (this field) and a maximum size (max_send_window_size). The send window can dynamically change, between the min and max sizes, to throttle the effective send rate in response to changing network congestion, as measured by negative acknowledgements received.
When a variable sized send window is used (i.e., when min_send_window_size and max_send_window_size are not set to the same value) the send window is initialized to min_send_window_size.
[default] com.rti.dds.infrastructure.ResourceLimitsQosPolicy.LENGTH_UNLIMITED
[range] > 0, <= max_send_window_size, or com.rti.dds.infrastructure.ResourceLimitsQosPolicy.LENGTH_UNLIMITED
| int max_send_window_size |
<<basic>> <<extension>> Maximum size of send window of unacknowledged samples
A com.rti.dds.publication.DataWriter has a limit on the number of unacknowledged samples in-flight at a time. This send window can be configured to have a minimum size (min_send_window_size) and a maximum size (this field). The send window can dynamically change, between the min and max sizes, to throttle the effective send rate in response to changing network congestion, as measured by negative acknowledgements received.
When a variable sized send window is used (i.e., when min_send_window_size and max_send_window_size are not set to the same value) the send window is initialized to min_send_window_size.
When both min_send_window_size and max_send_window_size are com.rti.dds.infrastructure.ResourceLimitsQosPolicy.LENGTH_UNLIMITED, then either com.rti.dds.infrastructure.ResourceLimitsQosPolicy.max_samples (for non-batching) or com.rti.dds.infrastructure.DataWriterResourceLimitsQosPolicy.max_batches (for batching) serves as the effective max_send_window_size. When com.rti.dds.infrastructure.ResourceLimitsQosPolicy.max_samples (for non-batching) or com.rti.dds.infrastructure.DataWriterResourceLimitsQosPolicy.max_batches (for batching) is less than max_send_window_size, then it serves as the effective max_send_window_size. If it is also less than min_send_window_size, then effectively both min and max send window sizes are equal to max_samples or max_batches.
In addition, the low and high watermarks are scaled down linearly to stay within the current send window size, and the full reliable queue status is set when the send window is full.
[default] com.rti.dds.infrastructure.ResourceLimitsQosPolicy.LENGTH_UNLIMITED
[range] > 0, >= min_send_window_size, or com.rti.dds.infrastructure.ResourceLimitsQosPolicy.LENGTH_UNLIMITED
| final Duration_t send_window_update_period |
<<extension>> Period in which send window may be dynamically changed
The com.rti.dds.publication.DataWriter's send window will dynamically change, between the min and max send window sizes, to throttle the effective send rate in response to changing network congestion, as measured by negative acknowledgements received.
The change in send window size happens at this update period, whereupon the send window is either increased or decreased in size according to the increase or decrease factors, respectively.
[default] The default value depends on the container policy:
[range] > [0,1 year]
| int send_window_increase_factor |
<<extension>> Increases send window size by this percentage when reacting dynamically to network conditions
The com.rti.dds.publication.DataWriter's send window will dynamically change, between the min and max send window sizes, to throttle the effective send rate in response to changing network congestion, as measured by negative acknowledgements received.
After an update period during which no negative acknowledgements were received, the send window will be increased by this factor. The factor is treated as a percentage, where a factor of 150 would increase the send window by 150%. The increased send window size will not exceed the max_send_window_size.
[default] 105
[range] > 100
| int send_window_decrease_factor |
<<extension>> Decreases send window size by this percentage when reacting dynamically to network conditions
The com.rti.dds.publication.DataWriter's send window will dynamically change, between the min and max send window sizes, to throttle the effective send rate in response to changing network congestion, as measured by negative acknowledgements received.
When increased network congestion causes a negative acknowledgement to be received by a writer, the send window will be decreased by this factor to throttle the effective send rate. The factor is treated as a percentage, where a factor of 80 would decrease the send window to 80% of its previous size. The decreased send window size will not be less than the min_send_window_size.
[default] The default value depends on the container policy:
[range] [0, 100]
| int multicast_resend_threshold |
<<extension>> The minimum number of requesting readers needed to trigger a multicast resend
Given readers with multicast destinations, when a reader NACKs for samples to be resent, the writer can either resend them over unicast or multicast. In order for the writer to resend over multicast, this threshold is the minimum number of readers of the same multicast group that the writer must receive NACKs from within a single response-delay. This allows the writer to coalesce near-simultaneous unicast resends into a multicast resend. Note that a threshold of 1 means that all resends will be sent over multicast, if available.
[default] 2
[range] [>= 1]
| boolean enable_multicast_periodic_heartbeat |
<<extension>> Whether periodic heartbeat messages are sent over multicast
When enabled, if a reader has a multicast destination, then the writer will send its periodic HEARTBEAT messages to that destination. Otherwise, if not enabled or the reader does not have a multicast destination, the writer will send its periodic HEARTBEATs over unicast.
[default] com.rti.dds.infrastructure.false
| boolean disable_repair_piggyback_heartbeat |
<<extension>> Prevents piggyback heartbeats from being sent with repair samples
When samples are repaired, the com.rti.dds.publication.DataWriter resends com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.max_bytes_per_nack_response bytes and a piggyback heartbeat with each message. You can configure the com.rti.dds.publication.DataWriter to not send the piggyback heartbeat and instead rely on the com.rti.dds.infrastructure.RtpsReliableWriterProtocol_t.late_joiner_heartbeat_period to control the throughput used to repair samples. This field is mutable only for com.rti.dds.infrastructure.DataWriterProtocolQosPolicy.rtps_reliable_writer. [default] com.rti.dds.infrastructure.false