nitroshare / qmdnsengine Goto Github PK

According to 3.6.2

The storage for objects with static storage duration (basic.stc.static) shall be zero-initialized (dcl.init) before any other initialization takes place. Zero-initialization and initialization with a constant expression are collectively called static initialization; all other initialization is dynamic initialization. Objects of POD types (basic.types) with static storage duration initialized with constant expressions (expr.const) shall be initialized before any dynamic initialization takes place. Objects with static storage duration defined in namespace scope in the same translation unit and dynamically initialized shall be initialized in the order in which their definition appears in the translation unit.
..
It is implementation-defined whether or not the dynamic initialization (dcl.init, class.static, class.ctor, class.expl.init) of an object of namespace scope is done before the first statement of main. If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first use of any function or object defined in the same translation unit as the object to be initialized.

The Android NDK's Clang/LLD sometimes produces an unloadable shared library and/or library that leads to crash when dlclose'd (depends on many things, including the target API version).
Their KnownIssues mentions similar issue with thread_local but I failed to find anything about exported namespaced static non-POD implementation guarantees/limitations, albeit there is a bunch of reports about crash during dlopen similar to what I sometimes see with my app built with NDK 21+/arm64 and running on Android O.

Look for example at:
// .h

QMDNSENGINE_EXPORT extern const QHostAddress MdnsIpv4Address;

// .cpp

const QHostAddress MdnsIpv4Address("224.0.0.251");

Depending on many things (including the linker, linkage type, whether QMdnsEngine::MdnsIpv4Address is referenced outside libqmdnsengine and so on), it is hard to guess when/where it's constructor shall be called.
Interestingly that decreasing the overall amount of static objects somehow solved this issue in my particular case.

A simple solution would be making MdnsIpv(4|6)Address a constexpr/inline function or making it a specialised enum + providing a respective overloads everywhere the object has been used before (i.e. Message::setAddress(SpecialAddress) => message.setAddress(QMdnsEngine::MdnsIpv4Address) ). Unfortunately, both will break source compatibility.

QMdnsEngine::Cache maintains cached records and sends a new query to refresh the record when the TTL is close to expiring to keep the cache fresh (via BrowserPrivate::onShouldQuery()). This seems like a sane approach, but it causes issues when combined with the behavior of BrowserPrivate::onMessageReceived() which places the records of all incoming responses into our cache. As each of these records expire, we send queries to refresh them. Unfortunately, since we snoop on every mDNS response that comes by, this means we are effectively retransmitting all mDNS queries that yielded any answer record when queried by any mDNS client on the subnet. This leads to unwanted mDNS traffic amplification by any QMdnsEngine client on the network as we will continue to refresh that record forever (and long after the client that sent the original query has finished whatever it needed that record for).

The crux of the issue seems to be that there's nothing that distinguishes a solicited record (which we probably do want to keep up to date, at least as long as somebody is actively using a QMdnsEngine::Browser instance for it), and an unsolicited record that we really don't care about but just opportunistically cached (which we should probably just let expire).

