Fallback to unicast should set options for unicast discovery (#104)
A very simple change that addresses a real usability issue, does not rely on any platform-specific changes and moreover builds cleanly on the source branch. So I am not going to wait until the AppVeyor build completes.
fix and enable SSL support when OpenSSL is available
This has been sitting pretty for some days now and in my opinion it makes sense to merge it — so merging it. The AppVeyor build is not done yet, but it is successful for the exact same commit on the source branch and it also succesful for the next-to-last commit. The last commit in the PR is no more than Travis CI configuration, so it doesn't even affect AppVeyor builds.
The default behaviour is to allow multicast, with a fallback of
disabling multicast altogether if the selected interface doesn't support
it. The trouble is that the default discovery configuration assumes that
multicast is available, avoiding the "well-known" port numbers and
avoiding sending any participant discovery messages via unicast. The
result is that the process will run in isolation, which is typically not
the desired result. (It is a quite annoying problem because it happens
on Linux when only a loopback interface is available. It appears that
multicast over loopback works fine, if only you try it, but the kernel
doesn't advertise it and so it doesn't get used.)
This commit changes two things: firstly, it this case it forces the
allocation of "well-known" unicast ports, and secondly, it automatically
adds the local interface's address to the discovery address set. This
way, at least communication inside the machine works.
(Note: AssumeMulticastCapable can be still be used to force it to treat
a Linux loopback interface has multicast capable. It is only the default
behaviour that has changed.)
With thanks to @jwcesign who did all the work except writing the commit
message.
Signed-off-by: Erik Boasson <eb@ilities.com>
Getting cmake to work with/without conan on macOS, Linux and Windows
seems to be trickier than it should be when dealing with older cmake
versions. Switching to an Ubuntu Xenial image on Travis CI at least
makes it build again.
The update then also eliminates the need to update cmake, clang and
maven, saving quite a bit of build time. A few small tweaks and an
update to the macOS image version reduces some 5 minutes from the macOS
build time.
The minimum required version for cmake needs to be updated, too, but
really only when openssl support is included. So instead of raising the
required version in the CMakeFile I am in favour of simply hoping for
the best.
Signed-off-by: Erik Boasson <eb@ilities.com>
One is reasonable (a difference between size_t and the type used for a blob in an iovec), the others are SOCKET-to-int conversions that are caused by the openssl API. Since I'm not going to fix openssl and every indication is that the conversion is safe in practice, silencing the compiler is a sensible thing to do.
Signed-off-by: Erik Boasson <eb@ilities.com>
A configuration setting to allow negotiating TLS1.2 is included. If I
got things done correctly, OpenSSL pre-1.1 can be used but requires
explicitly lowering the minimum allowed TLS version in the
configuration file.
Signed-off-by: Erik Boasson <eb@ilities.com>
With TLS1.3 the socket can indicate data is available even when there is no application data. This commit ignores a 0-byte read when no data is required. Long-term, handling short reads/writes in TCP mode need to be handled completely differently, but that is a story for another day.
Signed-off-by: Erik Boasson <eb@ilities.com>
OpenSSL support remains optional, but instead of including it or not solely depending on whether cmake manages to find it, there is now a DDSC_ENABLE_OPENSSL option that defaults to "ON". Setting to OFF removes the dependency. The Conan configuration has been updated to automatically provide openssl 1.1.1a.
Signed-off-by: Erik Boasson <eb@ilities.com>
In listener mode, the main thread would still periodically try to take samples. When this happens concurrently with the listener invocation, the result is a spurious warning that some samples were delivered out-of-order.
Signed-off-by: Erik Boasson <eb@ilities.com>
Line buffering allows monitoring progress via pipes or files, and as there is just one line of output per second, it doesn't affect performance
Signed-off-by: Erik Boasson <eb@ilities.com>
Fixing that produces a lot of noise on stderr because of inappropriate use of the "info" category in various place and, on macOS, because of a rather stupid way of messing with thread scheduling priorities even when none have been specified explicitly in the configuration.
Signed-off-by: Erik Boasson <eb@ilities.com>
Previously it wasn't set for all platforms, breaking, e.g., Linux on ARM. The property also does the trick for OpenIndiana, so that hack can be removed as well
Signed-off-by: Erik Boasson <eb@ilities.com>
Getting a QoS from an entity is akin to reading, and all read/take operations reuse or free/reallocate memory to avoid memory leaks, and so it is a reasonable assumption that calling dds_get_qos repeatedly without intervening calls to dds_reset_qos would not leak any memory either. (This was actually an assumption in the builtin topics test.) Therefore, it is reasonable to first call dds_reset_qos in dds_get_qos. All operations in the API that yield or modify a QoS object result in a properly initialised one, therefore the input to dds_get_qos is necessarily initialised, and so this is safe.
Signed-off-by: Erik Boasson <eb@ilities.com>
Stopping and restarting the DDSI stack in a single process would not re-initialise the TCP support code properly
Signed-off-by: Erik Boasson <eb@ilities.com>
Listener/status management invocation was rather expensive, and
especially the cost of checking listeners, then setting status flags and
triggering waitsets ran into severe lock contention.
A major cost was the repeated use of dds_entity_lock and
dds_entity_unlock, these have been eliminated. Another cost was that
each time an event occurred (with DATA_AVAILABLE the most problematic
one) it would walk the chain of ancestors to see if any had a relevant
listener, and only if none of them had any, it would set the status
flags.
The locking/unlocking of the entity has been eliminated by moving the
listener/status flag manipulation from the general entity lock to its
m_observers_lock. That lock has a much smaller scope, and consequently
contention has been significantly reduced.
Instead of walking the entity hierarchy looking for listeners, an entity
now inherits the ancestors' listeners. The set_listener operation has
been made a little more complicated by the need to not only set the
listeners for the specified entity, but to also update any inherited
listeners its descendants.
The commit is a bit larger than strictly needed ... I've started
reformatting the code to reduce the variety of styles ... as there I
haven't been able to find a single tool that does what I want, it may
well end up as manual work.
Signed-off-by: Erik Boasson <eb@ilities.com>
dds_init generates an entity name for the participant derived from the
process name and process id, but the name is currently uninitialised
(temporarily so, caused by a recent update to the OS abstraction layer).
Signed-off-by: Erik Boasson <eb@ilities.com>
When a remote writer is discovery, a proxy_writer object representation
that writer is created without yet having any knowledge of what the
current sequence number for that writer is. If a local reader is
matched with that proxy writer before a Heartbeat has been recevied and
this sequence number information is known, all historical data will be
made available to that reader, even if it is volatile.
By treating the first Heartbeat specially, by moving the next sequence
number to be delivered as fresh data forward to the next sequence
number, retrieval of historical data is avoided. Transient-local
readers have a separate ("out-of-sync") route to request it anyway.
Signed-off-by: Erik Boasson <eb@ilities.com>
Move details of built-in topics out of the DDSI core (so the only hooks
remain). For this, rtps_term had to be split, so now it is "stop"
followed by "fini".
Add a notion of local writers that are not bound to a participant ("local
orphans"), so that the local built-in topic writers can be created during
initialization. This eliminates the "builtin" participant. This
uncovered in inconsistency in the unit tests: on the one hand, a newly
created participant is expected to have no child entities; on the other
hand, the built-in topics were expected to be returned by find_topic ...
This inconsistency has been resolved by creating them lazily and
accepting that find_topic can't return them until they have been
created. Special code was in place in dds_create_reader anyway, so it
is not expected to have any real consequence for applications.
Use a special WHC implementation that regenerates the data on the fly
using the internal discovery tables of DDSI, so that the samples are only
stored by readers. This eliminates the memory overhead of that existed
previously when the WHC of the writers stored the data.
No longer return topic name and type name in the built-in topics, they
have been extracted already and are not accessible through the normal
interface but do cause problems when comparing QoS.
Signed-off-by: Erik Boasson <eb@ilities.com>
