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. Unfortunately,
since Indy 10 is so different from Indy 9, we have been unable to track down
the problem. We were hoping that someone might have seen this before and
have a suggestion on where to look in Indy 10 for the source of this
problem.
For the time being, we have rolled back to Indy 9, but it has its own
problems as well. We have a report server (created with Report Builder)
that uses plug-ins (Delphi Runtime Packages) to generate individual reports.
When the user requests the report, the plug-in is dynamically loaded and the
report is generated. Then the plug-in is unloaded. Unfortunately, at the
beginning of each day or when no reports have been requested for a long
period of time, the follwoing exception is raised:
"EIdWS2StubError, Error on call Winsock2 library function socket: Either the
application has not called WSAStartup, or WSAStartup failed"
We have tracked it down to the fact that the finalization section of the
"IdStackWindows" unit is being executed after the finalization section of
the "IdWinSock2" unit causing the WSACleanup procedure to execute after the
WS2Unload procedure which has unloaded the Winsock 2 DLL. We are not sure
why this happens after long gaps between report requests, however, we have
theorized that it has something to do with the loading on unloding of our
plug-ins. Unfortunately, we have not found a solution, however, at least we
only see this error reported rarely, so it does not unduly disrupt our
production systems. Anyway, we would like to solve it and that is why we
started testing with Indy 10, but it appears to have more serious problems.
Mark
"Ciaran Costelloe" <ccostelloe@flogas.ie> wrote in message
news:44208f10$1@newsgroups.borland.com...
> Mark D. Lincoln wrote:
>
>> During our testing with Indy 10 (first with version 10.0.52 then
>> version 10.1.5.0), we keep running into an EIdSocketError being
>> raised with the message "Socket Error # 10054Connection reset by
>> peer". If our applications use Indy 9, this never happens.
>
> This may not be your problem, but I came across an issue like this when
> the server was returning a redirection. For all I know it was since
> fixed, and there may have been a better way of dealing with it, but for
> any redirects, I just destroyed that instance of TIdHTTP and created a
> new one, passing it the redirected url. The application is still
> running fine, so I never investigated it further.
>
> Ciaran
