Re: Individual Members of PeerGroup

Creating a propagate output pipe has very little cost associated with 
it.  I suggest creating a new one when needed, then discarding it.

Mohamed

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



Poole, Paul P1 wrote:

>Vitaly and Mohamed:  Thanks so much for your time with this... I know
>that my solution will be so much better for it!
>
>Mohamed:  I see the API spec for OutputPipe op =
>pipeSerivce.createOutputPipe(propPipeAdv,
>Collections.singleton(src_pid), 1);
>
>Should I use this in a loop adding the src_pids that I need one at a
>time?  Is there a lot of overhead for creating these new pipes?  If so
>(and even if not), would it be at all efficient to cache these for a
>(brief?) period of time in the event I need to reuse these for future
>recovery?
>
>Thanks,
>
>Paul
>
>-----Original Message-----
>From: Mohamed Abdelaziz [mailto:[email protected]] 
>Sent: Friday, September 09, 2005 7:09 PM
>To: [email protected]
>Subject: Re: [JXTA user] Individual Members of PeerGroup
>
>
>I'll expand a little on the propagate pipes protocol and implementation,
>
>as it will help you understand the suggestions below.   Propagate pipes 
>are implemented similarly to IGMP as follows :
>
>Propagate pipe Membership
> - Nodes issue a propagate pipe Membership in the form of an SRDI 
>message to it's rendezvous
> - Rendezvous peers maintain membership lists for their clients
>
>Resolution
> - There is no resolution of a propagate
> - Creation of an OutputPipe defines the destination propagate endpoint,
>
>and possible peer endpoints.
>
>Message routing
> - In addition to Multicast (if available), a message is always walked 
>to the nodes rendezvous
> - On a rendezvous the message is deliver to all subscribers of the 
>channel, and walked the length of the peerview, where this step is
>repeated.
> - If a set of peers is specified, then the message is delivered to only
>
>those specified.
>
>Propagate pipe resignation
> - Nodes issue a propagate pipe resignation in the form of an SRDI 
>message (expiring the entry) to it's rendezvous.
>
>That said, the simplest solution I can suggest, is for the recovery 
>thread is to create an OutputPipe with the same propagate pipe adv and 
>the intended set of peers. The set may only contain one peer (the peer 
>that just sent the message), or a set peers picked randomly from a list 
>maintained by the app through communication history.
>
>The PipeService supports this kind of functionality,  and provides the 
>API to do so. Also, as noted above, the implementation leverages 
>rendezvous propagation, walkers, SRDI, and the pipe protocol to deliver 
>messages.  Bypassing the PipeService will only result in message 
>delivery failures. The API I am referring to, goes as follows  :
>
>OutputPipe op = pipeSerivce.createOutputPipe(propPipeAdv, 
>Collections.singleton(src_pid), 1);
>
>If you find in practice that the above does not meet your goals, then 
>the other alternative is to enhance the propagate pipe protocol to 
>provide access to propagate pipe group membership, etc.
>
>
>Mohamed
>
>
>Poole, Paul P1 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]]
>>Sent: Thursday, September 08, 2005 8:12 PM
>>To: [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.
>>    
>>