Syntax:
on {socket} {block}
on notify {client} {block}
on watchdog in {client} {block}
on tell {client}/{service} {block}
on ask {client}/{service} {block}
Keyword handler:
net.eclecity.linguist.network.keyword.NetworkKOn.class
Runtime handler(s):
net.eclecity.linguist.network.handler.NetworkHOn.class net.eclecity.linguist.handler.LHStop.class
Function:
The first form allows you to specify a handler to take control when a byte is received by a socket.
The data is retrieved by using the name of the socket as a numeric value.
The remaining forms all deal with peer-to-peer networking. There are four event types,
as follows:
When a new client or service is added, a multipoint message
is broadcast to all local computers to inform them about the change to the system. For every client, if one or
more services have the same type string (see create) the client will be notified and
wil have a list of all relevant services. This may happen several times during system start up so it's important
to realize that the same notification may already have occurred (unless the notify once
flag is set when the client is created).
In a peer-to-peer networking system, services and clients often need to know that the clients and services they
are talking to are still there, even if no messages have been exchanged. The most likely cause of a service or
client disappearing is the program running it being closed, maybe as a result of a system crash. The start
watchdog command will cause the networking system to send out regular watchdog messages telling the rest of
the network the machine is still running. Any client can monitor this message using on watchdog
in {client} and issue a suitable warning if the watchdog messages stop arriving. The normal use for this
is to ensure a central server or admin machine is still running. Only one computer should send watchdog messages
as the recipients don't know where they came from. If you need each machine to report its presence you should set
up a client to monitor watchdog messages and send back confirmations.
When a message is sent from a service to a client or vice versa it pops up in one of two places. If it was sent
as a send message it arrives as an on tell and doesn't require
a reply. If it was sent using the string value ask {message} it will
appear as an on ask and need to be answered using reply.
In both cases the message itself is available inside the on block as the text of the message. You can also find out who sent you
the message, using the name/address of {message} source.
Each of these returns a string value.
Examples:
on MySocket put MySocket into ReceivedByte
on notify AdminClient
begin
set the destination of AdminMessage to service 0 of AdminClient
...
end
on watchdog in AdminClient gosub to ReportMyPresence
on tell MyClient
begin
put the text of the message into ReceivedClientMessage
go to DecodeClientMessage
end
on ask MyClient
begin
if the text of the message is "Happy?"
begin
if Happy reply "yes" else reply "no"
end
end