PeerGroup & Peer Advertisements

A group is actualy two things:

Currently we put all this information in the same document. It may be simple - code wise, (in fact, I just did not think about it, then :-), but it is quite wastefull because both types of information are used in different contexts and for different purposes. You'd need the group definition in order to instanciate it on some peer, while you'd need particular instanciations in order to communicate with peers running that group. As a result the former needs to be published and cached in the surrounding group or wherever, while the later only needs to be published and cached within the group itself.

Also the definition can probably use a lot more eagerness in publishing and propagating than the instanciation. On top of that, they do not have the same optimal lifetime: the definition potentialy makes sense for a long time even if no peer currently instanciates it. On the other end, the description of a given instantiation is only usefull while the corresponding peer is up and can always be reobtained. So, purging it from a cache never does irreparable damage.

All these are very good reasons to separate this two sets of information in two independant types of advertisements. And that's one of the top items on my todo list, right after writting the present brain-dump.

My reason for bringing this up is that I have seen that someone was taking charge of the thorny item of expiring advertisments. The separation above encourages two different expiration policies, which, in my opinion makes the problem easier since that avoids the need for a policy that works for both types of information.



Jean-Christophe Hugly

Last modified: Thu Jun 14 14:23:36 PDT 2001