Does QSslSocket disconnect after a period of idle time?

[scieck]

Hi All,

after a client connects to a server, if nothing is sent between them do the sockets stay connected indefinitely?
In other words do QSslSockets or the wrapped native sockets have a build in idle timeout whereby if nothing is sent or received the sockets disconnect?

If sockets do auto disconnect after a period of idle time, how long is this time?
and if sockets do not auto disconnect after a period of idle time what is the role of the option:

QAbstractSocket::KeepAliveOption

QAbstractSocket::KeepAliveOption

To copy to clipboard, switch view to plain text mode 

Many Thanks
_andrea

[wysota]

after a client connects to a server, if nothing is sent between them do the sockets stay connected indefinitely?

It solely depends on the system policy of the two ends of the connection. Since there is no way to determine whether we're not receiving data because the other end doesn't have anything to say to us or it is long gone, systems usually assume the tcp connection is broken after some time (e.g. 15 minutes) of silence. Thus tcp stacks implement something called keep-alive to notify the other end they are still there.

[scieck]

...Since there is no way to determine whether we're not receiving data because the other end doesn't have anything to say to us or it is long gone, ...

Thank you wysota,

i don't understand something, when i kill the client, even without proper shutdown, the server immedialty emits the "QAbstractSocket::RemoteHostClosedError" error.
Should we not rely on this error been emitted in all cases ? so in some cases, it could be that the client is long gone and the socket on the server side does not know?

[wysota]

i don't understand something, when i kill the client, even without proper shutdown, the server immedialty emits the "QAbstractSocket::RemoteHostClosedError" error.

Not always. Pull the network cable out of your router and see if the remote server is notified about it. Or start dropping packets using your firewall software, the server will not have the slightest clue the connection was severed. Or just pull the power plug of one of the machines that are part of the network route from the socket. Or just satitate your link or start causing collisions to build up network congestion.

Should we not rely on this error been emitted in all cases ?

No, certainly not. Never rely on an external autonomous system (that is one you have no control over). "Trust no-one" as Agent Mulder would say

it could be that the client is long gone and the socket on the server side does not know?

Yes, of course.

[scieck]

If the QAbstractSocket::KeepAliveOption is set on both peers, if one of the two tcp sockets does not receive a keep-alive packet back in time is this triggered up the Qt level ?
so in other words by setting the keep-alive option can we findout if the other peer is still there or gone ? and can/should we trust keep-alive?

thanks again
_andrea

[wysota]

If the QAbstractSocket::KeepAliveOption is set on both peers, if one of the two tcp sockets does not receive a keep-alive packet back in time is this triggered up the Qt level ?

As already said, this is implemented by the operating system.

so in other words by setting the keep-alive option can we findout if the other peer is still there or gone ? and can/should we trust keep-alive?

Trust no-one. How can you be sure you're not talking to some alien implementation of the client? In networking you cannot dump any decision on your peer if you can't trust it. You have to be autonomous in your decisions. If you decide you need to receive some heart-beat from the client every 5 minutes and you don't receive it as expected then close the connection yourself without waiting for the tcp/ip stack to do it for you. And first of all understand how underlying protocols (at least tcp and ip) work, what they guarantee and what they don't guarantee.