tipc.plSWI-Prolog's broadcast library provides a means that may be used to facilitate publish and subscribe communication regimes between anonymous members of a community of interest. The members of the community are however, necessarily limited to a single instance of Prolog. The TIPC broadcast library removes that restriction. With this library loaded, any member of a TIPC network that also has this library loaded may hear and respond to your broadcasts. Using TIPC Broadcast, it becomes a nearly trivial matter to build an instance of supercomputer that researchers within the High Performance Computer community refer to as "Beowulf Class Cluster Computers."
This module has no public predicates. When this module is initialized, it does three things:
A broadcast/1 or broadcast_request/1
that is not directed to one of the six listeners above, behaves as usual
and is confined to the instance of Prolog that originated it. But when
so directed, the broadcast will be sent to all participating systems,
including itself, by way of TIPC's multicast addressing facility. A TIPC
broadcast or broadcast request takes the typical form: broadcast(tipc_node(+Term, +Timeout)).
The principal functors tipc_node, tipc_cluster,
and
tipc_zone, specify the scope of the broadcast. The functor
tipc_node, specifies that the broadcast is to be confined
to members of a present TIPC node. Likewise, tipc_cluster
and tipc_zone, specify that the traffic should be confined
to members of a present TIPC cluster and zone, respectively. To prevent
the potential for feedback loops, the scope qualifier is stripped from
the message before transmission. The timeout is optional. It specifies
the amount to time to wait for replies to arrive in response to a
broadcast_request. The default period is 0.250 seconds. The timeout is
ignored for broadcasts.
An example of three separate processes cooperating on the same Node:
Process A: ?- listen(number(X), between(1, 5, X)). true. ?- Process B: ?- listen(number(X), between(7, 9, X)). true. ?- Process C: ?- findall(X, broadcast_request(tipc_node(number(X))), Xs). Xs = [1, 2, 3, 4, 5, 7, 8, 9]. ?-
It is also possible to carry on a private dialog with a single responder. To do this, you supply a compound of the form, Term:PortId, to a TIPC scoped broadcast/1 or broadcast_request/1, where PortId is the port-id of the intended listener. If you supply an unbound variable, PortId, to broadcast_request, it will be unified with the address of the listener that responds to Term. You may send a directed broadcast to a specific member by simply providing this address in a similarly structured compound to a TIPC scoped broadcast/1. The message is sent via unicast to that member only by way of the member's broadcast listener. It is received by the listener just as any other broadcast would be. The listener does not know the difference.
Although this capability is needed under some circumstances, it has a tendency to compromise the resilience of the broadcast model. You should not rely on it too heavily, or fault tolerance will suffer.
For example, in order to discover who responded with a particular value:
Process A:
?- listen(number(X), between(1, 3, X)).
true.
?-
Process B:
?- listen(number(X), between(7, 9, X)).
true.
?-
Process C:
?- broadcast_request(tipc_node(number(X):From)).
X = 7,
From = port_id('<1.1.1:3971170279>') ;
X = 8,
From = port_id('<1.1.1:3971170279>') ;
X = 9,
From = port_id('<1.1.1:3971170279>') ;
X = 1,
From = port_id('<1.1.1:3971170280>') ;
X = 2,
From = port_id('<1.1.1:3971170280>') ;
X = 3,
From = port_id('<1.1.1:3971170280>') ;
false.
?-
While the implementation is mostly transparent, there are some important and subtle differences that must be taken into consideration:
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.