🚀 go-pugleaf

"Arnoud" <vult-r@endless-online.com> wrote in message
news:4519327b@newsgroups.borland.com...

> OnRead() seems to trigger only *once*, and then expect our
> applications to do at least one Read operation to trigger again.

That is how non-blocking sockets are designed to work.  The socket only
sends one OnRead event to let you know that data is available, and then your
application has to read what is available before a new OnRead event can be
triggered again.  This is explained in the socket API documentation:

    (begin quote)

    The Windows Sockets DLL will not continually flood an application with
messages for a particular network event. Having successfully posted
notification of a particular event to an application window, no further
message(s) for that network event will be posted to the application window
until the application makes the function call which implicitly re-enables
notification of that network event.

    Event            Re-enabling function
    FD_READ    recv, recvfrom, WSARecv, or WSARecvFrom
    ...

    Any call to the re-enabling routine, even one which fails, results in
re-enabling of message posting for the relevant event.

    For FD_READ, FD_OOB, and FD_ACCEPT events, message posting is
"level-triggered." This means that if the re-enabling routine is called and
the relevant condition is still met after the call, a WSAAsyncSelect message
is posted to the application. This allows an application to be event-driven
and not be concerned with the amount of data that arrives at any one time.
Consider the following sequence:

    1. Network transport stack receives 100 bytes of data on socket s and
causes Windows Sockets 2 to post an FD_READ message.
    2. The application issues recv(s, buffptr, 50, 0) to read 50 bytes.
    3. Another FD_READ message is posted since there is still data to be
read.

    With these semantics, an application need not read all available data in
response to an FD_READ message - a single recv in response to each FD_READ
message is appropriate. If an application issues multiple recv calls in
response to a single FD_READ, it can receive multiple FD_READ messages. Such
an application may need to disable FD_READ messages before starting the recv
calls by calling WSAAsyncSelect with the FD_READ event not set.

    (end quote)

You DO NOT, however, need to do a "garbage" read to get the OnRead event to
trigger in the first place.  If you connect to a server and do not do any
reads at all, you will still get an OnRead event when the server sends data.
I have been using TClientSocket for years and never had any problems with
that.


Gambit