🚀 go-pugleaf

"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
>
>"Peter" <piotrtrzeciak@yahoo.com> wrote in message 
>news:4798a5e1$1@newsgroups.borland.com...
>
>> The original code was very simple:
><snip>
>
>Your original code was reading endlessly, as TIdTCPStream::Read() always 
>returns the same Count value that you pass in, so imageData->msg would 
>always be greater than 0 until an exception occured.  Such logic is easy to 
>reproduce using the code I already gave you earlier:
>
>    while( imageData->msg > 0 )
>    {
>        // assuming rcv_buffer is a TIdBytes.  ReadBytes() will not exit 
>until all 32000
>        // bytes have been received.  The same was true for 
>TIdTCPStream::Read() as well...
>        AContext->Connection->IOHandler->ReadBytes(imageData->rcv_buffer, 
>32000);
>        imageData->msg = 32000;
>        fwrite(&imageData->rcv_buffer[0], imageData->msg, 1, 
>imageData->imgFile);
>    }
>
>> but now, I'm trying this:
><snip>
>> and I get no data from the socket.
>
>Then your client is not sending any data at all, or is more likely sending 
>data after a small delay.  You are exiting your loop if the InputBuffer has 
>no data each time you check it.  The first time you check the InputBuffer, 
>if no data has arrived yet, you exit the loop right away.  At the very 
>least, you should increase your timeout value to give the data a better 
>chance of catching up to how fast your reading code is running.
>
>With that said, the best option is to forget looping at all.  Have the 
>client send the data size before sending the actual data.  Then your server 
>knows exactly how many bytes to expect, and can call ReadBytes() or 
>ReadStream() just once to do all of the work.  In fact, that is what you 
>said in your original posting that you were doing, but you are not doing 
>that anymore in this latest code snippet.  So by introducing InputBuffer 
>checking into your code, which you did not need in the first place, you have 
>made the code operate worse, not better.
>
>
>Gambit 
>
>

Thanks for your answers!!!
I wish this was that simple :-)
Unfortunately, the "client" in this case is a Mainframe imaging system (from Big Blue, which does not make it easier).
The whole communication sequence was "reverse-engineered" from the network traces a few years ago. Now... we get two kinds of data on the socket: image (binary, where we have no control how it's sent by the Mainframe), and data (which we control, and the communication is done exactly how your suggested :-)).
When getting the binary data, first I get a piece that contains a binary code that says "image", and then I have to read that image (not knowing how big it is).
Thanks for your help!!! If you have any points for me, I greatly appreciate them!!!

Peter