🚀 go-pugleaf

"Mike Ruskai" <BUTthannydI@DONTearthlinkLIKE.netSPAM> wrote in message 
news:c65us3ljh7nr89gl6i6sojfkumfuup7qrt@4ax.com...

> Sometimes I forget I have code available to check.  I checked
> the code, and I see exactly how this is happening.
>
> Here's the relevant bit in IdIOHandler.pas (lines numbered for reference):
<snip>

Your analysis, although technically accurate, is misplaced in this 
situation.

ReadFromSource() retreives whatever data is currently pending in the socket 
at that moment.  ReadFromSource() sets the ClosedGracefully property to True 
only if the socket API recv() function returns 0 bytes after Readable() had 
returned True.  If even 1 byte is read, the ClosedGracefully property is not 
set to True.  CheckForDisconnect() can only raise the exception if the 
IOHandler's ClosedGracefully property has been set to True beforehand.

ReadBytes() does not call ReadFromSource() if there are already enough bytes 
stored in the InputBuffer to satisfy the caller.  It only goes to the socket 
when it absolutely needs to.  ReadBytes() is required to return all 
requested bytes, or fail otherwise.  If the socket reports a disconnect 
before all of the necessary bytes have been buffered, an exception is 
raised.  That is by design.  Changing ReadBytes() to pass False instead of 
True to the AIgnoreBuffer of CheckForDisconnect() would break that design, 
which in turn will break every method that relies on that design.  What you 
have described so far does NOT warrant such a change.

Think about it.  The server sends 1024 bytes and then disconnects.  Your 
client calls ReadBytes(..., 1024).  ReadBytes(), seeing that the InputBuffer 
does not hold enough bytes yet, calls ReadFromSource().  1 of 3 things will 
happen:

1) at least 1 byte will be read from the socket.  All of the received bytes 
will be stored in the InputBuffer, ReadFromSource() will exit without 
setting the ClosedGracefully property to True, CheckForDisconnect() will 
exit without error, and ReadBytes() will check the InputBuffer again.  If 
needed, the cycle continues for another iteration.

2) no bytes are received.  This means the socket reported a disconnect 
before all of the expected bytes could be read.  ReadFromSource() will set 
the ClosedGracefully property to True and exit.  CheckForDisconnect() will 
see that the ClosedGracefully property is True and raise an exception. 
ReadBytes() was expecting 1024 bytes, but only received (1024-X) bytes.  The 
socket has already discarded the remaining bytes.  There is nothing Indy can 
do about that.  Raising an exception is the proper behavior.

3) the socket reports an actual error.  An exception will be raised 
accordingly.

So, given the example you have shown earlier, the only way an 
EIdConnClosedGracefully exception can be raised is if the socket itself is 
actually reporting a disconnect before all of the expected bytes could be 
read from it.  If you are seeing ReadBytes() raise an exception too early in 
your code, then that is the only thing that can be happening.  The only 
reason to catch the exception and call ExtractToBytes() manually would be if 
you don't care that a disconnect was reported prematurely and want to 
continue processing whatever data was successfully buffered beforehand. 
Which, in most cases, will fail anyway since the data is incomplete and will 
likely break whatever protocol you are implementing.


Gambit