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

[Pierre Sahores]

Many thanks, Mark ! Very useful.

Pierre

> Le 9 mai 2015 à 21:03, Mark Waddingham <mark at livecode.com> a écrit :
> 
>> 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
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.com