polling only on socket, or can there be a trigger?

[Dr. Hawkins]

On Sat, May 9, 2015 at 10:54 AM, Mark Waddingham <mark at livecode.com> wrote:

> The idea here is that each time you get a 'newClient' message you have a
> newly named socket 'pClientSocket' which is the other end of the connection
> the client initiated. You can have as many of these client-connected
> sockets as you like, and independently read / write to them with messages
> sent when the action you request completes.


Thank you.  I appreciate this, and here is the catch, or what I'm not
understanding:

In your example, the read in newClient only appears to happen once.  And
part of what I'm trying to clear up is whether execution stops at that
line, or continues--or does this even matter, as an event triggered this,
and several could be simultaneous?  My current understanding is that it
waits if there is active writing, and when that writing is done, it does
clientDataReceived--and then is done.

Or, is it starting a ping-pong between clientDataReceived and
clientDataSent, with each calling the other when done?

In my case, newClient causes the opening of a database session
(revOpenDatabase), and a confirmation goes back to the client.  I have all
that working at this point (i think).

What I'm not getting is how to handle the client again using that freshly
created new socket (call it "sktRefresh") again without using polling.  For
example, client program opens the database, which contains various customer
files.  A few seconds later, the client wants to update the jones table, so
it sends the server a message with the relevant database commands, by
writing to sktRefresh.

As near as I can tell, when this happens* after* the initial opening, that
message is going to sit around until something decides to read it, rather
than triggering a new message.


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462