[Tipc-discussion] Re: how about the current tipc work

[Jon M. <jon...@er...>]

Hi Guo,
I am finally back from my Christmas/New year brak, and can read
my Ericsson mail again.
One reason for having this neighbour protocol is, just as you said,
to be able to sub-divide bigg clusters into smaller ones on the same
LAN.
The calulations I do about link supervision background load in my draft
explains why, but even memory usage considerations may require such
split of clusters.
Another reason is that we  may want to have several clusters or zones to

communicate even when they are not on the same LAN,  and maybe even 
geographically separated. This is actually something we do in our own
Ericsson products.

Instead of having to set up and maintain hundreds or even thousands of
such 
links manually when the clusters are changing, it is desirable with a
protocol 
that can do this automatically and with an optimal result. This is the
purpose
with the protocol.

Actually, it is implemented, and *was* working, in Manager.c in the
ericsson_stable
version. But the functionality I describe in the draft is more advanced,
with "all-to-N"
links instead of "all-to-2" links as in the older version, and
supporting multicast setup,
intead of relying on a manually configured pilot link.

/jon

Guo, Min wrote:


PS: Is there anyone there who would be interested to work

with the inter-cluster neighbour detection protocol ?

The code is found in cfg.c, but it probably does not work

any more. Anyway I updated the protocol a little in my

draft, as you may see, so the code must follow.

This is an interesting task, and a cool algorithm to demonstrate

to the world.

    



Why use such complex neighbor detection protocol? 

In my mind, I think it can be used to divide large cluster into small
cluster in the

 same LAN, and it can also do better load balance? Is that right?



Thanks

Guo Min