🚀 go-pugleaf

On or about Tue, 4 Mar 2008 14:12:01 -0800 did "Remy Lebeau \(TeamB\)"
<no.spam@no.spam.com> dribble thusly:

>
>"Mike Ruskai" <BUTthannydI@DONTearthlinkLIKE.netSPAM> wrote in message 
>news:tefrs3lpnfkk0arr2qa3vospikaj3j491h@4ax.com...
>
>> You misunderstood.  I'm using normal socket code (e.g. connect(),
>> select(), send(), recv(), etc.), not Indy.
>
>You can't use TIdSocksInfo with a non-Indy connection, and there is no way 
>to assign your own SOCKET handle to Indy's classes without re-writing them.

You misunderstood again.  The above is to explain that I have normal
socket code, not Indy code, which means your previous comment about
assigning a TIdSockInfo and leaving the rest of the code alone didn't
apply.

I'm not trying to use TIdSocksInfo with normal socket calls.

>
>> recv() reads data up to the buffer length specified.
>
>So does ReadBytes().
>
>> ReadBytes() blocks forever until the specified data length is read,
>> or the socket is closed.
>
>Or until a ReadTimeout elapses, if specified.

Which means you have to pick an arbitrary length of time you're
willing to have the program sit doing nothing, because there's no
function to read UP TO a number of bytes, from whatever's available,
without blocking until that number of bytes is completely filled.

>> In other words, ReadBytes() is useless for a normal program
>
>Not really.  If you want to just read what is currently available, up to but 
>maybe less than the desired length, then simply call the ReadFromSource() 
>method first and then adjust the length based on the InputBuffer's current 
>size.  For example:
>
>    IOHandler->ReadFromSource(true, 10, false);
>    IOHandler->ReadBytes(buffer, min(1024, IOHandler->InputBuffer->Size));
>
>> that doesn't know exactly how many bytes are going to be sent over the 
>> socket.
>
>Most protocols are designed to offer a way of knowing that.  But for those 
>rare cases where it simply is not, then that is why the ReadFromSource() 
>method and the InputBuffer property are publically accessible.

As it happens, ReadFromSource() is *not* publically accessible.  It's
protected.  

One of the big problems here is documentation.  All I have to go by is
the Indy 10.1.1 docs in BCB2007, since there's no hint of
documentation on the Indy home page.

From those docs, I can see that CheckForDataOnSource() calls
ReadFromSource() internally, so is a suitable replacement for your
suggestion.  It seems to work as intended, provide I use a Readable()
call before hand as an equivalent to select().

So thanks for that.

>> As it happens, the current design uses text-only data on the control
>> connection, so ReadLn() might work for command responses.  The
>> data connection exists only for the duration of the transfer, so
>> ReadBytes() may actually work out.
>
>Sounds like you are reproducing exactly what the FTP protocol already does.

Well, yes.  Aside from the fact that none of the commands match those
of FTP, the command response format is different, the data transferred
is not the contents of a file.  It's a proxy that sits between a
desktop client and a database server.  I modelled the basic design on
FTP, which I've written clients for.