🚀 go-pugleaf

"Paul Machiaverna" <paul.machiaverna@i-stat.com> wrote in message
news:41a4e2b4$1@newsgroups.borland.com...

> It has been my understanding that OnExecute (IdTCPServer1Execute)
> is simply a "start" event much like that of a TThread->Execute, where
> you stay in the method for as long as it takes to get the task completed
> and then let that method return (thread execution ends).

That is not correct.  It is true that TIdTCPServer.OnExecute is where your
socket reading/writing should occur.  However, it is common practice in
threaded socket programming to loop the threaded code, which is why the
OnExecute event is itself looped internally instead of requiring the
programmer to code his own loop inside the event handler.  The
TIdTCPServer.OnExecute code should performing the operations for only a
single iteration of TIdTCServer's looping.

> I was calling Readable() to check if there was something to read
> and then call a read data method.

You should call just the reading method by itself and not Readable() at all.
The reading method will wait for data to actually arrive before it returns.

> Of course, readable will return false when the client disconnects

Actually, it will return True.  A socket becomes readable when the other
party disconnects.  The reading code then immediately returns 0 bytes
afterwards.  That is how blocking sockets indicate disconnects.  Indy
already handles that condition, but you are not seeing it happen because you
are not using Indy correctly to begin with.  See below.

> if ( AThread->Connection->Socket->Binding->Readable( 1 ) )
> {
>   // Read it.
>   int liCount =
>       AThread->Connection->Socket->Binding->Recv(
>           lpbyBuffer, 1000, 0 );
> }

Why are you calling Recv() directly?  You should be using TIdTCPConnection's
ReadBuffer() method instead.  You are completely bypassing everything that
Indy implements for you.  If you are going to use that kind of code, then
you may as well just use the WinSock API directly and not use Indy at all.
You are not benefitting from Indy's extensive socket implementations at all.

> If Recv() isn't called, the client disconnect isn't detected (no exception
thrown).

Recv() doesn't throw any exceptions to begin with.  It is a direct wrapper
for the WinSock recv() function with no error checking performed.  That is
what the rest of the Indy library is for, but you are not utilizing that
support at all.

> What I need is another way to read binary data that will return
> the number of bytes read.

Call TIdTCPConnection's ReadFromStack() method and then check the Size of
the InputBuffer property.

> Unfortunately, I have no way of knowing in advance how much the client
> is going to send other than knowing that it won't be more than 18K bytes.

Why not?  What kind of data are you receiving to begin with?  How are you
going to know where one packet ends and the next packet begins?  Or are you
only receiving a single packet of data and then the client disconnects?  If
that is the case, then you could use TIdTCPConnection's ReadStream() method.
It has an AReadUntilDisconnect parameter.


Gambit