QAbstractSocket error signal not emitted

koahnig · 3 Dec 2015, 20:29

@Mark81
I had wondered about @kshegunov 's remark. Therefore, I looked it up and found the text section to my surprise.

However, the "and" is wrong as far as I know, you should use either one but not both.
qRegisterMetaType and Q_DECLARE_METATYPE .

The other things is that you have mentioned that there has been no warning in a debug window, but you should see one when the type is not registered. Therefore, try again without registration and if there is a warning.
Since you checked already the header file and a declaration is there, this is pointing towards a bug in documentation.

And you are right another declaration shall not be required then.

However, coming back top your initial problem. Just to be sure. Did you check with an error condition?

kshegunov · 12 Mar 2015, 20:38

@Mark81
Actually you'll probably need only Q_DECLARE_METATYPE as this is done at compile time - exposing the type to the metatype system (I know it is an enum but it's needed for the QVariant and the like). qRegisterMetaType you'll need if creating objects by class name dynamically, and it seems for queued connections, generally you won't need to call that function, but I suggest you do.

@koahnig
Directly from the documentation: "Adding a Q_DECLARE_METATYPE() makes the type known to all template based functions, including QVariant. Note that if you intend to use the type in queued signal and slot connections or in QObject's property system, you also have to call qRegisterMetaType() since the names are resolved at runtime."
Sometimes you need both.

Mark81 · 12 Apr 2015, 06:42

@koahnig
It would be interesting to know when the Q_DECLARE_METATYPE lines at the bottom of QAbstractSocket.h were added. Perhaps the docs was not updated after that, so now it should look like: "QAbstractSocket::SocketError is a declared but not a registered metatype, so for queued connections, you will have to register it with qRegisterMetaType()."
It's weird no one else in the world has ever used this signal!

Anyway, to test the error signal I'm simply trying to connect to my server (which works under normal conditions) with the Ethernet cable disconnected.

I'm expecting at least one of the following errors:

QAbstractSocket::ConnectionRefusedError	0	The connection was refused by the peer (or timed out).
QAbstractSocket::HostNotFoundError	    2	The host address was not found.
QAbstractSocket::SocketTimeoutError	    5	The socket operation timed out.
QAbstractSocket::NetworkError	        7	An error occurred with the network (e.g., the network cable was accidentally plugged out).

I also tried to connect before and then unplug the network cable. Nothing.

Mark81 · wrote on 4 Dec 2015, 07:13

Oh dear! It works Even without qRegisterMetaType() - so the docs are definitely wrong.
But it takes a huge time before fire, something about 30 s! This if I try to connect without the cable. After 30 seconds I get the NetworkError message.

On the other hand, if I establish the connection and then I unplug the cable nothing happens, even after few minutes.
Anyway I cannot wait for such a long time to inform the user the device is not connected anymore. I'm afraid I need to implement by myself a sort of software "ping" to be sure the remote device is still there. What a pity.

bsomervi · 4 Dec 2015, 19:53

The default time out on QTcpSocket is 30s, you can reduce it if you want more responsive failure detection but you should be sure that you do not use a timeout less than normal round trip latency to the server.

The docs are not wrong, you only need to register the types for Queued signal/slot connections as several have said above. Non-queued signal/slot connections are simply member function calls.

koahnig · 4 Dec 2015, 13:15

To add to @bsomervi there you have the default waiting time of 30 seconds

@bsomervi said:

The docs are not wrong, you only need to register the types for Queued signal/slot connections as several have said above. Non-queued signal/slot connections are simply member function calls.

This is the first time I have seen such a difference for signal-slot connections. However, certainly I know only a small fraction of the documentation.
If you say so, I assume that you are correct about different behaviour for queued and non-queued connections.
The documentation is at least a bit ambiguous in that respect and the sentences might require a revision for clarity.

kshegunov · 4 Dec 2015, 16:32

@koahnig said:

This is the first time I have seen such a difference for signal-slot connections.

It pops out every time you write a class that you intent to use as a signal/slot parameter in multithreaded application.

koahnig · wrote on 4 Dec 2015, 16:32

@kshegunov

That there is a difference between queued and non-queued is clear.
I had meant that there is difference in registered objects between queued and non-queued connections.
I came across the need to register for my own classes. So far I thought that all Qt classes are registered alreay. Thought to have read a reference somewhere, but also quite a while ago.

Mark81 · wrote on 4 Dec 2015, 19:53

@bsomervi

The default time out on QTcpSocket is 30s, you can reduce it if you want more responsive failure detection

English is not my primary language, thus I apologize if sometimes it's hard to understand what I'm reading. Anyway I read through the docs and I cannot find how to reduce this timeout. As @koahnig said I could use the waitForConnected() function but: 1. the docs say it may fail randomly on Windows, 2. it blocks the execution of my code, 3. it could work only during connection, but it isn't useful to detect a failure (i.e. the cable disconnected after).

I cannot find a method like: setTimeout() or similar.

Currently the only way I found is to periodically send back and forth a message: when I don't receive the answer in few seconds I assume the connection is lost. I hate this approach, though! I'm pretty sure the system knows if a TCP socket isn't alive anymore!

bsomervi · 12 Apr 2015, 23:45

@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.