[Qt-interest] QTcpSocket timeouts

[Bob Hood]

Anatoly, please send responses directly to the mailing list.  I use an
email firewall that redirects emails from any source of which I have not
previously explicitly approved to a "holding" area, and I don't always
check it regularly.  In addition, more eyes on a problem can lead to
more suggestions, and potentially more elegant approaches.


Anatoly Burakov wrote:
> On 18.03.2010 3:00, Bob Hood wrote:
>> Anatoly Burakov wrote:
>>> On 18.03.2010 2:37, Bob Hood wrote:
>>>> You probably need to let the event loop run so that data from the
>>>> incoming connection can be processed and queued up for you.  That's
>>>> essentially what is happening when you post the dialog box (i.e., and
>>>> event loop runs and data is processed).
>>>>
>>> Just tried to put qApp->processEvents() instead of message boxes -
>>> didn't help. Any other ideas?
>> Yes.  Following Qt's programming model would probably help a lot.
>>
>> That means you need something event-driven, so the event loop runs and
>> you respond to events it generates.  Just as a rough example, you need
>> to have a class (say, "SocketEvent") that has slots that can receive
>> signals generated by your sockets.  Hook things up, and then run the
>> event loop.
>>
>> For example, if you are writing a console app, you could do something
>> like this (minimal and untested):
>>
>>     int main(int argc, char* argv[])
>>     {
>>         ...
>>         QCoreApplication app(argc, argv);
>>
>>         // set up sockets
>>         QTcpSocket* my_socket = new QTcpSocket();
>>         <further setup here>
>>
>>         // create my signal-processing class instance
>>         SocketEvent* my_socket_event = new SocketEvent(my_socket);
>>
>>         // connect signals to slots
>>         QObject::connect(my_socket_event, SIGNAL(readyRead()),
>> my_socket_event, SLOT(read_device()));
>>         <further setup here>
>>
>>         // run the Qt event loop
>>         int result = app.exec();
>>
>>         // clean up
>>         QObject::disconnect(my_socket_event, SIGNAL(readyRead()),
>> my_socket_event, SLOT(read_ready()));
>>         <further cleanup here>
>>
>>         delete my_socket_event;
>>
>>         // exit
>>         return result;
>>     }
>>
>> Qt will then perform the data processing and queuing for you within the
>> event loop, and your processing class ("SocketEvent") will receive
>> notification that data is ready without having to block and busy wait
>> things.
>
> Well, on a second thought though, i would like to further ask for
> assistance. The reason is that my software is going to send A LOT of
> signals (by these i mean not signal/slot mechanism, but integers sent to
> QTcpSocket) and not in a random, but in a very specific flowchart-like
> order (e.g. recv signal, if signal = 1 send signal 2, if signal = 2 send
> signal 3 etc). I can't really think of any practical way of achieving
> this with the scheme you mentioned, as i would have to set up a lot of
> slots for every possible scenario. So far my implementation looks like
> many nested switch/case statements, which is the most logical (to me, at
> least) way to achieve what i want to do.

This mechanism we've been discussing is merely a "data pump", a means of
getting the data to you in an event-driven fashion.  Interpreting the
data is entirely up to you (the application).  What you are referring to
above is the protocol, or "handshaking", that your client/server (or
P2P) arrangement requires, and this is (again) dictated by the design of
your solution.  Interpreting the incoming data can take on any form
necessary; as you point out, it may require a large switch statement, or
some other language-intrinsic mechanism.

If you must interpret the data, and respond, in real-time between the
socket clients (an approach in client/server programming that can lead
to deadlocks), you should be able to do this outside of the need to
acquire the data from the other end of the pipe, and sending data
responses back, which is what we've been talking about.