Building and Testing a JXTA Application

Building and testing your first JXTA JSE application can be difficult. Here are some useful "tricks" which may help simplify the process.

If your application is planned to run on the whole internet then turn off TCP multicast while testing. Multicast provides different behaviours that are not available across the whole Internet. Your application may make incorrect assumptions which won't work once the application is deployed on the Internet. When you are satisfied that your application is working correctly you can turn on multicast as an optimization.

Use only one network transport. JXTA provides several network transports; TCP, HTTP and soon UDP and probably BlueTooth. Having traffic routed through multiple transports can be very confusing to debug and when things don't work it can be very difficult to figure out where the problem originates. Configure, tune and use only one network transport at a time until you are satisfied with how each performs. Once you have everything working you can enable multiple network transports as an optimization.

Don't run a rendezvous in the public network. If your peers are connected to the JXTA public network then you will not be able to run your own rendezvous. The public JXTA rendezvous servers use the ACL feature in order to exclude random "rogue" rendezvous to improve performance. This means that your rendezvous will not work correctly in the net peer group. There are two solutions you can use; isolate your peers on a disconnected network or use the JXTA private net peer group features.

Use JXTA Logging. If you are doing development with JXTA then you should enable WARN or INFO level logging. WARN or INFO log levels will provide you a lot of information about what JXTA is doing and how JXTA is configured. Enabling logging is perhaps the most important single way that you can reduce your frustration with debugging JXTA applications.

Use private networks. If your application will eventually need to use the JXTA private net peer group feature then you should enable this feature as soon as possible. Disconnecting yourself from the JXTA public network will remove a lot of the ambiguity and mystery because you will control all of the peers.

Comments:

Thanks, Mike. This is good advice. I have one question, though. If one should use only one transport, which should it be? I have been leaving both TCP and HTTP turned on under the assumption that a) some peers cannot be reached by TCP, and b) HTTP is not as efficient as TCP. So...should HTTP be my first choice, or TCP? Or am I stuck with both?

Posted by Vanessa Williams on July 20, 2006 at 08:01 AM PDT #

You can use either and the best choice is probably the message transport which is most likely to be the one used in the field. I personally prefer to use the TCP transport when I have a choice because it isn't quite as quirky about when/why it connects/disonnects. In order to meet HTTP requirements the HTTP message transport is a bit more mysterious in its behaviour. Both message transports should produce identical results, but the TCP message transports behaviour is usually easier to explain.

Posted by Mike Duigou on July 21, 2006 at 02:17 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

mduigou

Search

Archives
« July 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today