Re: Individual Members of PeerGroup

I must have missed something else, thanks for the quick feedback.    The 
final patch will address the problem correctly.

The root cause lays in two areas :

1- Special handling of propagate pipe messages on a rendezvous peer
2- Lack of specification of destination peers in the wire header.  
Basically the WirePipe relied on the rendezvous service for propagation 
to a specified  set of peers, however the specified set is not preserved 
throughout the network.

I will also take the opportunity to loosen the tight checking of 
unneeded WireHeader elements allowing us to reduce the overhead of a 
propagate pipe, at  a later point in time.   For those interested these 
include :

- Message ID (a duplicated in the propagate header)
- Visited Peer is an overkill and unneeded to duplicate message as 
Propagate pipe subscriptions (SRDI) and  message id's avoids unintended 
delivery
- TTL, duplicated in the authoritative propagate header
 
Please create an issue under the platform for the forthcoming patch

Cheers,
Mohamed



Poole, Paul P1 wrote:
> Mohamed,
>
> Thanks for the quick response (and patch).  I have looked over the patch
> and tried it.  The patch, unfortunately, doesn't resolve this particular
> problem.  The patch you provided ensures that the node that initiates
> the message will receive it.  For example, if there are 2 nodes A and B.
> If A is the rdv node and B is the node trying to send a message to A
> (via the method described below), this patch will send the message to B
> (itself) as well as attempt to send it to A.  For some reason, A never
> receives the message.  
>
> Here is the problem, using the same example above (no patch)... Node A
> is the rdv and B is an edge peer.  If B sends a message to A, A will not
> receive the message.  However, if A sends a message to B, B will receive
> the message.  To expand on this, if there are 5 nodes: A, B, C, D, and
> E, where node A is the rdv node.  If B sends a message to A and C, C
> will receive the message, but A will not.
>
> I hope this is clear.  I am mucking around in the source code for Jxta
> right now.  If I solve this problem, I will post it here.  
>
> Thanks,
>
> -----Original Message-----
> From: Mohamed Abdelaziz [mailto:[email protected]] 
> Sent: Wednesday, September 21, 2005 12:11 PM
> To: [email protected]
> Subject: Re: [JXTA user] Individual Members of PeerGroup
>
>
> Yes that's bug.  Looking through the WirePipe the logic which deals with
>
> such messages (destined to a specific set of nodes) on a rendezvous ends
>
> up bypassing any local listener during hand off between the incoming, 
> and the outgoing threads.
>
> The attached patch will address the issue.  Keep in mind it may not be 
> the final patch.
>
> Mohamed
>
>
>
> Index: WirePipe.java
> ===================================================================
> RCS file: 
> /cvs/platform/binding/java/impl/src/net/jxta/impl/pipe/WirePipe.java,v
> retrieving revision 1.38
> diff -u -r1.38 WirePipe.java
> --- WirePipe.java       27 Jul 2005 16:31:49 -0000      1.38
> +++ WirePipe.java       21 Sep 2005 16:06:36 -0000
> @@ -465,10 +465,8 @@
>       */
>      void sendMessage(Message msg, Set peers) throws IOException {
>  
> -        // do local listeners if we are to be one of the destinations
> -        if(peers.isEmpty() || peers.contains(myGroup.getPeerID())) {
> -            callLocalListeners(msg, null, null);
> -        }
> +
> +        callLocalListeners(msg, null, null);
>  
>          if(peers.isEmpty()) {
>              if (myGroup.isRendezvous()) {
>
>
> Poole, Paul P1 wrote:
>   
>> Mohamed,
>>
>> Regarding: "OutputPipe op = pipeSerivce.createOutputPipe(propPipeAdv,
>> Collections.singleton(src_pid), 1);"
>>
>> I ran into one problem with this... If the src_pid belongs to the 
>> rendezvous peer, it fails.  Is this a bug?  Do you know of any good 
>> workarounds?  I am using a history list (based on an LRU cache, per 
>> your
>> suggestion) to obtain a list of peers.  Sometimes one of the peers
>> selected is a rendezvous... When this happens, a message is sent, but
>> the rdv peer never receives this message.  This is problematic for
>> message recovery in a two node scenario since the only other node to
>> request missed messages from is the rendezvous.
>>
>> Thanks for your assistance,
>>
>> Paul
>>
>> -----Original Message-----
>> From: Mohamed Abdelaziz [mailto:[email protected]]
>> Sent: Monday, September 12, 2005 3:55 PM
>> To: [email protected]
>> Subject: Re: [JXTA user] Individual Members of PeerGroup
>>
>>
>> PipeMessage should define and include source PID, IMO is it a missing
>> feature. However, in the interim. Exchange src id in the message, and
>>     
> to
>   
>> convert a string into a peerid can be easily done through :
>>
>> try {
>>                 pid =(PeerID) IDFactory.fromURI(new URI(pidStr)); } 
>> catch (Exception ex) {}
>>
>>
>> The problem with using the list of peers connected to a rendezvous, is
>> the assumption that such peers are subscribers to the communication 
>> channel, in addition, the pipe service does not expose any api's to 
>> access the list of subscribers. That said, the simplest way to do this
>>     
>
>   
>> without extending the core services is to use a dynamic list.
>>
>> I would also add the dynamic list should be an LRU cache to ensure a
>> fresh list (the JXME project has a class which fits this purpose see:
>>     
>
>   
> http://jxme.jxta.org/source/browse/jxme/proxyless/proto/src/net/jxta/imp
>   
> l/cm/LRUCache.java?rev=1.2&view=auto&content-type=text/vnd.viewcvs-marku
>   
>> p).
>>
>>
>> Mohamed
>>
>>   
>>     
>
>
>   


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