Remy Lebeau (TeamB) schrieb:
> "Michael Stieler" <michael.stieler@rie.eu> wrote in message
> news:479619da$1@newsgroups.borland.com...
>
>> I have the following problem with Indy 10.1.6:
>
> That is a very old version. The current version is 10.2.3. You should
> consider upgrading.
Okay, I updated. I read about your efforts to improve the project. Thank
you, Indy is a important piece of software.
>
>> - I check for ReadLnTimeout or exceptions in this call
>> - If one of these occure, I call conn.Disconnect
>
> You should always call Disconnect() when you are done with the connection.
I do.
>
>> Now I do something the program can't handle: I remove the
>> network cable from the computer.
>
> You should not be doing that in the first place. That is a very poor way to
> test unexpected disconnects.
I know and we also test other ways of unexpected disconnects but a lose
of power of the network devices already occured at a large customer of
us, so the software has to cope with this. (Removing the network cable
seems to have the same effect as switching off the router the PC is
connected to)
>
>> => The ReadLn call throws an exception: Socket Error # 10054
>> Connection reset by peer.
>
> There is no standard that says what kind of error is generated when pulling
> out the cable. There is no guarantee that an error will even be generated
> at all. That is strictly up to the OS to decide, and I have seen different
> things happen on different OSs.
Ok.
>
>> If I call the Connected Function it ALSO throws the same exception
>> and Connect doesn't work either.
>
> The Connected() method has to read from the socket in order to determine its
> status.
>
>> So I tried the following work-around to close the connection:
>
> That is redundant. You don't need to call Connected() first. Just call
> Disconnect() by itself. It will either succeed or fail:
>
> try
> conn.Disconnect;
> except
> end;
I will fix this.
>
>> But even this doesn't allow me to call conn.Connect at a later
>> time, because the exception is again thrown.
>
> Then the socket is not fully closed.
.. but closing doesn't work either, this is what I didn't believe.
>
>> How can I leave this state?
>
> Destroy the TIdTCPClient instance and reinstantiate it anew.
Okay, I was asking because I wanted to make sure there is no "cleaner"
solution. I agree losing the network cable is not-standard but it can
happen and I'm surprised that there's no way to do a recover.
Let's see what the new version brings..
Michael
