|Did you know ...||Search Documentation:|
While the implementation is mostly transparent, there are some important and subtle differences that must be taken into consideration:
udp_subnetscope is not reentrant. If a listener performs a broadcast_request/1 with UDP scope recursively, then disaster looms certain. This caveat does not apply to a UDP scoped broadcast/1, which can safely be performed from a listener context.
ip(A,B,C,D)or an atom or string of the format
A.B.C.D. Options processed:
For compatibility reasons Options may be the subnet mask.
|Address||has canonical form |
%prolog\n, followed by the Prolog term in quoted notation while ignoring operators. This hook may use alternative serialization such as fast_term_serialized/2, use
library(ssl)to realise encrypted messages, etc.
|Scope||is the scope for which the message is broadcasted. This can be used to use different serialization for different scopes.|
|Term||encapsulates the term broadcasted by
the application as follows:
udp(invalid_message)to stop processing the message.
This hook is intended to initiate a new node joining the network of
peers. We could in theory also omit the in-scope test and use a normal
broadcast to join. Using a different channal however provides a basic
level of security. A possibe implementation is below. The first fragment
is a hook added to the server, the second is a predicate added to a
client and the last initiates the request in the client. The excanged
join(X)) can be used to exchange a welcome handshake.
:- multifile udp_broadcast:udp_unicast_join_hook/3. udp_broadcast:udp_unicast_join_hook(Scope, From, join(welcome)) :- udp_peer_add(Scope, From),
join_request(Scope, Address, Reply) :- udp_peer_add(Scope, Address), broadcast_request(udp(Scope, join(X))).
?- join_request(myscope, "18.104.22.168":10001, Reply). Reply = welcome.