RE: Individual Members of PeerGroup
"Poole, Paul P1" <[email protected]> Wed, 21 Sep 2005 16:02:58 -0400
| Newsgroups | gmane.comp.java.jxta.user |
|---|---|
| Message-ID | <[email protected]> |
The issue has been submitted. Thanks for your help! -Paul -----Original Message----- From: Mohamed Abdelaziz [mailto:[email protected]] Sent: Wednesday, September 21, 2005 3:35 PM To: [email protected] Subject: Re: [JXTA user] 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/i > mp > > l/cm/LRUCache.java?rev=1.2&view=auto&content-type=text/vnd.viewcvs-mar > ku > >> p). >> >> >> 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]