There are a couple of days left for you all, if you want to get my book for $10 only!
In the course of the "Spring $10 Campaign" on packtpub.com you can purchase the eBook version of my "Hands-On High Performance Programming with Qt 5" book for $10 only until 30th of April.
So hurry on! here's the link: https://www.packtpub.com/application-development/hands-high-performance-programming-qt-5.
Get it when it's still fresh. It only came out this January!
PS: Sorry for the short notice, but somehow I overslept... Shame on me. 😞 Sorry.
8 comments:
I read your book. It explains networking problems in detail and gives solutions. But i have a question. I don't know when to use TCP/IP or HTTP protocol for server. Can give any suggestion s on which protocol to use? I have many clients( about 500 ) and they must get information form db through the server and server do some operations and return result to clients.
Hi Sardor,
this is a design decision and it depends on the use case and trade-offs you are willing to take. HTTP is not a bad choice for a Request-Response communication patterns - is that the case with your application?
Hi, Marek Krj
Thanks a lot for you reply. Yes, my choice is request–response method. Because a every client ( An embedded device such as raspberry pi) sends a request(post, get and delete) to server and waits a response from server. If HTTP is not a bad choice as you say, I think http is going to solve my problem. And now i have three final questions.
1. In your book you say "we can fool the server into not closing the connection by sending some dummy keep-alive requests to the server." and is it not bad idea? because server have to create thread or socket and keep it alive for a long time. If it is not bad idea, can i use http protocol for sending data(sensor data or frame for face recognition) in every 300 ms to server? and is it not slow?
2. In your book you say "Since Qt isn't very well-suited for that task—I, for example, used the C++ RestSdk library to write a HTTP server".If we say qtnetwok is well-suited for client side, what kind of other libraries except C++ RestSdk you would prefer or recommend for server side? You know there are many libraries such as Boost.asio, poco, cpp-netlib:The C++ Network Library.
3. If I use lower-level classes such as QTcpSocket, QTcpServer, will it causes many problems? or we can use them without problem?
Thanks a alot in advance
Hi Sardor,
let us see:
1. This is the "long polling" option (google it) and it burns resources on server. 500 connections doesn't seem so high though. If it's too much, switch to WebSockets. Or use WebSockets right away.
2. I'm a fan of C++ RestSdk on Windows. And it is cross platform! BTW it uses Boost.asio under the hood on Linux. POCO is also well-tested, but I didn't use it. Boost.asio is mainstream on Linux.
3. OFC you can use them. On the other side, it uses the Qt slot/signal mechanism - it could possibly be too slow, but in normal case it should suffice!
As you see, the reponse is "it depends" (as always :-)...
Hi, Marek Krj
Thank you for your recommendations. They are very helpfull.
cool!
Hi, Marek Krj
I wanted ask you about nesting event Loops in Qt. Many people say we should avoid nesting event Loops like QDialog::exec(), QEventLoop::exec. Even Qt doc says: "Avoid using this(QDialog::exec()) function; instead, use open(). Unlike exec(), open() is asynchronous, and does not spin an additional event loop. This prevents a series of dangerous bugs from happening (e.g. deleting the dialog's parent while the dialog is open via exec()). When using open() you can connect to the finished() signal of QDialog to be notified when the dialog is closed."
I found these two articles on the Internet and they say we should avoid nesting event Loops
1) https://www.qt.io/blog/2010/02/23/unpredictable-exec
2) https://youtuberead.com/watch-de/thigo-mcieir-qt-event-loop-netwkg-i-o
In his Qt event loop, networking and I/O API talk, Thiago Macieira mentions that nesting of Qeventloop should be avoided:
"QEventLoop is for nesting event Loops... Avoid it if you can because it creates a number of problems: things might re enter, new activations of sockets or timers that you were not expecting."
In my project i use the following:
QNetworkAccessManager l_nm;
QUrl l_url ("http://...");
QNetworkRequest l_req(l_url);
QNetworkReply *l_reply = l_nm.get(l_req);
QEventLoop l_event_loop;
QObject::connect(l_reply, SIGNAL(finished()), &l_event_loop, SLOT(quit()));
l_event_loop.exec();
But now i don't know should i use nesting event Loops or not. Moreover if nesting event Loops cause problems and we don't use nesting event Loops then we have to write more code.
If you share your experience about this I would be glad.
Thanks a alot in advance
Hi Sardor,
indeed, nested event loops are quite error-prone (I've seen that in some project in production code). However in this use case you are doing just a blocking wait on a QNetworkReply and I don't think anything could go wrong. However, note that all other events normally handled by the main event loop of the thread will be now handled here!
Why aren't you just using waitForReadyRead(-1) to block and wait for response?
Post a Comment