Re: JXTA cannot discover peers behind NATs?
"Regis Ivan" <[email protected]> Wed, 20 Dec 2006 23:29:23 +0000
| Newsgroups | gmane.comp.java.jxta.user |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_40740_11546775.1166657363653 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm interested to take a look at your sample app code. A colleague of mine encountered a similar problem a while ago so I might be able to help figure out why it behaves the way you described. Regards, Regis On 20/12/06, Mark Griffin <[email protected]> wrote: > > I have a test program that gets the same results. The peers connect > to the net rendezvous then publish and discover a group advertisement > then publish and discover each other's pipe advertisement. > > Once a peer has joined the group it starts a listening thread and a > sending thread. The sending thread iterates through the list of > discovered peers sending a message to their pipe. The listening > thread echos messages back to the sending peer. > > So once you launch the peer you can sit and watch it discover and > echo messages to all other discovered peers. The output looks like > ping with time stamps, etc.. > > The net rendezvous connect usually happens quickly. The publish / > discover of the peer group advertisement in order to join the group > can take a half hour or more but it usually does work. > > Then the rest of the application behaves well. I can move peers to > different networks while the application continues to run and they > eventually join back in on the ping game. > > I'm probably using the JXTA API wrong or inefficiently in my sample > app. If anybody wants to take a look at it let me know. I have it > somewhat packaged up and ready to go. You just need to edit your > group and peer name in the launch script and away you go. > > > -Mark > > > On Dec 19, 2006, at 8:58 PM, Alan Zhang wrote: > > > It seems JXTA cannot discover peers behind NATs and two peers both > > behind > > NATs cannot connect to each other. I did a simple test by starting > > two jxta shell > > in one machine with different PIDs and different tcp ports. I > > diabled local > > multicasting to force the two peers to talk to each other via relay > > and > > rendezvous. Using "rdvstatus" command and "relaystatus" command, I > > found > > both peers could connect to a relay and a rendezvous, but they > > couldn't see > > each other even when they were connected to a same rendezvous peer(i.e > > jxta-38). I also created a pipe adv in one peer and tried to find > > the adv in the > > other peer but failed. I guess the relay peer might be a problem, > > because a > > edge peer behind NAT has to poll its relay peer for messages, if > > the edge peer > > failed to get other peers' query messages from the relay peer, it > > cannot answer > > the query to uncover itself to other peers. Any insight? > > > > Thanks! > > > > Alan > > 2006/12/20 > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > ------=_Part_40740_11546775.1166657363653 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div>Hi,</div> <div>I'm interested to take a look at your sample app code. A colleague of mine encountered a similar problem a while ago so I might be able to help figure out why it behaves the way you described.</div> <div> </div> <div>Regards,</div> <div>Regis<br><br> </div> <div><span class="gmail_quote">On 20/12/06, <b class="gmail_sendername">Mark Griffin</b> <<a href="mailto:[email protected]">[email protected]</a>> wrote:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I have a test program that gets the same results. The peers connect<br>to the net rendezvous then publish and discover a group advertisement <br>then publish and discover each other's pipe advertisement.<br><br>Once a peer has joined the group it starts a listening thread and a<br>sending thread. The sending thread iterates through the list of<br>discovered peers sending a message to their pipe. The listening <br>thread echos messages back to the sending peer.<br><br>So once you launch the peer you can sit and watch it discover and<br>echo messages to all other discovered peers. The output looks like<br>ping with time stamps, etc.. <br><br>The net rendezvous connect usually happens quickly. The publish /<br>discover of the peer group advertisement in order to join the group<br>can take a half hour or more but it usually does work.<br><br>Then the rest of the application behaves well. I can move peers to <br>different networks while the application continues to run and they<br>eventually join back in on the ping game.<br><br>I'm probably using the JXTA API wrong or inefficiently in my sample<br>app. If anybody wants to take a look at it let me know. I have it <br>somewhat packaged up and ready to go. You just need to edit your<br>group and peer name in the launch script and away you go.<br><br><br>-Mark<br><br><br>On Dec 19, 2006, at 8:58 PM, Alan Zhang wrote:<br><br>> It seems JXTA cannot discover peers behind NATs and two peers both <br>> behind<br>> NATs cannot connect to each other. I did a simple test by starting<br>> two jxta shell<br>> in one machine with different PIDs and different tcp ports. I<br>> diabled local<br>> multicasting to force the two peers to talk to each other via relay <br>> and<br>> rendezvous. Using "rdvstatus" command and "relaystatus" command, I<br>> found<br>> both peers could connect to a relay and a rendezvous, but they<br>> couldn't see<br> > each other even when they were connected to a same rendezvous peer(i.e<br>> jxta-38). I also created a pipe adv in one peer and tried to find<br>> the adv in the<br>> other peer but failed. I guess the relay peer might be a problem, <br>> because a<br>> edge peer behind NAT has to poll its relay peer for messages, if<br>> the edge peer<br>> failed to get other peers' query messages from the relay peer, it<br>> cannot answer<br>> the query to uncover itself to other peers. Any insight? <br>><br>> Thanks!<br>><br>> Alan<br>> 2006/12/20<br>><br>><br>><br>> __________________________________________________<br>> Do You Yahoo!?<br>> Tired of spam? Yahoo! Mail has the best spam protection around <br>> <a href="http://mail.yahoo.com">http://mail.yahoo.com</a><br><br>---------------------------------------------------------------------<br>To unsubscribe, e-mail: <a href="mailto:[email protected]">[email protected] </a><br>For additional commands, e-mail: <a href="mailto:[email protected]">[email protected]</a><br><br></blockquote></div><br> ------=_Part_40740_11546775.1166657363653--