My sequence is that the client connects to the server, and then sends
it
periodic messages. On the initial connection, the server creates a
database connection and leaves it open (opening a database takes time
measured in hundreds of milliseconds). The approach of opening and
closing a database on each transaction simply isn't a realistic option
for
me.
All the socket commands can be used in a non-blocking, message-based
way.
When you 'accept connections' you create a listening socket whose
purpose is to wait for connections and then supply you with a 'normal'
socket to talk to the client which connected. The listening socket will
continue to persist after this (until you close it) continuing to wait
for new connections from clients.
So an outline of an example (which assumes on receiving data from the
client you need to send it something):
on startServer
accept connections ... with message "newClient"
end startServer
on newClient pClientSocket
read from pClientSocket ... with message "clientDataReceived"
end newClient
on clientDataReceived pClientSocket, pData
... process pData ...
write ... to socket pClientSocket with pData with message
"clientDataSent"
end clientDataReceived
on clientDataSent pClientSocket
read from pClientSocket ... with message "clientDataReceived"
end clientDataSent
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.
If you use the blocking form of the socket commands then (as they don't
dispatch messages whilst blocking) you can basically only talk to one
client at a time. The blocking form may well be fine for a client, if it
is connecting to a server, interacting with some sort of linear protocol
and then closing the connection; but for a server that wishes to handle
multiple clients simultaneously it is a much better idea to use the
messaging form.
Hope this helps,
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
