🚀 go-pugleaf

"DWilkinson" <dennis.c.wilkinson@boeing.com> wrote in message
news:4408c710$1@newsgroups.borland.com...

> My program is hanging on a socket read (
...IdTCPClient1->Socket->Recv(msg, 600); )

You should not be calling Recv() directly.  Use the TIdTCPClient's own
ReadBuffer() method instead:

    IdTCPClient1->ReadBuffer(msg, 600);

Timeouts are handled at a higher level, but you are trying to access a
lower-level method.

> despite having set the Readtimeout

Recv() is not subject to the ReadTimeout.  That is why you should not be
calling the IOHandler's reading methods directly.


Gambit

"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
>
>"DWilkinson" <dennis.c.wilkinson@boeing.com> wrote in message
>news:4408c710$1@newsgroups.borland.com...
>
>> My program is hanging on a socket read (
>...IdTCPClient1->Socket->Recv(msg, 600); )
>
>You should not be calling Recv() directly.  Use the TIdTCPClient's own
>ReadBuffer() method instead:
>
>    IdTCPClient1->ReadBuffer(msg, 600);
>
>Timeouts are handled at a higher level, but you are trying to access a
>lower-level method.
>
>> despite having set the Readtimeout
>
>Recv() is not subject to the ReadTimeout.  That is why you should not be
>calling the IOHandler's reading methods directly.
>
>
>Gambit
>
>

The reason I was using Recv() rather than ReadBuffer() is that I get no response other than a time-out when I do. 

I assume the reason for this is that ReadBuffer() does not return until the read buffer has been filled. 

However, in my application, I don't know size of the incoming message beforehand, other than the maximums.

So how do I read variable length messages?

Your assistance is greatly appreciated!

"DWilkinson" <dennis.c.wilkinson@boeing.com> wrote:
>
>"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
>>
>>"DWilkinson" <dennis.c.wilkinson@boeing.com> wrote in message
>>news:4408c710$1@newsgroups.borland.com...
>>
>>> My program is hanging on a socket read (
>>...IdTCPClient1->Socket->Recv(msg, 600); )
>>
>>You should not be calling Recv() directly.  Use the TIdTCPClient's own
>>ReadBuffer() method instead:
>>
>>    IdTCPClient1->ReadBuffer(msg, 600);
>>
>>Timeouts are handled at a higher level, but you are trying to access a
>>lower-level method.
>>
>>> despite having set the Readtimeout
>>
>>Recv() is not subject to the ReadTimeout.  That is why you should not be
>>calling the IOHandler's reading methods directly.
>>
>>
>>Gambit
>>
>>
>
>The reason I was using Recv() rather than ReadBuffer() is that I get no response other than a time-out when I do. 
>
>I assume the reason for this is that ReadBuffer() does not return until the read buffer has been filled. 
>
>However, in my application, I don't know size of the incoming message beforehand, other than the maximums.
>
>So how do I read variable length messages?
>
>Your assistance is greatly appreciated!
>

Also, incoming data has no terminator character, so I don't think I can use ReadLn() either. And IdAntiFreeze doesn't seem to do anything, as the application is hung until the timeout occurs when using ReadBuffer().

Again, thank you for your help.

"DWilkinson" <dennis.c.wilkinson@boeing.com> wrote in message
news:440c9e1f$1@newsgroups.borland.com...

> The reason I was using Recv() rather than ReadBuffer() is
> that I get no response other than a time-out when I do.

The only way that can happen is if you are trying to read more data than is
actually being sent.  Like most of the other reading methods, ReadBuffer()
waits for the entire requested data block to be available before it exits.
If you ask it to read 100 bytes, for example, then it will not return until
at 100 bytes are available (or until a timeout or error occurs).

> However, in my application, I don't know size of the incoming
> message beforehand, other than the maximums.

Why is that?  That is not a very good design.

If you have control over the design of the protocol, then the best choice is
to send a fixed-length value specifying the length of the following data,
before then sending the actual data.  That way, the receiver can read the
length first, since it always knows how many bytes to read for that value,
and then it can use that value to finish reading the remaining data that
follows it.  You can use the Read/WriteInteger() methods for that, for
example:

    IdTCPClient1->WriteInteger(size of my data);
    IdTCPClient1->WriteBuffer(my data, size of my data);
    ...
    int BufSize = IdTCPClient1->ReadInteger();
    // allocate a memory buffer as needed, then ...
    IdTCPClient1->ReadBuffer(Buffer, BufSize);

If you don't have control over the design, and must read whatever is
available regardless of the length, then use the ReadFromStack() method.  It
returns how many bytes were actually received, or -1 on timeout.

    int NumRead = IdTCPClient1->ReadFromStack(true, IdTimeoutDefault,
false);
    if( NumRead > 0 )
    {
        // allocate a buffer as needed, then...
        IdTCPClient1->ReadBuffer(Buffer, NumRead);
        // use buffer as needed...
    }
    else if( NumRead == 0 )
    {
        // disconnected, the ClosedGracefully property will be set
        // to true, and any further reading/writing operations on the socket
        // will throw an EIdConnClosedGracefully exception
        //
        // do something else ...
    }
    else
    {
        // reading timeout, no data received yet
        //
        // do something else...
    }


Gambit

"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
>
>"DWilkinson" <dennis.c.wilkinson@boeing.com> wrote in message
>news:440c9e1f$1@newsgroups.borland.com...
>
>> ..in my application, I don't know size of the incoming
>> message beforehand, other than the maximums.
>
>Why is that?  That is not a very good design.
>

Agreed, but I'm interfacing to an existing server design on a Sun Unix box. I will use the ReadFromStack method you recommended. Thank you very much; you are providing a valuable service here!