Comparison of resp_arrives and msg_succeeds, Idempotent versus non-idempotent requests – Echelon Neuron C User Manual
Page 153

Neuron C Programmer’s Guide
141
msg_send(); // send the message
// wait for completion
while (!msg_succeeds(motor)) {
post_events();
if (msg_fails(motor))
node_reset();
else if (resp_arrives(motor)) {
x = x + resp_in.data[0];
resp_free(); // optional
}
}
}
Comparison of resp_arrives and msg_succeeds
You can use both resp_arrives and the completion events (msg_succeeds,
msg_fails, and msg_completes) for the same request transaction because these
events give you different information. The following example illustrates this
difference.
Suppose you send one request to six devices using multicast (group) addressing.
Three of the responses are received and three are not received. In this case, the
resp_arrives event is TRUE three times, once for each time a response arrives.
The msg_succeeds event never becomes TRUE, because some of the responses did
not arrive. The msg_fails event becomes TRUE when the allotted time for all
responses to arrive is exceeded. In other words, for msg_succeeds to be TRUE,
all
of the responses must be received.
Response arrival events always occur
before
the message completion events
(msg_completes, msg_fails, or msg_succeeds).
Idempotent Versus Non-Idempotent Requests
An
idempotent
transaction is one that can be safely repeated. For example, the
command “turn on the light” can be sent repeatedly without changing the end
effect (the light goes on).
A
non-idempotent
transaction cannot be safely repeated without changing the
meaning. The command “turn up the volume by 10%” is an example of a non-
idempotent message. Responding to it ten times is
not
the same thing as
responding to it once.
LonTalk messages do not include an “idempotent” attribute. Instead, the
receiving device infers the attribute through the lack or existence of application
data in the response to the request.
If a response does not contain application data, the Neuron firmware assumes its
request is non-idempotent and cannot be safely repeated to the application. In
this case the firmware sends the original response to any repeated requests, and
does not forward the repeated request to the application. This firmware feature
simplifies application processing for responses without data because the
application does not have to test for duplicate messages.
If a response does contain application data, the Neuron firmware assumes its
request is idempotent and can be safely repeated. In this case the application