Skip to content
  • 0 Votes
    3 Posts
    187 Views
    C

    @Sajjad-Ali Quite apart from @JonB's observations:

    Your receiver is not listening. You need to look at QTcpServer You need to ensure that the receiving end does not have a system firewall blocking whatever port you are listening on.
  • 0 Votes
    5 Posts
    280 Views
    mrdebugM

    Hi, if you have to straming audio and video files you could use live555 on server side and, client side, only QMediaPlayer using rtsp.

  • 0 Votes
    17 Posts
    958 Views
    JonBJ

    @Prakash08
    Sorry, but you're wrong. @Christian-Ehrlicher & I have both tried to point this out to you.

    First of all, QMediaPlayer *player = new QMediaPlayer is a pointer to an allocated object on the heap. That means it persists until something deletes it. The fact that QMediaPlayer *player is itself a local variable is neither here nor there, when it goes out of scope that does not destroy the object it points to. That is quite different from QBuffer buffer(&received_data), which is a local stack variable, not a pointer to an object. That does get destroyed at the end of the if.

    Secondly, player->setMedia(QMediaContent(), &buffer) means that player is using the stack buffer, so as soon as the if exits buffer is destroyed but the QMediaPlayer is still using it as its buffer. When you go player->play() at the end that only starts playing the video, it does not finish playing it. It carries on playing after the function exits. But it's reading from a buffer which has now been destroyed. Not good! Lucky it does not "crash". Your "Error:failed to seek" error may be from code trying to access it when it is no longer valid.

    This is all standard C++ stuff.

  • 0 Votes
    1 Posts
    320 Views
    No one has replied
  • 0 Votes
    5 Posts
    585 Views
    SGaistS

    AFAIK, if this does happen you likely have other bigger issues. The signal is not related to the success of the request.

  • 0 Votes
    5 Posts
    625 Views
    M

    @J-Hilk thanks for your comment. I put that to read continuously from the buffer, but of course it is not necessary as soon as the signal/slot mechansim works.

  • 0 Votes
    9 Posts
    902 Views
    SGaistS

    Hi,

    @calmstack said in QtNetwork: incomingConnection not triggered:

    @jsulm Isn't it what the official documentation recommends ?

    No, it's one usage example. You have the same example without threads.

  • 0 Votes
    5 Posts
    898 Views
    KroMignonK

    @Vincent66 Bonjour, QTfp ne fait plus parti du project Qt mais les sources restes accessibles sur GitHub ==> https://github.com/qt/qtftp

    Pourquoi ne pas simplement partir de là et faire les adaptations eventuellement nécessaire pour la compilation?

  • 0 Votes
    9 Posts
    3k Views
    QjayQ

    hey i didn't fixed it . i downloaded Qt5.12.4 and then upgraded my openssl lib to 1.1.1b

    so i am good now
    thanks !!

  • 0 Votes
    3 Posts
    1k Views
    T

    It wooooorked, thank you so muuuuch :)

  • 0 Votes
    5 Posts
    1k Views
    W

    @SGaist said in HTTPS POST performance:

    Hi and welcome to devnet,

    @wrekler said in HTTPS POST performance:

    How relevant is knowing the server?

    It is relevant because:

    It might be sleeping if for example it's an heroku free tier that hasn't been used for some times. Therefore the first query will have to wait for the server to awaken thus it will be longer. It might require authentication which takes some time on first query to setup and allow to process. It might need to query some slow to start resource to answer your question etc.

    Oh, I see. Well it is not a my server, it is a thirdy party server, so I can't answer to all that question. All I know is:

    It is hosted on akamai.com Acqtually it require some authentication data that I give with POST data

    So I think I can't optimize requests server side, all can I do is caching DNS/TCP/SSL requests but I don't know if Qt 5.11.2 actually implements all that suggestions

  • 0 Votes
    6 Posts
    2k Views
    IMAN4KI

    @SGaist
    NO, both are 32bit.
    Seems clearing the build dir and make again solved the problem!

  • 0 Votes
    10 Posts
    4k Views
    IMAN4KI

    At long last! i decided to simply process reply in worker thread(Thanks @raven-worx ):

    using Header = QMap<QString, QString>; class HttpWorker : public QObject { Q_OBJECT public: struct HttpData { bool hasError = false; NetworkError error = NetworkError::NoError; QString errorString; QByteArray data; }; HttpWorker(QThread*, const QUrl&, const QUrlQuery&); ~HttpWorker(); void addHeaders(const Header&); enum Method { Post, Get }; void setMethod(Method m) { http_method = m; } Method method() const { return http_method; } private Q_SLOTS: void sendRequest(); private: QNetworkAccessManager manager; Header headers; QUrlQuery params; QUrl url; Method http_method = Post; private: void check(QNetworkReply*); void appendHeaders(QNetworkRequest*); Q_SIGNALS: void finished(HttpData); }; HttpWorker::HttpWorker(QThread* thread, const QUrl& _url, const QUrlQuery& _params) :url{ _url }, params{ _params } { qRegisterMetaType<HttpData>("HttpData"); moveToThread(thread); manager.moveToThread(thread); QObject::connect(thread, &QThread::started, this, &HttpWorker::sendRequest); QObject::connect(this, &HttpWorker::finished, thread, &QThread::quit); QObject::connect(thread, &QThread::finished, thread, &QThread::deleteLater); QObject::connect(thread, &QThread::finished, this, &HttpWorker::deleteLater); QObject::connect(&manager, &QNetworkAccessManager::finished, this, &HttpWorker::check); } HttpWorker::~HttpWorker() { } void HttpWorker::addHeaders(const Header& _headers) { headers = std::move(_headers); } void HttpWorker::appendHeaders(QNetworkRequest* req) { if (!req) return; QMapIterator<QString, QString> iterator(headers); while (iterator.hasNext()) { iterator.next(); req->setRawHeader(QByteArray::fromStdString(iterator.key().toStdString()), QByteArray::fromStdString(iterator.value().toStdString())); } } void HttpWorker::sendRequest() { const auto content_h = QStringLiteral("application/x-www-form-urlencoded"); if (method() == Post) { QNetworkRequest req(url); req.setHeader(QNetworkRequest::ContentTypeHeader, content_h); if (!headers.isEmpty()) appendHeaders(&req); const auto data = params.isEmpty() ? url.toEncoded() : params.toString(QUrl::FullyEncoded).toUtf8(); manager.post(req, data); } else { url.setQuery(params); QNetworkRequest req(url); req.setHeader(QNetworkRequest::ContentTypeHeader, content_h); manager.get(req); } } void HttpWorker::check(QNetworkReply* reply) { HttpData data; if (reply->error()) { data.hasError = true; data.error = reply->error(); data.errorString = reply->errorString(); } else { data.data = std::move(reply->readAll()); } emit finished(std::move(data)); reply->deleteLater(); }
  • 0 Votes
    8 Posts
    3k Views
    mrjjM

    Ok, it sounds like a bug then.
    Good if you open ticket.
    Make sure to include a small complete working example they can use
    to reproduce it.

  • 0 Votes
    8 Posts
    4k Views
    J

    @raven-worx
    I did as you suggested https://bugreports.qt.io/browse/QTBUG-63313 . Hope the bug report is properly documented

  • 0 Votes
    9 Posts
    2k Views
    jsulmJ

    @IMAN4K You could just emit a signal after getting the data and processing it.

  • 0 Votes
    1 Posts
    797 Views
    No one has replied
  • 0 Votes
    4 Posts
    2k Views
    kshegunovK

    By default QDataStream uses big endian. You can change it manually, but do so on all platforms you want to deploy to/programs you're deploying. In any case you're fine as long as you stream your data with the appropriate operators and don't use writeRawData/readRawData or any reinterpret_cast "tricks".

  • 0 Votes
    17 Posts
    7k Views
    kshegunovK

    @marlenet15
    Hi,
    Here you can find a threaded TCP server example. You can ignore the module specific classes QDaemonApplication (think of it as QCoreApplication) and QDaemonLog you can substitute with QDebug.

    Enjoy!
    Kind regards.

  • 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.