[Interest] ThreadedFortune example extending to send message forever

Nilesh Kokane nilesh.kokane05 at gmail.com
Mon Sep 5 18:17:44 CEST 2016


On Mon, Sep 5, 2016 at 8:08 PM, Viktor Engelmann <viktor.engelmann at qt.io> wrote:
> so you got the server running :-)

Yes :-)

> what was the problem?

Firewall. Reinhardt and Thiago guessed it right.

> Maybe it hangs inside waitForDisconnected?

Could be.

I played with the ThreadFortune server and found that when I commented
disconnectFromHost() & waitForDisconnected() from the thread and
instead call  exec(), then I get readReady signal from the client end.
But when I don't call exec I dont.

In the original example, How does disconnectFromHost() triggers
readyRead signal?

Qt doc says that it only emits disconnected() signal at the server
side. QAbstractSocket will enter ClosingState and wait until all data
has been written.

So, does it forcefully flushes data out to trigger readyRead() signal
at the client side?

>Have you tried waiting for more than 30 seconds (the default timeout of the method)?

No, I'll give a try.

> Do you hard-code the client side port number?

Yes

>the same client-IP/client-Port/server-IP/server-Port combination cannot be used again > within 2 minutes after a disconnect - the operating system suppresses that. That is to > prevent late packets from the old connection to be falsely passed to the new
> connection. After 2 minutes, such packets must have timed out and be dropped, so
> the same combination can be reused safely.

I see.




--
                 Nilesh Kokane



More information about the Interest mailing list