🚀 go-pugleaf

My advice to you is not to use ctBlocking mode, whenever you can avoid doing
so. I use non-blocking, and this works well. Some words I sent out recently
about "Post"ing with non-blocking sockets :-


Question : The OnSuccess or OnFailure callbacks are called BUT always before
Post() returns. So I'm puzzled ? What is then the point of having these
callbacks ?



This may be because the actual sending of the raw http data is handled by
Windows Sockets. The Post message is sent to Winsock and this gives a yeah or
nay as to whether the pipe is able to handle the request (success or failure
is then triggered) even though the data has not been sent yet. The same
happens with non-blocking sockets (TServerSocket), in that a send request will
return immediately, having queued up the data. TClientSocket uses an OnRead
event to receive data in non-blocking mode. When this is triggered, the system
has already received x bytes, and Winsock is triggering the event, either
because its receive buffer is full, or because the entire datagram has been
received. The function ReceiveLength tells you how many bytes Winsock has got
for your app. The function ReceiveBuf returns the actual number of bytes
transferred from Winsocks to your app (nearly always the same as
ReceiveLength). To get the data, I use a construct like this in the OnRead
event :-

int ii=Socket->ReceiveBuf(rcvbfr,Socket->ReceiveLength());

This is how asynchronous comms has to work, in the uncertain world of
connectivity.

-- 
Mark Jacobs
DK Computing
http://www.dkcomputing.co.uk
markj atty critical dotty co dotty uk

"Vladimir Stefanovic" <spam@not.needed> wrote in message
news:4152f591@newsgroups.borland.com...
| Maybe it is in some connection with blocking modes at
| client (which is ctBlocking at me). Unfortunately I'm not
| currently at PC with BCB to test again.