title: Can Windows Socket #10060 error (WSAETIMEDOUT - An attempt to connect timed out without establishing a connection) be a programming error at all?
body: <p>I have Delphi application that uses Indy HTTP components (that uses Windows socket). And from time to time I am receiving #10060 socket error (WSAETIMEDOUT - An attempt to connect timed out without establishing a connection) upon execution of Indy procedure:</p>
  
  <pre><code>CheckForSocketError(IdWinsock2.Connect(ASocket, @LAddr, SizeOf(LAddr)));
  ...
  connect : TconnectProc;
  ...
  TconnectProc = function ( const s: TSocket; const name: PSockAddr; const namelen: Integer): Integer; stdcall;
  </code></pre>
  
  <p>Actually all this is just wrap around Windows connect function <a href="https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-connect" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-connect</a> that gives error and message WSAETIMEDOUT. So - my question is - can this be programming error at all? Even if I have server running on the other computer and even that server has trouble serving request, even in such cases the low level connect should execute normally, if the server can not serve the GET/POST request, then, of course, the errors should be but those errors should spring in only during execution of other Socket functions not in the <code>connect</code> function, isn't so?</p>
  
  <p>I am trying to solve my problem <a href="https://serverfault.com/questions/973648/is-it-possible-that-unencrypted-traffic-can-cause-windows-socket-10057-10060?noredirect=1#comment1266907_973648">https://serverfault.com/questions/973648/is-it-possible-that-unencrypted-traffic-can-cause-windows-socket-10057-10060?noredirect=1#comment1266907_973648</a> and now I am seeking whats happening in my code.</p>
  
  <p>My server side code is very simple - it is just TIdHttpServer component with implemented (I provide event name only here):</p>
  
  <pre><code>MyForm.IdHTTPServerCommandGet(AContext: TIdContext;
    ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
  </code></pre>
  
  <p>So - what can be worng with my implemention, what can lead to the appearance of <code>WSAETIMEDOUT</code> for <code>connect</code>? Yes, my procedure can be long sometimes, but it for years it returned the answer sucessfully and there were no communication errors. And I guess, that connect function can even not depend (does not use/raise) OnCommandGet event, so, I have no control how the server side handles socket connect function from the client? </p>
  
  <p>It may be possible that this is connected with TCP (not HTTP) keepalive, maybe some Windows updates have reduced client-side settings of Windows TCP keepalive for the clients and now this manifests as such error.</p>