Skip to content
  • 0 Votes
    2 Posts
    355 Views
    JoeCFDJ

    @DrEmbo said in QNetworkInterface::addressEntries() returns empty list:

    allInterfaces

    this works for me with Qt 5.15.2 on Linux.

    QList< QNetworkInterface > network_interfaces = QNetworkInterface::allInterfaces(); for( auto interface : network_interfaces ) { if ( interface.flags().testFlag( QNetworkInterface::IsRunning ) ) { auto address_entries = interface.addressEntries(); for ( auto address_entry : address_entries ) { .................. } } }
  • 0 Votes
    7 Posts
    579 Views
    Kent-DorfmanK

    system() is the naive OS interface mecahnism. It will stall the calling program while executing. an async QProcess is a better mechanism if you must call a subshell...The sophisitcated Linux way is to use the dbus system to talk directly to NetworkManager.

  • 0 Votes
    2 Posts
    577 Views
    raven-worxR

    @Sudip-Ghimire
    subclass QNetworkAccessManager and reimplement createRequest and call the base class implementation.
    Then set your custom NAM to the QWebPage:
    https://doc.qt.io/archives/qt-5.5/qwebpage.html#setNetworkAccessManager

  • 0 Votes
    11 Posts
    2k Views
    nooneN

    after removing the lines:-

    auto img = QImage::fromData(rawimg); QLabel *myLabel = new QLabel; myLabel->setPixmap(QPixmap::fromImage(img)); myLabel->show();

    it works perfectly with more than 20*3 images

  • 0 Votes
    4 Posts
    562 Views
    nooneN

    @JonB Thanks. I didn't know about those links. they look promising. This whole networking stuff is really new to me

    @Christian-Ehrlicher Thanks. So for large data, I guess QWebSocket::binaryFrameReceived() is the correct way

  • 0 Votes
    2 Posts
    1k Views
    kshegunovK

    None of the above. Pool your TCP connections on top of a few threads, and independently pool your few database connections on top of another set of threads. Make the actual queries asynchronous by queuing them through the tread pool.
    The solution's rather complex, though, and 1000 connections ain't that much, so you may be able to get away with a single thread for the TCP stack and a single thread for the SQL stack.

  • 0 Votes
    11 Posts
    4k Views
    thamT

    About this project, I use the lib found on the github as I mentioned before. It works well and quite easy to adjust the codes for my own requirements.

    One bug I found about this lib is it do not delete the resource if clients disconnected(maybe not a big issue for the author so he did not fix it), you need to handle that part by yourself. If you need to have multiple keys, I suggest boost::multiindex, although the api is a bit complicated, it is easy to use and help us write clean codes.

    If my customers allowed, I would put the version after alternate to github.

  • 0 Votes
    10 Posts
    2k Views
    S

    Okay I found the culprit in an unexpected corner.

    I decided to completely strip it to the absolute bare minimum:

    int main(int argc, char *argv[]) { QCoreApplication app (argc, argv); // initialization Sms_notifier notifier(true, 5); notifier.notify( "+0123456789", "Lorem Ipsum is simply dummy text of the printing and typesetting industry. "); qWarning() << "done, looping"; while(true) { QCoreApplication::exec(); } } Sms_notifier::Sms_notifier(bool test, int interval_length_milliseconds) : QObject (NULL) ,m_test (test) ,m_interval_length_milliseconds(interval_length_milliseconds) ,m_manager () ,m_timer () ,m_addressee() ,m_payload() { m_timer.setSingleShot(true); QObject::connect(&m_manager, &QNetworkAccessManager::finished, this, &Sms_notifier::on_nam_finished); QObject::connect(&m_timer, &QTimer::timeout, this, &Sms_notifier::on_timer_elapsed); } Sms_notifier::~Sms_notifier() { } bool Sms_notifier::notify( const std::string addressee, const std::string payload ) { m_addressee = addressee; m_payload = payload; return notify(); } bool Sms_notifier::notify() { QNetworkRequest request; QByteArray data; m_manager.post(request, data); return false; } void Sms_notifier::on_nam_finished(QNetworkReply* reply) { QNetworkReply::NetworkError error = reply->error(); reply->deleteLater(); if (error != QNetworkReply::NetworkError::NoError) { m_timer.start(m_interval_length_milliseconds); } else { qWarning() << "success"; m_addressee.clear(); m_payload.clear(); } } void Sms_notifier::on_timer_elapsed() { notify(); }

    It turns out it was still leaking while there was no network. So I stripped away all libraries that were linked, and it still leaked.

    Eventually my eye struck this in the .pro file:

    QMAKE_CXXFLAGS += -fsanitize=address QMAKE_CFLAGS += -fsanitize=address QMAKE_LFLAGS += -fsanitize=address -lasan

    This was added to detect memory leaks and report them when the application quits. After removing this, the excessive "memory leak" was gone.

    I am assuming that the address sanitizer allocates memory for each allocation done by the application, for its own administration purposes. I suspect that when the application releases the allocated memory, the sanitizer holds on to the respective administration data until the application quits. This could explain why when I remove the sanitizer it also removes the leak.

    Well, thanks everyone for your input!

  • 0 Votes
    5 Posts
    4k Views
    D

    @Xando On windows, this did not work for me, even fixing the socket options to the windows equivalent. What did work was:

    udpSocket = new QUdpSocket(this); groupAddress4 = QHostAddress(multicastAddr); bool result = udpSocket->bind( QHostAddress::AnyIPv4, port, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint);
  • 0 Votes
    8 Posts
    2k Views
    VRoninV

    @Pablo-J.-Rogina said in How to handle many QNetworkReplies ?:

    I'm just using only one QNAM per application.

    That means that, if you connect to QNetworkAccessManager::finished() instead of QNetworkReply::finished() yor slot can be triggered even when a request from a totally unrelated class is finished

  • 0 Votes
    8 Posts
    2k Views
    P

    @aha_1980 said in UDP Socket - writeDatagram uses IPv6 and not IPv4:

    Then why not use QHostAddress::AnyIPv4 ? Looks more clear to me...

    Learn something new everyday :)

  • 0 Votes
    8 Posts
    3k Views
    V

    @VRonin Excellent! This is exactly what I was looking for! Thank you!

  • 0 Votes
    3 Posts
    2k Views
    OBsIV XIMO

    Thanks. Path of least resistance was build OpenSSL for Android and deploy with our app.

  • 0 Votes
    1 Posts
    894 Views
    No one has replied
  • 0 Votes
    3 Posts
    1k Views
    VRoninV

    I agree with stack overflow. Your design is flawed. The state machine behind the communication should not depend in any way on the interface

  • 0 Votes
    2 Posts
    1k Views
    kshegunovK

    @htmlboss
    Hi,

    let's call them "node" and "controller"

    Let's not do that. Let's call them a server and a client - it's much better and easier to follow the accepted terminology. A server will serve the requests presented by the clients (see the analogy with a busy restaurant?).

    There can only be one "controller", but the number of "nodes" may vary (eg. different clients).

    So you have one server and a few clients. So far so good.

    I want to have the "controller" initiate the connection to each client such that arbitrary data is sent back and forth as it is ready (readyRead() signal? ).

    How data flows between the client and the server is completely independent of who initiated the connection. You can still have the server sending data to the clients (what http servers mostly do), and still the client initiates the connection (i.e. your browser).

    I have implemented the Fortune Client/Server example with the "controller" as the Client (since it would initially ask for a connection), and the Fortune Server as a test (eventually it would be a "node" sending data). This is where I'm stuck. Ignoring less-than-critical performance issues, how would I modify the Fortune example (or perhaps roll my own) to allow the Server to accept data from the "controller" without the use of any buttons/etc, but to get it as it is "ready"? Ideally, this needs to scale up to a max of 15 "nodes".

    Just write from the appropriate side (application). The server should stay the server, and the client should stay a client, don't switch their roles.

    Kind regards.

  • Qt Local DNS Mapping

    Unsolved General and Desktop
    2
    0 Votes
    2 Posts
    933 Views
    SGaistS

    Hi and welcome to devnet,

    AFAIK, it's not possible on a "per application" basis. Qt's network stack uses what the OS provides.

  • 0 Votes
    4 Posts
    2k Views
    SGaistS

    Maybe QNetworkConfigurationManager and friend classes might be of help here.