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