🚀 go-pugleaf

"Peter" <piotrtrzeciak@yahoo.com> wrote in message 
news:478e1c34$1@newsgroups.borland.com...

> pStream = new TIdTCPStream(AContext->Connection);
> msg = pStream->Read(imageData->rcv_buffer, 20);

You don't need to use a TIdTCPStream like that.  In fact, that class is 
primarily meant for Indy's internal use.  TIdIOHandler has its own reading 
methods that you should use instead, ie:

    TIdBytes rcv_buffer;
    AContext->Connection->IOHandler->ReadBytes(rcv_buffer, 20);

> discards it, then reads two bytes to see how long the remaining
> transmission is:
> msg = pStream->Read(imageData->rcv_buffer, 2);

Use the IOHandler's ReadSmallInt() method instead:

    calculated_length = AContext->Connection->IOHandler->ReadSmallInt();
    AContext->Connection->IOHandler->ReadBytes(rcv_buffer, 
calculated_length);

> Now, the first two reads come back ok, but then the calculated length
> is different on each connection (and it's the same client, so I assume it
> should be the same), and the last read never comes back (that length is
> usually very large, like 40k+)

Sounds like you are not taking endian into account.  Is the client sending 
the 2-byte length value in host byte order or network byte order?  It makes 
a big difference.  If you don't process it in the correct byte order, you 
will end up with the wrong value, potentially telling Indy to expect more 
data than is actually sent.

By default, ReadSmallInt() (and all of the other numeric reading methods) 
expects the value to arrive in network byte order and converts it to host 
byte order before exiting.  You can set the AConvert parameter to false to 
skip that step if needed.


Gambit