[Qt-interest] QTcpServer timeout ?

[BRM]

The TCP Stack Keep Alive is the proper way to do this.Every modern TCP stack 
supports TCP Keep Alive. TCP KeepAlive is  explicitly provided so that you don't 
have to do it in your application.

The only thing the local sys admin can do is completely disable that 
functionality, but to do that, it would have to be a special kernel build, and 
the likelihood of that is low especially in a company environment; add to that 
the further likelihood that the admin would disable TCP KeepAlive and your 
practically guaranteed that won't happen unless you are working in an embedded 
environment, but then you would be aware of that as one of the developers and 
could affect the project accordingly. Otherwise, it's just disabled by default 
and setting it will enable it for that connection.

And, btw, nearly every modern OS now provides its own firewalls as well - so 
you're not just dealing with the firewalls between LANs and WANs, etc; your 
dealing with the firewalls of the two computers you are directly talking with - 
even when you use localhost (though usually firewalls are configured to allow 
all comms on localhost, but not necessarily so). So for network-oriented 
programs, it would most definitely be in their interest to account for 
firewalls.

Now, I can agree that this isn't necessarily the _only_ problem he is having; 
but it is still a likely culprit; and this should at least help generate the 
Disconnected signal for the connection - which you may not necessarily see until 
you try to write something to the socket.

Ben

From: Stephen Collyer <scollyer at netspinner.co.uk>
>
>Cc: QtInterest <qt-interest at trolltech.com>
>Sent: Wed, July 21, 2010 9:25:47 AM
>Subject: Re: [Qt-interest] QTcpServer timeout ?
>
>
>On 21 July 2010 14:07, Atlant Schmidt <aschmidt at dekaresearch.com> wrote:
>
>Stephen:
>>  You are correct that generic TCP connections don’t “inherently” time out.
>>  But many, many TCP connections in the real world (in the situations I
>>  mentioned such as firewalls, public carriers, and the like) absolutely
>>  DO timeout. 
Yes, that's a good point - a firewall could be closing a connection. 
If it's the kind of app. that has to survive in such an environment, I
would recommend that they implement an application level keepalive
though - that won't be dependent upon the vagaries of the underlying
OS or local sys admin (who may have changed the kernel level TCP
keepalive settings without your knowing it).

>-- 
>Stephen Collyer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100721/82a48771/attachment.html