On Mon, Sep 5, 2016 at 8:08 PM, Viktor Engelmann <viktor.engelm...@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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
