Re: Individual Members of PeerGroup

Using a the same propagate pipe (a new op instance, same pipe id and a 
set of peers), as a unicast pipe is a lot more efficient in the 
following situations :

- High churn rate
- The set of peers > PeerView/2
- Infrequently invoked

 A Unicast pipe carries a higher cost due to pipe/route resolution, 
whereas with a propagate pipe  the network is leveraged for message 
delivery.

-- 
http://blogs.sun.com/roller/page/hamada
http://weblogs.java.net/blog/hamada



Vitaly Vainer wrote:

> Hi Paul,
> I would suggest to maintain special recovery input pipe with well 
> known id on each peer, so you'll know how to address them by unicast 
> output pipe.
> In my application the network is by its nature unstable too, so I'm 
> using well known ids for basic services and your recovery service 
> looks very appropriate for this approach.
>  
> Vitaly.
>
>  
> On 9/9/05, *Poole, Paul P1* <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     Mohamed,
>
>     Thanks for taking the time to respond... Here is what I am trying to
>     accomplish:
>
>     I have designed a system where each message generated by a peer for a
>     group is numbered.  This numbering is used by the other peers to
>     determine if they have received all of the messages from a given peer.
>     If a message received is larger than expected, then it is threaded
>     into
>     recovery mode (after a short sleep cycle since some messages are
>     received out of order).  In recovery mode, I want a peer to be able to
>     request from other peers the messages that were missed.  However, I do
>     not want the query to be propagated to the entire group, just a
>     couple
>     of them (at most 3).  I am trying to develop this for a very unstable
>     network - peers are coming and going at a high rate.  Thus, I want
>     to be
>     able to obtain the "latest" list from the rendezvous and send my
>     recovery requests to a few members of the group that are currently
>     connected (preferentially connected with least latency, but that
>     will be
>     tackled later).  I thought that perhaps grabbing the current list from
>     rdv and sending a recovery message to a few of them would work,
>     but I am
>     unable to get the propagate method to work (I have created a separate
>     thread for that problem).
>
>     I would love to hear alternative suggestions.
>
>     My current problem with performing a unicast loop is that I do not
>     understand how to obtain a pipe for each peer that I chose from
>     the list
>     of connected peers.  If I can get a unicast pipe from each of those
>     peers, then I could set this up to simply unicast the recovery
>     message.
>
>     Thanks for your help!!!
>
>     -----Original Message-----
>     From: Mohamed Abdelaziz [mailto:[email protected]
>     <mailto:[email protected]>]
>     Sent: Thursday, September 08, 2005 8:12 PM
>     To: [email protected] <mailto:[email protected]>
>     Subject: Re: [JXTA user] Individual Members of PeerGroup
>
>
>     Mohamed Abdelaziz wrote:
>
>     > Paul,
>     >
>     > Creating an OutputPipe object with the desired set of peers should
>     > provide the functionality you seek. Using rendezvous propagation may
>     > work given the correct service name and param, however, we advise
>     > against it, mainly due to the potential flood everywhere, and as a
>     > result it has become more restrictive in the upcoming release 2.3.5.
>     >
>     > Is this a static set of peers, or you looking for suggestions on
>     how
>     > to dynamically create one?
>     >
>     > if it is the latter, perhaps a ping message over the propagate pipe
>     > results into a unicast response over the same propagate pipe.
>
>
>     Another suggestion is to keep track of peers over the course of
>     communication and dynamically augment the random set of peers.
>

-- 
http://blogs.sun.com/roller/page/hamada
http://weblogs.java.net/blog/hamada