[Qt-interest] QTcpSocket timeouts

[Anatoly Burakov]

On 18.03.2010 22:08, Bob Hood wrote:
> 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.

Sorry i just forgot to change the recipient address... Anyway, i found
the running qApp->processEvents() after each statements involving
streams cured the problem (i had to do it on both sides - client and
server).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5238 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100318/ab3d9eeb/attachment.bin