Fri May 21 09:38:08 CEST 2004
From: "Vlad Dumitrescu" <vlad_dumitrescu@REDACTED>
> I have a couple of related questions, I just hope they'r not the kind that
> would be answered with a "RTFM!" :-)
Actually, RTFM ;-]
> * What differentiates a full node from a hidden node?
Hidden node is visible only at the connected peer (i.e. if you run BIF
nodes(), you're not going to be able to see it, but if you run undocumented
net_kernel:nodes_info(), you will). This implies that you will not be able
to connect to other nodes that are known to the connected node implicitly,
even if you have a same cookie. As TFM says, similar to C-Node.
> * the before mentioned erlang:set_cookie(Node, Cookie) is documented as
I am not using erlang:set_cookie/2 but auth:set_cookie( Node, Cookie),
however, I suspect that the effect is the same.
This command affects the node at which it has been issued, and expects
remote Node to use Cookie when connecting to *this* node.
This is useful in situations where you have a node A for which you'd like to
allow access from a particular remote node B without disclosing the node's A
For example, consider nodeA with cookie cookieA and nodeB with cookie
nodeA may issue auth:set_cookie( nodeB, cookieB ), in which case nodeB will
be able to connect to nodeA immediately.
However, in order to avoid disclosing any cookie, both parties may agree on
the cookie and:
(nodeA@REDACTED) auth:set_cookie( nodeB@REDACTED, cookieX ).
(nodeB@REDACTED) auth:node_cookie( nodeA@REDACTED, cookieX ).
This way nodeA instructs the run-time to expect connection from nodeB using
cookieX, and conversely, nodeB is instructing run-time to use cookieX when
connecting to nodeA. As a matter of fact, auth:node_cookie/2 will have a
side-effect of establishing the connection with node in question.
More information about the erlang-questions