On Tue, Sep 6, 2016 at 4:23 PM, Konstantin Shegunov wrote:
> On Mon, Sep 5, 2016 at 7:17 PM, Nilesh Kokane
>> In the original example, How does disconnectFromHost() triggers
>> readyRead signal?
>
>
> You're blocking the event loop for the thread, so no queued slot invocations
> will be made until
On Mon, Sep 5, 2016 at 7:17 PM, Nilesh Kokane
wrote:
>
> 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
On 5 September 2016 at 15:38, Viktor Engelmann
wrote:
> Do you hard-code the client side port number? 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 pac
On Mon, Sep 5, 2016 at 8:08 PM, Viktor Engelmann 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 com
so you got the server running :-)
what was the problem?
Maybe it hangs inside waitForDisconnected? Have you tried waiting for
more than 30 seconds (the default timeout of the method)?
Do you hard-code the client side port number? the same
client-IP/client-Port/server-IP/server-Port combination
Hello,
I extended Threaded fortune to send message in infinite loop as below,
but then it only send once and I get the socket error. I've not
changed the fortune client but I only press Get fortune once and
expect the message to be sent continuously which isn't a case.
Is it really needed to abor