A turnkey private JXTA net demo
There is a lot of interest in private nets in JXTA, and understandably so. If you want to make money, history, or both with JXTA, one absolutely must come to terms with creating a private net in which your hosts can run without outside interference.
After some discussion with friends (thanks, Vanessa), we concluded that a simple standalone app that demonstrated private net creation and a working set of peers was in order.
Here is source code for creating a private net rendezvous and relay, and an application peer.
The code is not beautiful, or much commented, but if you’re into JXTA to any degree, you’ll see how it hangs together.
Unzip the zip file and modify build.properties to reflect where your JXTA distribution jars are.
Modify seeds.txt to reflect which host in your sandbox is the rendezvous/relay. As you can see, the bundled seeds.txt uses a typical home LAN type of network address.
Pick three hosts to run on. Call one of them the dedicated rendezvous/relay. On that host, run “ant rdv”. Logging output goes to ./rdvlog.txt. Tail the log file, looking for CLIENTCONNECT/CLIENTRECONNECT type of messages, just for fun and to convince yourself that your peers (below) are really connecting. If you never see a CLIENTCONNECT or CLIENTRECONNECT in the rdv log file, something is wrong. Check your host ACLs and such. Also, verify that an rdv listener comes up on port TCP 9701.
Pick two other hosts, copy the zip file to them, and run “ant node” on each. (Make sure the seeds.txt file is accurate!).
The “nodes” are real JXTA peers doing real work: they create a “propagate pipe” and write their PeerID and a random integer to it. The peers will not attempt to do this work, however, until they have connected to a rendezvous (see ‘waitforRdv()’ in MyPeer.java source). When the peer connects to a rendezvous, it will announce it to System.out.
Typical working (not including startup-type messages) System.out node output looks like this
[java] (from other): urn:jxta:uuid-59616261646162614E504720503250338E1B00F1F7CC4F76BEBAE14EA96ED64403 says 369883458 [java] (from self): urn:jxta:uuid-59616261646162614E50472050325033B75D6C9614D349F5AFCAF9A076718C7703 says -1309999697
Update 16 Nov 2006: I added “cache clearing” to both the build.xml Ant script and to the Rdv and Peer classes on startup.
Update 17 Nov 2006: Thanks to Jeff Schultz of the JXTA community for pinpointing a bug in the latest code. At this time the code runs for a lot of hours on end, and therefore constitutes a good working model on how to create a private p2p net with supported peers.
[tags]JXTA,p2p[/tags]
Thanks for the sample – there is a lot to learn from it. I got it run on my subnet but can’t get it to run across subnets – yet. I know you said the code was not beautiful but I saw unexpected behavior when I stopped and restarted the rdv. The rdv event was seen in the node and that caused the main method in the node application to return. The application stays running because the doSomething thread never returns.
Is there anything in the configuration that is preventing the rdv / node example from working across subnets?
mark griffin
November 15, 2006 at 2:35 pm
Hi. Yes, there is plenty of room for tweaking the code, esp. in the thread that never returns.
I did not test the code across subnets, mainly because I have no good way to do that. It should work in that situation, however, and I regret that you are having problems.
In the multi-subnet context, do you see the right TCP connections being made by the rdv and set of nodes? rdv’s should start listeners on port 9701, and nodes should connect to it. Also, and I’m sure you’ve done this, make sure that the rdv/relay seeds.txt are always correct. If you keep your rdv/relay on teh same host, set the seeds.txt correctly, and then move nodes around to various subnets, you should be ok. iow, move the nodes to foreign nets and not your rdv – saves you from changing the seeds file.
ae6rt
November 15, 2006 at 2:43 pm
As of about yesterday, the zip file code is working well and I consider this demo functional.
ae6rt
November 19, 2006 at 8:46 pm
The peers behind different NAT can’t communicate each other in my private net.
The peers can discover and communicate each other with JxtaBiDiPipe in the subnet.
The all peers can discover each other through RDV/Relay in the pubnet,the peer of fixed IP can exchange messages with other peer,
but Peers of non fixed IP behind different NAT can’t exchange messages each other with JxtaBiDiPipe.
Why message can’t deliver via relay?
How should configue to Rdv/Relay and Peer?
chenliguo
April 28, 2007 at 11:36 pm
Hi!
I’m wondering why the NetGroup and AppGroup created in this example is not displayed when using the ‘group [-r]‘ command in the JXTA shell.
Furthermore my two MyPeers receive message from each other but when I type in ‘peers [-r]‘ in the JXTA Shell each peer only lists itself and the RDV/Relay-peer.
What’s going wrong?
Thanks,
Martin
Martin
October 8, 2007 at 1:13 am
Hi, I have some questions about turnkey private JXTA net demo:
Can I use the AdHoc mode rather than RDV_SERVER + RELAY_SERVER? which are the differences?
For doing my own net, should I specify all the ids as it were specified in the Rendezvous class?
Thanks!!!
Leandro
Leandro
February 4, 2008 at 1:24 pm
Hi!
The link for the zip is no longer working. Can you please update it?
Thanks.
Enygma
January 15, 2009 at 11:39 pm
Thanks for the note about the broken link. I fixed it.
Mark
radioae6rt
January 16, 2009 at 6:44 am
Cool.
I already had a copy and wanted to see if it was the latest.
The problem is that you say that it is a private group and probably you mean that you use a private network. More specifically: you don`t use the public rdvs/relays and set up your own rdv instead.
I thought that by “private” you would mean creating and joining a group that has PSEMembershipService set and requires authentication.
Almost all tutorials just show how to join a group using the “StringAuthentication” method, but almost none of them actually show how to create a group and set pse membership + actually set the certificate + encrypted private key for that group.
It would be awsome if you could provide such a relevant example.
Cheers!
Rnygma
January 16, 2009 at 10:35 am