polling only on socket, or can there be a trigger?
Mark Waddingham
mark at livecode.com
Sat May 9 15:03:37 EDT 2015
> Or, is it starting a ping-pong between clientDataReceived and
> clientDataSent, with each calling the other when done?
Yes - that's precisely what the code does that I outlined.
Sockets are bidirectional in nature and so you can 'simultaneously' be
reading and writing to them at the same time.
When you do a 'read' or a 'write' and specify a message no direct action
takes place at that point at all. Instead, the engine queues the read
(or write) request (they are separate queues) and marks the socket to
notify the engine when data arrives (or data is sent). As data arrives
(or is sent), the engine dispatches the appropriate messages in order to
satisfy the requests that have been made. In particular, no blocking
occurs at the point of the read/write command, instead things happen the
next time the event loop runs (typically when the current handler stack
which was initiated by a message completes; but also when a 'wait with
messages' command occurs).
The reason I wrote the outline as a 'ping-pong' of reads and writes is
because that is what most protocols entail, but you could schedule a
sequence of 'read with message' and/or a sequence of 'write with
message' and they would be serviced in order for each read queue and
write queue (the actual nature of the interleaving of the two would
depend on when data finishes sending, or is received).
> 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.
I take it by 'sktRefresh' you mean the socket identifier given to you as
the parameter to 'newClient'? This is the server-side of the connection
to the individual client, so on the server side you issue an appropriate
'read with message' for that socket which will fire when the client
sends it some data. Then, on the server you would service that request
in the callback message and perform the query returning the data using
'write with message'. Now, if the client needs to be able to send
several requests to the client simultaneously then you would probably
also want to 'read with message' so the server can catch another (whilst
data is being written back) request - but that will depend on the client
and how it is going to use the server.
> 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.
Yes - the only way to read data from a socket is to explicitly use the
'read' command. The blocking form will sit and wait until the client has
actually sent some data (which means the server cannot be doing anything
else); whilst the 'with message' form tells the engine to watch for data
to be delivered and as soon as it satisfies the specified read condition
send you a message with the data. i.e. The server can happily go off and
do other things until the client *actually* does send some data to
process.
Mark.
--
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the use-livecode
mailing list