onexpression moves execution to the specified peer:
foois instructed to be executed on a peer with id
onsupports variables of type
INIT_PEER_ID. It points to the peer that initiated this request.
do_foois executed on "peer foo", always.
bar(1)is executed on the same node where
bazwas running. If
bazis the first called function, then it's
bar(2)is executed on
"peer baz", despite the fact that foo does topologic transition.
bar(2)is in the scope of
on "peer baz", so it will be executed there
bar(3)is executed where
bar(1)was: in the root scope of
baz, wherever it was called from
relaypattern: there should be a well-connected peer that relays requests from a peer to the network and vice versa.
ons nested or delegated in functions work just as you expect:
on ... via, significant indentation changes the place where the code will be executed, and paths that are taken when execution flow "bubbles up" (see the last call of
foo). It's more efficient to keep the flow as flat as it could. Consider the following change of indentation in the previous script, and how it affects execution:
onscope is ended, it does not affect any further topology moves. Until you stop indentation,
onaffects the topology and may add additional topology moves, which means more roundtrips and unnecessary latency.