The build information in the README was very limited (now it is less
limited) and, the list of prerequisites was incomplete, documentation
link was out of date ... This cleans it up a bit.
Signed-off-by: Erik Boasson <eb@ilities.com>
The "rhc" test runs a random sequence of operations (writes, reads, &c.)
through an RHC with conditions attached to it. All possible state masks
are used, and query conditions are tried with a condition that only
tests the key value, and one that tests attribute values. It depends on
the internal checking logic of the RHC, which is currently enabled only
in Debug builds because of the associated run-time overhead.
Signed-off-by: Erik Boasson <eb@ilities.com>
Various details:
- index replaced throughout by bitmask
- caching a single sample in RHC for deserialising samples when query conditions are used
- short-circuiting the trivial case of an instance matched neither before nor after a change to its state
- combining inc/dec counters into a single delta in condition evaluation
- major speed-up of rhc_check_counts by not checking the condition bit masks every single time
Signed-off-by: Erik Boasson <eb@ilities.com>
The specification says the data in an invalid sample must not be inspected, but that means retrieving the key values from a disposed/unregistered instance after a take is impossible. So, the elegant thing to do is to always provide the key values in the data. The remaining question is then whether the non-key fields should be left in whatever state they happened to be in, or be set to zero. The latter is more consistent in the interface, and that is almost invariably a good thing.
Signed-off-by: Erik Boasson <eb@ilities.com>
Whenever a sample or an instance is added, check it against the attached query conditions and indicate which ones match
Signed-off-by: Erik Boasson <eb@ilities.com>
This index can then be used as an index into a bitmap to keep track
which query conditions are matched by a sample or an instance.
Signed-off-by: Erik Boasson <eb@ilities.com>
The read condition and the query condition are represented by the same data type internally, and a read condition therefore has a "m_filter" attribute. It makes more sense to initialise this properly as part of the read condition, instead of initialisation-by-memset in the dds_create_readcond, then overwriting it in dds_create_querycond.
Signed-off-by: Erik Boasson <eb@ilities.com>
The RHC tracing produces so much junk that is hardly ever useful that a
normal trace should definitely not include it.
Signed-off-by: Erik Boasson <eb@ilities.com>
A read restricted to samples in "read" state would not enter the condition update code on the false assumption that no read conditions could become triggered if the number of read samples remained the same, but it is nonetheless possible that the instance was transitions from "new" to "old" as a consequence, at least in my interpretation of the spec and the current implementation of read() in Cyclone. This commit brings consistency to the implementation without the intention of confirming the current behaviour as being desirable.
Signed-off-by: Erik Boasson <eb@ilities.com>
The name change missed the uses of the macro, with the result that
datagram truncation on reception does not result in warning (but in
the default configuration, truncation cannot occur); and that the
message flags are undefined on sending datagrams, but judging by the
man page, the likelihood of this causing problems is also small in
practice.
Signed-off-by: Erik Boasson <eb@ilities.com>
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>