OK guys i can confirm this is a bug in the Qt5.3 (linux version at least); as the exact same code on Qt5.5 on windows produces the followin output :
Message received: "Hello, world!"
Close code: 1002

Was already reported btw : [https://bugreports.qt.io/browse/QTBUG-42982](link url)

@Mark81 Sorry I have misled you, I was confusing the timeout on the wait...() functions with the asynchronous signals. You do not want the wait...() functions in the GUI thread as they block.

The first thing to note is that normal TCP/IP will retry 12 times to send a data segment taking up to 9 minutes before it causes an error.

I think you have two choices in the normal TCP/IP framework.

If you are sending data and expecting a reply, you can start a single shot timer that is cancelled if the reply is received but causes your communications failed code to run when it times out.

If you are just waiting for data then you will get no notification of errors as TCP/IP will wait forever on a disconnected circuit. So in this case you must have your server send you periodic "heartbeat" data to confirm its reachability.

@Bart_Vandewoestyne said:

Could my educated guess be correct?

Your guess sounds reasonable to me.

Does anybody have any idea why the original author of this code decided to make a difference between linux and non-linux? If I remove the ifdef and simply use close() in all situations, things seem to work, although it seems that in this case the ClientSslSocket destructor is no longer called (and I'm not sure if this is a good thing...).

Nope, sorry. Are there any comments in the code, or in the commit history? Could you ask the author directly?

What would be the clean solution here? How should FooBar's destructor look like?

It's hard to say without knowing how the rest of the program is designed. Maybe you can manually disconnect the socket before deleting it?