🚀 go-pugleaf

"Billy Holliday" <NoSpam@Hohoho.com> wrote in message 
news:43312e17$1@newsgroups.borland.com...
> Is it possible to get the length of a received datapacked with INDY
> TidTCPServer ?

You can find out how much data the TCPServer has received since you last 
checked. For your app, something like this might work:

// Untested

void __fastcall TForm1::TcpServerExecute(TIdPeerThread *AThread)
{
        int StackRead;
        unsigned int DataSize;

        // Read data off the TCP connection.
        if(AThread->Connection->InputBuffer->Size == 0)
        {
                try
                {
                        StackRead = 
AThread->Connection->ReadFromStack(true, 1000, false);
                }
                catch( const Exception &E )
                {
                        StackRead = -1;
                }
                catch(...)
                {
                        StackRead = -1;
                }
        }
        else
        {
                StackRead = -1;
        }

        // Check that we have received data and that we are connected..
        if(StackRead > 0 && AThread->Connection)
        {
                DataSize = AThread->Connection->InputBuffer->Size;
                if(DataSize > 0)
                {
                        // I would suggest getting the boost library and 
not using raw pointers
                        // But this should work for now.
                        char response[20];

                        char *Data = new char[DataSize];

                        try
                        {
                            AThread->Connection->ReadBuffer(Data.get(), 
DataSize);

                            // Now Data contains the data received.
                            // And DataSize contains how much data was 
received.

                            // Process it here.

                            // Send your response.
                            AThread->Connection->WriteBuffer( response, 
strlen( response ), true );
                        }
                        __finally
                        {
                            delete[] Data;
                        }
                }
        }
}

However, as Mr Lebeau did point out, you probably will still have to 
disable Nagle.

Jonathan 

"Billy Holliday" <NoSpam@Hohoho.com> wrote in message
news:43312e17$1@newsgroups.borland.com...

> I can use the  AThread->Connection->ReadChar(); function in
> IdTCPServer1Execute to get the data..

You did not explain what kind of data you are receiving in the first place.

> But i have a binary datapacked, contaning 0x00 in the data.

So?  ReadChar() does not care about 0x00.

> With ReadChar() i can't known, how much data i received.

ReadChar() always reads 1 byte at a time, regardless of the value of the
byte.

> Is the a function or property to get the size???

That depends  on what kind of data you are actually receiving.  You could
use AThread->Connection->ReadFromStack() and then check the
AThread->Connection->InputBuffer->Size to find out how much was actually
read.  This approach reads everything that is currently available on the
socket, without regard to the contents of the data.  But that is not very
efficient, nor is it reliable since TCP frequently breaks up data into
smaller blocks, or combines multiple blocks together, during transmission.
ReadFromStack() is directly effected by that.

Most protocols have a defined layout to the data that is being sent.  Your
reading code should more closely resemble the actual data layout that you
are expecting.  For instance, if you are expecting a string, then have Indy
read a string.  Indy will wait until the full string is received, even if it
is broken up into multiple smaller blocks or it is combined with other
blocks. On the other hand, some protocols have a fixed-length data record,
so you could use ReadBuffer() instead.  On another hand, some protocol send
data lengths embedded inside the data.  You could read the lengths and then
use ReadBuffer() or ReadStream() to receive the rest of the data for a
particular record.

Again, it all depends on what the data actually looks like in the first
place.  Please provide more details.


Gambit