TidHTTP: EIdSocketError Socket Error # 10054 Connection reset by peer

[Sam]

Group,

Indy9.0.14 reports a EIdSocketError exception of "Socket Error # 10054
Connection reset by peer."

I get this error from TidHTTP on my client for a POST or a GET when my
ASP.NET web server takes a long time to response back to my client.

Is there a way around this. All subsequent requests by TidHTTP fail after
this error occurs.

BTW I am using Delphi6.

TIA,

-Sam

[Sam]

Post by Sam
I get this error from TidHTTP on my client for a POST or a GET when my
ASP.NET web server takes a long time to response back to my client.

Correction - I get this error after leaving the application stand idle for
5 minutes or more. Then any attempt to make another request causes a #10054
Connection reset by peer.

What is causing this?

[Remy Lebeau (TeamB)]

Post by Sam
Correction - I get this error after leaving the application stand
idle for 5 minutes or more. Then any attempt to make another
request causes a #10054 Connection reset by peer.

Please show your actual code, both server and client.


Gambit

[Sam]

Post by Remy Lebeau (TeamB)
Please show your actual code, both server and client.

The server code is ASP.NET. All it does is receive XML content. And response
with XML content.

Here is the guts of the client code that basically prepares an XML request
and waits for an XML response:

function TDataLayer.HttpPostXml(url: string; postdata: TdomNode):
TdomDocument;
var
request, response: TMemoryStream;
sl: TStringList;
xml: TdomDocument;
uri: TIdURI;
begin
uri := TIdURI.Create();
request := TMemoryStream.Create();
response := TMemoryStream.Create();

try
xwriter.writeToStream(postdata, 'utf-8', request); //xwriter is a
TDomToXmlParser component
request.Position := 0;
url := uri.URLEncode(url);
http.Post(url, request, response);
response.Position := 0;
xml := xreader.streamToDom(response); //xreader is a TXmlToDomParser
component

if xml.getElementsByTagName('Exception').length > 0 then begin
Result := nil;
LogException(xml.getElementsByTagName('Exception').item(0));
end else begin
Result := xml;
end;
except
on e: Exception do begin
LogException(e, 'HttpPostXml');
Result := nil;
end;
end;

request.Free();
response.Free();
uri.Free();
end;

[Remy Lebeau (TeamB)]

Post by Sam
The server code is ASP.NET. All it does is receive XML content.
And response with XML content.

Then why would it take so long to respond in the first place? If you leave
things sitting long enough, eventually TIdHTTP is going to timeout
internally (unless you set its ReadTimeout property really high). Are you
using KeepAlives at all? If not, then each new request is going to create a
new connection, so even if one connection times out and is closed, future
requests should not be erroring like you have described.


Gambit

[Sam]

Post by Remy Lebeau (TeamB)
Then why would it take so long to respond in the first place? If you leave
things sitting long enough, eventually TIdHTTP is going to timeout
internally (unless you set its ReadTimeout property really high).

Remy, thanks for the reply.

I want you to know that my TidHTTP.ReadTimeOut property is set to 1 minute.
This is fine so far and is not causing any time-out errors so far.

Actually the behavior that is causing the problem is:

1. User fires up his/her PC.
2. User logs into application. (this is done against SQL server, no IIS yet)
3. User enters an order using the Order Entry application. This is
considered the first web request here and takes the longest. No problem.
4. User enters many more orders. No problem.
5. User steps away from PC for 5 minutes.
6. User attempts to enter another order. Problem error arises. Socket Error
#10054 Connection reset by peer.

Looking at the above behavior it almost seems that TidHTTP assumes that the
connection is still alive after 5 mintues and tries to re-use a connection
that is stale? Made stale by who? I am not sure!. And I always thought the
HTTP protocol is connectionless? It thought its about
connect-request-receive-disconnect? Isn't it?

Post by Remy Lebeau (TeamB)
Are you using KeepAlives at all? If not, then each new request is going

to create a

Post by Remy Lebeau (TeamB)
new connection, so even if one connection times out and is closed, future
requests should not be erroring like you have described.

I am not familiar with KeepAlives but I found this setting on IIS Website
Properties. And the feature IS enabled. How does this KeepAlives setting
affect to connection between IIS and TidHTTP? Maybe I should turn this off?

Does all this have to do with KeepAlives?

[Remy Lebeau (TeamB)]

Post by Sam
6. User attempts to enter another order. Problem error arises.
Socket Error #10054 Connection reset by peer.

Did you leave the connection to the server open for that 5 minutes? Sounds
like the server itself has timeouts as well, and since your app didn't do
anything for 5 minutes, it kicked out the program's connection to the
server.

Post by Sam
Looking at the above behavior it almost seems that TidHTTP
assumes that the connection is still alive after 5 mintues and
tries to re-use a connection that is stale?

TIdHTTP does not "assume" anything. The only way that would happen is if
the HTTP KeepAlive feature was actually used. In which case the conection
would remain active.

Post by Sam
Made stale by who?

The server, aka the "peer" for your client program.

Post by Sam
And I always thought the HTTP protocol is connectionless?

HTTP is built on top of TCP, so there is *always* a connection. Whether
that connection remains active or not after each request, on the other hand,
is a separate issue. The HTTP protocol provides a means of keeping
connections open or for making them be closed each time.

Post by Sam
It thought its about connect-request-receive-disconnect? Isn't it?

It can be, but that is not the only way it can work.

Post by Sam
I am not familiar with KeepAlives but I found this setting on IIS
Website Properties. And the feature IS enabled. How does
this KeepAlives setting affect to connection between IIS and
TidHTTP?

If a KeepAlive is issued, then TIdHTTP will keep the connection open after
the response has been returned. You can check the TIdHTTP's
Response.KeepAlive property to see if it was set to true during the
response. Or just Disconnect() the socket manually if desired.


Gambit

[Sam]

Post by Remy Lebeau (TeamB)
If a KeepAlive is issued, then TIdHTTP will keep the connection open after
the response has been returned. You can check the TIdHTTP's
Response.KeepAlive property to see if it was set to true during the
response. Or just Disconnect() the socket manually if desired.

Remy, its working. Basically I'm doing a TidHTTP.DisconnectSocket() manually
prior to any request.

Thanks for all the help - Cheers!!!

[Remy Lebeau (TeamB)]

Post by Sam
Remy, its working. Basically I'm doing a TidHTTP.DisconnectSocket()
manually prior to any request.

If you set the Response.KeepAlive property to false prior to calling
Get/Post(), then TIdHTTP will disconnect the socket for you internally on
each request if the socket is still connected.


Gambit