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

Page 153

Advertising
background image

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

Advertising