2.2.1 Caveats

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