🚀 go-pugleaf

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

>
>"Mike Ruskai" <BUTthannydI@DONTearthlinkLIKE.netSPAM> wrote in message 
>news:ghsqs35tipni65rjlntjpl7hgi6f1bv1g8@4ax.com...
>
>> Indy supposedly supports SOCKS, so I'm trying to figure out
>> how to convert the normal socket code to the bizarre usage of Indy.
>
>Simply attach a TIdSocksInfo to your TIdTCPClient.  It will handle the SOCKS 
>for you.  You don't have to change anything else in your reading/writing 
>code.

You misunderstood.  I'm using normal socket code (e.g. connect(),
select(), send(), recv(), etc.), not Indy.  I'm adding conditional
code that uses Indy instead when a SOCKS server is configured.

>> One problem is that there's no simple functional equivalent of recv()
>> for the IOHandler.
>
>Yes, there is, which you have already discovered - Readable() and 
>ReadBytes().

It's not equivalent at all.  recv() reads data up to the buffer length
specified.  ReadBytes() blocks forever until the specified data length
is read, or the socket is closed.  In other words, ReadBytes() is
useless for a normal program (i.e. one without a dedicated socket
reading thread) that doesn't know exactly how many bytes are going to
be sent over the socket.

>> However, while Readable() returns true, both ReadBytes() and
>> ReadLn() read nothing at all.
>
>Please show your actual code.

I got that bit sort of working, by adding a delay to Readable().  

It's still iffy to use.  There is simply no way I can see to loop
while receiving available data until the received data is deemed
complete (due to the high-level protocol definition).  A hack with
ReadTimeout and ReadBytes() sort of works, but is so sensitive to
network timing that it's worthless.

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.

Overall, however, I have to say that Indy is a huge pain to work with
for someone used to normal socket programming.