🚀 go-pugleaf

"Vladimir Stefanovic" <antivari@po.sbb.co.yu> wrote in message
news:433cd755@newsgroups.borland.com...

> I want to use Indy to do the same thing that I
> knew with TClientSocket/TServerSocket:

Indy can do everything TClient/ServerSocket does, and more.

> 1) TClientSocket (ctNonBlocking) sends buffer of data
> (possibly lots of data) to TServerSocket( stBlocking/
> OnGetThread )
>
> 2) TServerSocket receives data in a thread, in nagotiated
> protocol, for example: "buffer_length buffer"
>
> 3) TServerSocket sends back the confirmation to client
> that the operation was successful or not.

Ok so far.

> Which Indy components are the most suitable for that
> (I suppose TIdTCPClient/TIdTCPServer)?

Yes.

> Am I supposed to send data in peaces (buffer portins), then
> look how much data was actually sent, and continue from
> that place like I did with TClientSocket/TServerSocket?

No.  When you write data with Indy, you can write the entire data at one
time, and Indy will internally send it in portions as needed.  As far as
your own code is concerned, whichever writing method you call will not
return control to your code until the specified data is passed to the socket
in full.

> The same was with server.

Likewise, when you read data with Indy, you tell Indy how much to read, and
it waits until all of the data is received in full before then returning
control to your code.

> I remember that even in TClientSocket I had SendText()
> which was not reliabe because noone can guarantee that
> *all*  the buffer will be sent at the same time.

That is true, although SendText() does return how many bytes were sent, so
that you can call SendText() with the remaining string data if needed.

> Is the same here?

No.  When you call Indy's Write(String) method, for instance, Write() does
not return until the entire string is passed to the socket in full.


Gambit