While the implementation is mostly transparent, there are some
important and subtle differences that must be taken into consideration:
- TIPC broadcast now requires an initialization step in order to
launch the broadcast listener daemon. See tipc_initialize/0.
- Prolog's broadcast_request/1 is
nondet. It sends the request, then evaluates the replies synchronously,
backtracking as needed until a satisfactory reply is received. The
remaining potential replies are not evaluated. This is not so when TIPC
is involved.
- A TIPC broadcast/1 is completely
asynchronous.
- A TIPC broadcast_request/1 is
partially synchronous. A
broadcast_request/1 is sent, then the
sender balks for a period of time (default: 250 ms) while the replies
are collected. Any reply that is received after this period is silently
discarded. An optional second argument is provided so that a sender may
specify more (or less) time for replies.
- Replies are no longer collected using findall/3.
Replies are presented to the user as a choice point on arrival, until
the broadcast request timer finally expires. This change allows traffic
to propagate through the system faster and provides the requestor with
the opportunity to terminate a broadcast request early if desired, by
simply cutting choice points.
- Please beware that broadcast request transactions will now remain
active and resources consumed until broadcast_request finally fails on
backtracking, an uncaught exception occurs, or until choice points are
cut. Failure to properly manage this will likely result in chronic
exhaustion of TIPC sockets.
- If a listener is connected to a generator that always succeeds (e.g.
a random number generator), then the broadcast request will never
terminate and trouble is bound to ensue.
- broadcast_request/1 with TIPC scope is not
reentrant (at least, not now anyway). If a listener performs a broadcast_request/1
with TIPC scope recursively, then disaster looms certain. This caveat
does not apply to a TIPC scoped broadcast/1,
which can safely be performed from a listener context.
- TIPC's capacity is not infinite. While TIPC can tolerate substantial
bursts of activity, it is designed for short bursts of small messages.
It can tolerate several thousand replies in response to a broadcast_request/1
without trouble, but it will begin to encounter congestion beyond that.
And in congested conditions, things will start to become unreliable as
TIPC begins prioritizing and/or discarding traffic.
- A TIPC broadcast_request/1 term that
is grounded is considered to be a broadcast only. No replies are
collected unless the there is at least one unbound variable to unify.
- A TIPC broadcast/1 always succeeds,
even if there are no listeners.
- A TIPC broadcast_request/1 that
receives no replies will fail.
- Replies may be coming from many different places in the network (or
none at all). No ordering of replies is implied.
- Prolog terms are sent to others after first converting them to atoms
using term_to_atom/2. Passing real numbers
this way may result in a substantial truncation of precision. See prolog
flag option,’float_format’, of current_prolog_flag/2.
- [nondet]tipc_host_to_address(?Service,
?Address)
- locates a TIPC service by name. Service is an atom or
grounded term representing the common name of the service. Address
is a TIPC address structure. A server may advertise its services by name
by including the fact, tipc:
host_to_address(+Service, +Address),
somewhere in its source. This predicate can also be used to perform
reverse searches. That is it will also resolve an Address to
a
Service name. The search is zone-wide. Locating a service
however, does not imply that the service is actually reachable from any
particular node within the zone.
- [semidet]tipc_initialize
- See tipc:tipc_initialize/0
