elein wrote:

>I am thinking too hard about this problem, I'm sure.
>
>node 1 has two children nodes 2 & 4
>node 2 has one child, node 3
>
>paths are set up between each possible pair.
>
>What should the listen look like?
>
>store listen (origin=1, receiver=2, provider=1);
>store listen (origin=2, receiver=1, provider=2);
>store listen (origin=1, receiver=4, provider=1);
>store listen (origin=4, receiver=1, provider=4);
>store listen (origin=2, receiver=3, provider=2);
>store listen (origin=3, receiver=2, provider=3);
>
>Should there also be:
>
>store listen (origin=1, receiver=3, provider=2);
>store listen (origin=3, receiver=1, provider=2);
>
>Thanks for your help.  I'm concerned I'm missing
>something basic.
>
>  
>
Each node needs to get events originating from each other node, so there 
need to be 4x3 = 12  "store listen" entries.

Rec     Org  Provider
1        2    2
1        3    2
1        4    4
2        1    1
2        3    3
2        4    1
3        1    2
3        2    2
3        4    2
4        1    1
4        2    1
4        3    1

Understanding this...

For each receiver (1..4)...
   We look at the 3 nodes it needs to get events from...
       And for those, the provider is the nearest member in the tree

The first line becomes the slonik command:
  store listen (receiver = 1, origin = 2, provider = 2):

The second line gives slonik command:
  store listen (receiver = 1, origin = 3, provider = 2);

The code in RebuildListenEntries() takes a slightly different 
perspective; the above approach is really easy to draw out based on a 
network diagram:

          1
         / \
        2   4
        |
        3

What you basically do for each "provider" is to look at what node is the 
nearest one that talks to the desired "origin."

So, consider node 2, as the receiver; it needs to get events from node 4.

Where should it get them from?  Well, the nearest node to #2 on the path 
leading to #4 is node #1.

Thus...
  store listen (receiver = 2, origin = 4, provider = 1);

The Perl script provides somewhat different (and arguably better, by a 
different metric) answers; the above has been sufficient for our 
"whiteboarding efforts" to get some moderately complex configurations 
working.

Hope that helps.