I suspect its because there is missing parenting of child Qt components (like here

Hi, I need to use thi lib on Windows.
To build it I'm trying like this:
cmake -DCMAKE_PREFIX_PATH=C:\Qt\Qt5.9.1\5.9.1\msvc2015\bin ..\qmdnsengine .
C:\Qt\Qt5.9.1\5.9.1\msvc2015\bin is where I have Qt dlls.
I obtain this error:
cmake -DCMAKE_PREFIX_PATH=C:\Qt\Qt5.9.1\5.9.1\msvc2015\bin ..\qmdnsengine .
-- Selecting Windows SDK version 10.0.14393.0 to target Windows 10.0.17763.
CMake Error at CMakeLists.txt:24 (find_package):
By not providing "FindQt5Network.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"Qt5Network", but CMake did not find one.

Could not find a package configuration file provided by "Qt5Network"
(requested version 5.4) with any of the following names:

Qt5NetworkConfig.cmake
qt5network-config.cmake

Add the installation prefix of "Qt5Network" to CMAKE_PREFIX_PATH or set
"Qt5Network_DIR" to a directory containing one of the above files. If
"Qt5Network" provides a separate development package or SDK, be sure it has
been installed.

-- Configuring incomplete, errors occurred!
See also "C:/Cpp/qmdnsengine/qmdnsengine-build-desktop/CMakeFiles/CMakeOutput.log".

How can I resolve?

I have a pixhawk connected via static IP address and qmdnsengine is unable to find it, but avahi discovery works fine.
It appears that when qmdnsengine is using the mdns group 224.0.0.251 it does not work, but using 192.168.2.2 (rasp ip) or 192.168.2.255 works. Any idea ?

Is there a way to send QU queries with this library?
Multicast DNS reference: https://datatracker.ietf.org/doc/html/rfc6762#section-5.4

Since iOS16 and MacOS Ventura I'm not able anymore to send broadcast messages from this library. Are you seeing the same thing?
I'm starting the port to NWListener unfortunately :(

i have success use cmake create these three files , qmdnsengine.dll,qmdnsengine.exp,qmdnsengine.lib , but i dont get qmdnsengine.h .
so when i use code below , errors occour , it said QMdnsEngine is not a class or namespace name .

code below :
QMdnsEngine::Server server;
QMdnsEngine::Cache cache;
QMdnsEngine::Browser browser(&server, "_http._tcp.local.", &cache);

The broadcast code needs to immediately send a mDNS probe on newly added network interfaces and this is only possible if Server keeps track of which ones are available. Perhaps interface discovery should be moved to a separate class...

There is a couple of PRs that are great but they don't have review and neither are merged.

There is a bug in versions of Qt earlier than 5.9 where QUdpSocket::joinMulticastGroup() does not cope with multi-homed devices [QTBUG-27641]. I suggest bumping the minimum version to a least 5.9 to avoid the issue.

ServerPrivate::ServerPrivate(Server *server)
: q(server)
^^^^^^^^^
here, probably, should be
: QObject(server)
, q(server)

The resolver has a signal called resolved which has parameter address. But to what name does this address belong?
Maybe it can be added it to the signals parameters: emit q->resolved(record.name(), record.address());

The test suite is currently failing on TestBrowser:

FAIL!  : TestBrowser::testBrowser() Compared values are not the same
   Actual   (serviceRemovedSpy.count()): 0
   Expected (1)                        : 1
qmdnsengine\tests\TestBrowser.cpp(144) : failure location

The offending section of tests\TestBrowser.cpp:

//...

{
    QMdnsEngine::Record record;
    record.setName(Type);
    record.setType(QMdnsEngine::PTR);
    record.setTtl(0);
    record.setTarget(Fqdn);
    QMdnsEngine::Message message;
    message.setResponse(true);
    message.addRecord(record);
    server.deliverMessage(message);
}

// The serviceRemoved signal should have been emitted
QCOMPARE(serviceRemovedSpy.count(), 1);

The DNS parser includes support for NSEC records but they are not used in the mDNS code.

The Provider/ProviderPrivate class destructor causes a crash in certain cases. See the destructor below:

ProviderPrivate::~ProviderPrivate()
{
    if (confirmed) {
        farewell();
    }
}

The farewell() function then proceeds to use the server member variable. This causes a crash if the objects are not deleted in correct order. The example/doc code

QMdnsEngine::Server server;
QMdnsEngine::Hostname hostname(&server);
QMdnsEngine::Provider provider(&server, &hostname);

is safe because the destructors of local objects are called in the reverse order of their constructors (~Provider() --> ~Hostname() --> ~Server()). The following, perhaps as surprise to many however, is not:

QMdnsEngine::Server* mServer = new QMdnsEngine::Server(this);
QMdnsEngine::Hostname* mHostname = new QMdnsEngine::Hostname(mServer, this);
QMdnsEngine::Provider* mProvider = new QMdnsEngine::Provider(mServer, mHostname, this);

because the QObject children are deleted in a different order (~Server() --> ~Hostname() --> ~Provider()).

The problem is trivial to go around by forcing the deletion order but I think proper Qt integration and QObject conformance would require supporting the natural QObject child object deletion order as well.

Hi, I'm using qmdnsengine
on Linux without any problem. On Windows no one device is found.
I have tryied to disable the firewall without any good result.
Does anybody using qmdnsengine on Windows 10?

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x000000010dee9f98 qt_meta_stringdata_Qt + 0 1 libqmdnsengine.0.dylib 0x000000010cd2dd3d QMdnsEngine::ProviderPrivate::~ProviderPrivate() + 77 2 libqmdnsengine.0.dylib 0x000000010cd2de7e QMdnsEngine::ProviderPrivate::~ProviderPrivate() + 14 3 org.qt-project.QtCore 0x000000010dba8610 QObjectPrivate::deleteChildren() + 224 4 org.qt-project.QtCore 0x000000010dba83f4 QObject::~QObject() + 1700 5 libqmdnsengine.0.dylib 0x000000010cd2087e QMdnsEngine::Cache::~Cache() + 14 6 org.qt-project.QtCore 0x000000010dba8610 QObjectPrivate::deleteChildren() + 224 7 org.qt-project.QtWidgets 0x000000010cd843f3 QWidget::~QWidget() + 1059 8 provider 0x000000010cd10713 main + 131 9 libdyld.dylib 0x00007fff6ab733d5 start + 1

Qt 5.12.7, OS X 10.14.6

void Message::reply(const Message &other)
{
if (other.port() == MdnsPort) {
if (other.address().protocol() == QAbstractSocket::IPv4Protocol) {
setAddress(MdnsIpv4Address);
} else {
setAddress(MdnsIpv4Address); <= "Here should be MdnsIpv6Address????"
}
} else {
setAddress(other.address());
}
setPort(other.port());
setTransactionId(other.transactionId());
setResponse(true);
}

Queries may contain existing records which indicate that the host already has them in its cache. This signals to the other peers that the records do not need to be resent. QMdnsEngine currently ignores these.