Re: 答复 : Re: [JXTA user] JXTA private net problems
"Mark S. Petrovic" <[email protected]> Wed, 27 Dec 2006 06:54:02 -0800
| Newsgroups | gmane.comp.java.jxta.user |
|---|---|
| Message-ID | <20061227145402.GD9244@false> |
chenliguo, hello. An Internet-based private JXTA net should work as well as it does on a single subnet. A couple possible explanations of why your private net may not work on the open Internet: 1) The rendezvous is behind a packet filter the is blocking edge peers attempting to connect. 2) The rendezvous is behind a consumer grade home router that is changing= port numbers if you are using port-forwarding. - Check your OS security log files to see if packet filter violations are occuring on any JXTA ports. - Does your rendezvous peer ever output a "CLIENTCONNECT"? - Does your edge peer ever output a "RDVCONNECT"? Mark On Tue, Dec 26, 2006 at 01:17:23PM +0800, [email protected] wrot= e: >=20 > Hello all: >=20 > My private net working very good in a subnet,but can not working in th= e > Internet. > Peer can not discovered other peer in the Internet. > How use the NetworkConfigurator class? > What PlatformConfig file should be content? > How deploy private net working in the Internet? > Have the best practice? >=20 >=20 > thanks. >=20 >=20 >=20 >=20 >=20 > (See attached file: my private net.jpg) >=20 >=20 > (Embedded image moved to file: pic16541.pcx) >=20 >=20 >=20 >=20 >=20 >=20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =E5=86=85 = =20 > =E5=AE=B9=EF=BC=9A = =20 > =20 >=20 >=20 > = =20 > Jeff Schultz = =20 > <[email protected] =E6=94=B6=E4=BB=B6=E4=BA=BA=EF= =BC=9A [email protected] =20 > .AU> =E6=8A=84=E9=80=81=EF=BC=9A (= =E5=AF=86=E9=80=81=EF=BC=9A chenliguo/Bjxinwei) = =20 > =E4=B8=BB=E9=A2=98=EF=BC=9A R= e: [JXTA user] JXTA private net problems =20 > 2006-12-06 = =20 > 09:24 = =20 > =E8=AF=B7=E7=AD=94=E5=A4=8D =E7=BB=99 = =20 > user = =20 > = =20 > = =20 >=20 >=20 > > Sorry for the confusion ;) > > 10.1.14.132 is the IP of my PC and 192.168.13.6 is used in the DMZ an= d > > 83.64.248.67 is the external IP. But I just took my server out of the > > DMZ and directly connected it to the Internet and WOHOOOOO .... it > > finally works ;) I was able to connect to my Rdv/Relay! > > > > To sum up I had two problems: > > 1) Using hostnames as seeding URI did not work. > > Only IPs are valid! > > 2) Running a Rdv/Relay behind a router with portforwarding does not w= ork! > > The server MUST have an Internet addressable IP for JXTA to work. >=20 > It can't work unless the router is told to allocate a fixed port > number, forwards the packets properly, and, critically, the JXTA RDV > process knows it's happening. This is because while the router > changes outgoing packets to pretend they come from the external > address, it can't do anything to the content, including the JXTAHELLO > generated by the RDV. (I'm not clear why it needs to announce the > interface it's using in this way, but it does do it, and it needs to > use the right, reachable, address for it.) >=20 > If you're configuring the RDV programmatically, you'll need something > like the following, with, in your example, localAddress > "tcp://192.168.13.6:9901" and publicAddress "tcp://83.64.248.67:9901": >=20 > TcpTransportAddress tcpAddress =3D new TcpTransportAddress(); > tcpAddress.setAddress(new URI(localAddress)); > . . . // more configuration > TcpTransport tcpTransport =3D new TcpTransport(); > tcpTransport.setAddress(tcpAddress); > if(proxyURI !=3D null) { > PublicAddress publicAddress =3D new PublicAddress(); > publicAddress.setAddress(new URI(proxyURI)); > publicAddress.setExclusive(true); > tcpTransport.setPublicAddress(publicAddress); > } >=20 >=20 > Configured like this, it does work, but it has two problems: >=20 > 1) It's a pain to deploy unless you're only setting up a couple of > processes. It's useless for an end-user deployment unless you feel > like getting UPnP to work, and even then, I doubt it's worth trying. >=20 > 2) Don't try this at home. As Mark says, consumer-grade routers are > unlikely to do the right thing all the time, although in my experience > they work for a few tens of thousands of messages and then lock-up. >=20 >=20 > Jeff >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >=20 >=20 >=20 --=20 Mark S. Petrovic Pasadena, CA=20 http://www.petrovic.org