Overly aggressive sending of ACKNACKs eats bandwidth and causes
unnecessary retransmits and lowers performance; but overly timid sending
of them also reduces performance. This commit reduces the
aggressiveness.
* It keeps more careful track of what ACKNACK (or NACKFRAG) was last
sent and when, suppressing ACKs that don't provide new information for
a few milliseconds and suppressing NACKs for the NackDelay
setting. (The setting was there all long, but it didn't honor it when
the writer asked for a response.)
* It ignores the NackDelay when all that was requested has arrived, or
when it receives a directed heartbeat from a Cyclone peer. The latter
is taken as an indication that no more is following, and allows the
recipient to ask far arbitrary amounts of data and rely on the sender
to limit the retransmit to what seems reasonable. (For NACKFRAG one
can do it in the recipient, but for ACKNACK one cannot, and so one
might as well do it at the sender always.)
* Sufficient state is maintained in the match object for the ACKNACK
generator to decide whether or not to send an ACKNACK following the
rules, and it may decide to send just an ACK even though there is data
missing, or nothing at all.
* If HEARTBEAT processing requires an immediate response, the response
message is generated by the receive thread, but still queued for
transmission. If a delayed response is required, it schedules the
ACKNACK event.
Signed-off-by: Erik Boasson <eb@ilities.com>
This changes a few intertwined things at the same time:
* It allows configuring sending a partial message for large messages,
with a maximum derived from the discovered receive buffer sizes;
* It uses a different message size limit for datagrams that include
retransmits than for those that don't. The argument here is that,
having seen flaky networks where large datagrams cause trouble, it
makes sense to default to sending retransmits as datagrams that fit in
individual packets.
* The best performance is generally obtained using the maximum data gram
size, but the benefits do fall off quite quickly once they are
largish. For flaky networks, it doesn't make sense to go for 64kB
datagrams. This tries to find a reasonable compromise.
* It now packs mutiple fragments into a single DATAFRAG message to
eliminate the cost of using small fragment sizes.
The changes in buffer sizes cause the ddsperf sanity check to fail:
* The larger amounts of unacknowledged data cause the used memory to be
higher, failing the RSS check. Raising the limit seems
reasonable (the alternative would be to configure it back to the old
values, but it is all empirically determined anyway).
* The same also causes the publisher thread to get to run more and the
ping/pong bit gets less of a chance. Using fixed-frequency bursts
helps with this.
This therefore also adjust the test configuration and the thresholds a
bit.
Signed-off-by: Erik Boasson <eb@ilities.com>
* Remove the "plist" and "rawcdr" abuse of the "serdata_default" sample
representation.
* Introduce a new "plist" topic type and a new "pserop" topic type. The
former represents parameter lists as used in discovery, the second
arbitrary samples using the serialiser in ddsi_plist.c.
* Introduce sertopics for each of the built-in "topics" used by the DDSI
discovery protocol using the two new topic types, and reference these
in the readers/writers used in discovery.
* Construct and deconstruct the discovery message by using the
conversion routines for these sample types, rather than fiddling with,
e.g., the baroque interface for adding parameter lists to messages.
* As a consequence, it introduces standardized logging of received and
transmitted discovery data and eliminates the annoying "(null)/(null)"
and "(blob)" descriptions in the trace.
* Limits the dumping of octet sequences in discovery data to the first
100 bytes to make the embedded certificates and permissions
documents (somewhat) manageable.
* Eliminates the (many) null pointer checks on reader/writer topics.
* Fixes the printing of nested sequences in discovery data (not used
before) and the formatting of GUIDs.
Various interfaces remain unchanged and so while this removes cruft from
the core code, it moves some of it into the conversion routines for the
new topic types.
It also now allocates some memory when processing incoming discovery
data, whereas before it had no need to do so. Allowing for aliasing of
data in the new sertopics and adding a way to initialize these specific
types on the stack (both minor changes) suffices for eliminating those
allocations.
Signed-off-by: Erik Boasson <eb@ilities.com>
Check actual topic type before "downcasting"
Signed-off-by: Erik Boasson <eb@ilities.com>
Free the memory we own and is actually allocated
Signed-off-by: Erik Boasson <eb@ilities.com>
Ignore logging newlines if nothing is buffered
Signed-off-by: Erik Boasson <eb@ilities.com>
Suffix data with "(trunc)" one byte earlier
The sample printing code changed over time and now stops as soon as it
can once it has filled up the buffer. As the return value is simply the
number of bytes written, if that number is equal to buffer size less
one (because of the terminating nul) it may or may not have been
truncated, but the likelihood is that it has been. So add the "(trunc)"
suffix once that point has been reached.
Signed-off-by: Erik Boasson <eb@ilities.com>
This is a workaround for interoperability issues, ultimately driven by a
Windows quirk that makes multicast delivery within a machine utterly
unreliable if the transmitting socket is bound to 0.0.0.0 (despite all
sockets having multicast interfaces set correctly) when there are also
sockets transmitting to the same multicast group that have been bound to
non-0.0.0.0. (Note: there may be other factors at play, but this is
what it looks like after experimentation.)
At least Fast-RTPS in some versions binds the socket it uses for
transmitting multicasts to non-0.0.0.0, so interoperability with
Fast-RTPS on Windows requires us to bind the socket we use for
transmitting multicasts (which was the same as the one we use for
receiving unicast data) also to non-0.0.0.0 or our multicasts get
dropped often.
This would work fine if other implementations honoured the set of
advertised addresses. However, at least Fast-RTPS and Connext (in some
versions) fail to do this and happily substitute 127.0.0.1 for the
advertised IP address. If we bind to, e.g., 192.168.1.1, then suddenly
those packets won't arrive anymore, breaking interoperability.
The only work around is to use a separate socket for sending.
Signed-off-by: Erik Boasson <eb@ilities.com>
the destination cache of the network stack is in a certain state. The issue
is resolved by binding unicast sockets (incoming unicast and all outgoing
traffic) to the address of the interface instead of inaddr_any (0.0.0.0).
Set the new configuration option internal/BindUnicastToInterfaceAddr to
false to get the old behavior.
Co-authored-by: Erik Boasson <eb@ilities.com>
Signed-off-by: Dennis Potman <dennis.potman@adlinktech.com>
* Fix some typos.
Signed-off-by: ChenYing Kuo <evshary@gmail.com>
* Also update q_config.c, cyclonedds.rnc, cyclonedds.xsd for correct
build.
Signed-off-by: ChenYing Kuo <evshary@gmail.com>
* Remove cdds.md.
Signed-off-by: ChenYing Kuo <evshary@gmail.com>
This works around a termination issue on Windows caused by the process
sometimes being unable to send a packet to itself to wake up a thread
stuck in a blocking read on a socket.
Signed-off-by: Erik Boasson <eb@ilities.com>
This commits adds support for the DOMAIN_ID and DOMAIN_TAG parameters in
participant discovery, allowing multiple domains to share a port
number (a feature introduced in DDSI 2.3). The tag can be configured
via Discovery/Tag.
This commit also introduces a setting Discovery/ExternalDomainId that
makes it possible to override the domain id on the network, both in what
is advertised in the DOMAIN_ID discovery parameter and in the
calculation of port numbers. This way a single process can create two
independent domains that talk via the network, which is on occassion
useful in writing tests.
Signed-off-by: Erik Boasson <eb@ilities.com>
This adds two things to the XSD (and the RNC file and options.md):
* attributes previously missing because of a bug in the conversion
script
* a name space (https://cdds.io/config)
Adding the name spacing requires a different set of attributes at the
top of a configuration file, which in turn need to be ignored by the
configuration parser, and which should be reflected in the configuration
example in the README.
Signed-off-by: Erik Boasson <eb@ilities.com>
The ``docs/makernc.pl`` perl script can extract the options from the
source code for the configuration processing and turn these into a
GitHub MarkDown document and a RELAX NG Compact form (RNC) description
of the options. Standard conversion tools can be used to turn the RNC
file into an XSD.
Although they are generated by a mechanical transformation, it is not
(yet) part of the build process, in no small part because there no
proper generation and publishing system has yet been set up for the
documentation.
Now that there is an XSD and a Markdown file for discovering the
options, there is no need to retain the configuration editing tool. Any
decent editor will do a better job.
Signed-off-by: Erik Boasson <eb@ilities.com>
