Echelon IzoT NodeBuilder - Manual (Page 155)

Service Type Displays the service type used by the network variable to send
updates as specified in the functional profile (Unspecified,
Acknowledged, Repeated, or Unacknowledged). This property is
only available for output network variables.
You can change the service type for mandatory and optional output
network variables if the functional profile has not specified one, and
you can change the service type for implementation-specific output
network variables. The service types vary in reliability and resources
consumed:
• Unspecified. The network management tool or integrator will
determine which service type is used.
• Acknowledged. The sending device expects to receive
confirmation from the receiving device or devices that a network
variable update was delivered. The sending application is
notified when an update fails, but it is up to the developer of the
sending device to handle the notification in the device
application. While acknowledged service is very reliable, it can
create excessive message traffic, especially for large fan-out or
polled fan-in connections. When acknowledged messaging is
used, every receiving device has to return an acknowledgment.
Acknowledged messaging can be used with up to 63 receiving
devices, but an acknowledged message to 63 devices generates at
least 63 acknowledgements—more if any retries are required due
to lost acknowledgements.
Acknowledged service is the best choice for most network
variable connections due to its superior reliability and
performance.
• Unacknowledged. The sending device sends out the network
variable update only once and does not expect any confirmation
from the receiving device. This message service type consumes
the least amount of resources, but is the least reliable.
Unacknowledged service is often used with data that is frequently
repeated as part of the application’s algorithm, where the
occasional loss of an update might not be critical.
• Repeated. The sending device sends out a series of network
variable updates, but does not expect any confirmation from the
receiving device. Repeated service with three repeats has a
99.999% success rate in delivering messages. Repeated service
provides the same probability of message delivery as
acknowledged messaging with the same number of retries, with
significantly lower network overhead for large multicast fan-out
connections. For example, a repeated message with three retries
to 64 devices generates four packets on the network, whereas an
acknowledged message requires at least 64 packets. However,
the repeated message in this case does not allow for the backlog
estimation that an acknowledged message does.
IzoT NodeBuilder FX User's Guide 141