Ciaran,
Here is the problem with using the try...except to work around the problem,
it does not solve the root problem in Indy 10. It simple deals with the
simptom. In addition, once the error appears, the communication between the
client and server fails everytime, so the try..except would simply try
forever. What we really would like to know is why production code that has
run for four (4) years 24/7/365 on our servers with Indy 8 and then Indy 9
now does not work with Indy 10? What changed in Indy 10 that broke our
system?
As for the client code, we are simply using the Post() method of the TIdHTTP
class passing the URL, the request data stream, and a stream to be filled
with the response data.
Mark
"Ciaran Costelloe" <ccostelloe@flogas.ie> wrote in message
news:4421ef7b@newsgroups.borland.com...
> Mark D. Lincoln wrote:
>
>> Ciaran,
>>
>> Since we have created both the server and client applications, this
>> is not our problem. Also, since this occurs in Indy 10 and not in
>> Indy 9, there has got to be something up with the socket code in Indy
>> 10.
>
> There is no general problem with Indy 10's TIdHTTP. I have a couple of
> applications that use it to automate some processes, one of which pulls
> a pile of web pages off a server once a day after an average 23-hour
> delay between the web site getting updated. Each download is, however,
> wrapped in a try...except whereby if there was a "connection reset by
> peer", it would retry after a short delay - you should consider
> implementing this anyway, to deal with network problems, and it should
> sort your issue out.
>
> You could check it out further by running the free Ethereal packet
> sniffer to see exactly why the connection is being reset.
>
> If you showed your client code, someone here may spot a programming
> error.
>
> Ciaran
