🚀 go-pugleaf

"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.

> 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.

> 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, 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.


Gambit