🚀 go-pugleaf

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

> The entire amount of data was sent over the socket

That does not necessarily mean that the client will be able to read all of 
it, though.  It is up to the OS whether the disconnect is reported before or 
after all of the bytes have actually been read.

> and received into the input buffer.

If the InputBuffer already had all of the necessary bytes in it prior to 
calling ReadBytes(), then ReadFromSource() and CheckForDisconnect() would 
not be called at all.

If the InputBuffer did not have enough bytes, but ReadFromSource() received 
all of the necessary bytes, then it would not set the ClosedGracefully 
property to True, CheckForDisconnect() would not raise an exception, and the 
loop would exit and return the requested bytes.

Again, the ONLY way for CheckForDisconnect() to raise an exception is if the 
ClosedGracefully property was set to True.  For that to happens, recv() had 
to have returned 0 (or WSAESHUTDOWN or WSAECONNABORTED with a non-empty 
InputBuffer) inside of ReadFromSource(), indicating that there is no more 
data available to read and the connection is no longer active.

> The problem is that ReadBytes() fails to check the input buffer
> if there's no more data to read directly from the socket.

The only way for ReadBytes() to know that there is no more data to read from 
the socket is if the socket reports a disconnect inside of ReadFromSource(). 
ReadBytes() calls ReadFromSource() only when the size of the InputBuffer is 
not sufficient.  Even if ReadFromSource() fills the InputBuffer to the right 
size, the ClosedGracefully property WOULD NOT be set to True, 
CheckForDisconnect() WOULD exit without an error, the loop WOULD stop, and 
ReadBytes() would call ExtractBytes() and exit normally.

So what is the actual problem???  I still do not see any.  This logic has 
been running in Indy for YEARS without any problem.

> So it throws the exception, which leaves no recourse but to read from
> the buffer directly for the last bit of data that was sent.

It does not raise an exception while data is still being received into the 
InputBuffer.  You have not proved otherwise yet.  The exception cannot be 
raised until the socket stops providing data, which can only happen when you 
are asking ReadBytes() for more bytes than are actually available.

> But I said that from the start - ReadBytes() wants to block until it
> gets the total requested bytes

That is how it is designed and meant to work.

> when a proper function of the sort would read UP TO that number
> of bytes, returning anywhere from 0 to the requested number.

That is NOT what ReadBytes() is meant for, that is NOT how it is designed, 
and that is NOT how Indy is designed to be used in general.  Indy is a 
blocking library.  It waits for the requested number of bytes.  That is a 
core fundamental design shift from standard socket API programming 
practices.  That is how it is designed from the ground up to work.  It 
intentionally handles all of the "I-asked-for-X-but-only-got-Y" logic 
internally so the developer doesn't have to anymore.  Indy uses a different 
paradigm to socket programming than most socket developers are used to.  If 
this is not the kind of functionality you want, then Indy is not the right 
choice for you.  Go use an asynchronous socket library instead.  That is the 
kind of thing they are good at - making you work more to accomplish the same 
tasks manually.

> Or at the least, it would only block until it receives at least 1 byte.

That is what ReadFromSource() does, until a timeout elapses (if specified).

> As it is, the function is documented as either waiting until that number
> of bytes is read, or until the socket is disconnected.

That is exactly what it does.

> But when the socket is disconnected, it's not retrieving the last bytes
> from the buffer

Yes, it does, when used properly.

> necessitating the workaround I used.

Then you are clearly still using it wrong.  Such workarounds are NOT needed 
to use Indy effectively.  Please show a more complete snippet of how exactly 
you are using it.

> If you can show "proper" usage of ReadBytes() that doesn't require
> going to the buffer for the last bit of data, I'm all eyes.

Or, you could show what you are trying to do in the first place, and then 
someone can tell whether you are using it right or wrong.


Gambit