| META TOPICPARENT | name="WebHome" |
This topic is related to either isolating your JXTA network for privacy or for testing without affecting the public network. Testing is probably more important because you should "NEVER" add a peer to the public network that acts as a RDV or acts as Relay (this will not even be possible in some networks, including the public network, in the future versions of JXTA -post 2.2.1). The reason is that only managed peers should be setup to act this way. Testing also causes problems if these peers are brought up and down.
If we are testing, we also might want to be sure that we are in control if the network and have the best response. By having out own RDV we can be sure all the tests work and are not affected by the public network. By creating the public network we ensure there are no public peers attaching and using our RDV and Relay or that our test peers are not talking to the public RDV/Relay that may be busy or even using a different version of JXTA.
A private network can also be used for a corporation. This allows the corporation to allocate RDV/Relays and isolate peers that use them. This does two things that are important to many companies: First is isolation and thus a level of security. Second, this allows you to monitor and manage the RDV and Relay peers to ensure a level of service for your clients.
The best solution is to place a config.properties file in your .jxta directory. Do this with all your peers and the RDV peer. This prevents all the peers from contacting the public peer groups even if the seeds are downloaded. Note that only one peer needs to download the seeds to infect the group and add it to the public network! That's why this is the better solution because it is true isolation.
Note that this explicitly disables the capacity of a peer to reach
the public NetPeerGroup?.
Here is what should be in config.properties:
NetPeerGroupID=jxta:uuid-??????????????????????????????????
NetPeerGroupName=MyNameForNetGroup
NetPeerGroupDesc=My desc for Infrastructure Group
How do you generate the peer group ID? Below is how I do it so that I can generate it on the fly. You can either do this before you start jxta and write the file or print the ID and paste it into the config.properties file. Not that if it is printed, it is prefixed with "urn:" which must be removed.
public static final net.jxta.peergroup.PeerGroupID createInfrastructurePeerGroupID(String clearTextID, String function){
LOG.info("Creating peer group ID = clearText:'"+clearTextID+"' , function:'"+function+"'");
byte[] digest = generateHash(clearTextID, function);
net.jxta.peergroup.PeerGroupID peerGroupID = IDFactory.newPeerGroupID( digest );
return peerGroupID;
}
/**
* Generates an SHA-1 digest hash of the string: clearTextID+"-"+function or: clearTextID if function was blank.<p>
*
* Note that the SHA-1 used only creates a 20 byte hash.<p>
*
* @param clearTextID A string that is to be hashed. This can be any string used for hashing or hiding data.
* @param function A function related to the clearTextID string. This is used to create a hash associated with clearTextID so that it is a uique code.
*
* @return array of bytes containing the hash of the string: clearTextID+"-"+function or clearTextID if function was blank. Can return null if SHA-1 does not exist on platform.
*/
public static final byte[] generateHash(String clearTextID, String function) {
String id;
if (function == null) {
id = clearTextID;
} else {
id = clearTextID + functionSeperator + function;
}
byte[] buffer = id.getBytes();
MessageDigest algorithm = null;
try {
algorithm = MessageDigest.getInstance("MD5");
} catch (Exception e) {
LOG.error("Cannot load selected Digest Hash implementation",e);
return null;
}
// Generate the digest.
algorithm.reset();
algorithm.update(buffer);
try{
byte[] digest1 = algorithm.digest();
return digest1;
}catch(Exception de){
LOG.error("Failed to creat a digest.",de);
return null;
}
}
-- DanielBrookshier - 07 Jun 2004 |