Many thanks, Mark ! Very useful. Pierre
> Le 9 mai 2015 à 21:03, Mark Waddingham <[email protected]> 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 ~ [email protected] ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > _______________________________________________ > use-livecode mailing list > [email protected] > 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 _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
