RE: Individual Members of PeerGroup

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.
>
>  
>
>>Mohamed
>>
>>    
>>
>
>
>  
>


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


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]