The peer-to-peer (P2P) layer below GPS Dancer is based on JXTA. JXTA (short for juxtapose) is a collection of XML-based prototcols developed by SUN Microsystems from 2001 onwards. It creates a virtual overlay network that allows any two computers to communicate with each other via a series of XML exchanges, regardless of the involved operating system, programming language or other implementation details. Moreover, JXTA offers various mechanisms to deal with network obstacles such as firewalls, NAT translators or proxies, in a way that is completely transparent to the client code. There are implementations ("bindings") of the JXTA protocol in various programming languages. The native binding is in JAVA, and its version 2.6 is used by Dancer.

Initially, SUN and later Oracle hoped that JXTA would become the global standard for P2P applications on the internet. They also hoped that peer-to-peer computing would become a hype. This is why different JXTA-based P2P applications will happily work together to pass information between peers from different projects and sub-projects. The advantage is that, in case of widely-spread use of JXTA, the global network of JXTA peers would become so dense that communication flows smoothly via any route available. Essentially, it would create a whole new internet on top of the other internet.

In practice JXTA is rather difficult to live with. Its concepts are abstract, poorly documented and not very intuitive. The software itself is also poorly documented, and often the available documentation applies to some older version of a JAVA class that you are trying to use, which leads to unpredictable behaviour and many hours of frustrating debugging sessions. In summary, JXTA is not very good at making new friends.

However - the only alternative to using an existing P2P layer like JXTA would have been to implement our own. Given that the GPS Dancer project is organized by GPS people, not internet gurus, the result would undoubtedly have been far less stable and useful than JXTA, and the amount of time lost with implementation and testing would have exceeded the considerable amount of time that was now spent on learning JXTA.

At this point it is only fair to give some credit to Jerome Verstrynge, who has over the years turned into mister JXTA, and has always been extremely helpful in answering questions through JAVA forums, the JXTA-JXSE project, or simply by direct e-mail. His book is probably the best attempt at making JXTA easy. Without people like this the Dancer project would also not have been where it is today.

From many elements of the JXTA JXSE implementation, the version 1.0 of Dancer only uses the JxtaSocket and JxtaServerSocket classes for communication between peers. It then assigns these to normal JAVA Socket and ServerSocket instances, taking care not to use any non-supported methods of these generic parent classes. This approach implies that GPS Dancer could actually use other Socket or ServerSocket classes in the future as a direct replacement for JXTA. If one day the GPS Dancer project meets a network guru with a lot of time on his hands (yeah right), he or she can implement an alternative communication layer to replace the JXTA sockets, and we would not have to change anything else in the software. Until that day, JXTA 2.6 will be with us.

One of the key features that motivated the choice for JXTA (as opposed to e.g. Tapestry) was JXTA's capability to transparently switch protocols between e.g. HTTP and TCP, according to network layout and local levels of protection (firewalls, Network Address Translators etc). Unfortunately, modern firewalls are becoming so restrictive that even automatic switches to HTTP on port 80 are no longer easy. This means that in practice your Dancer peer will hardly ever be able to function behind a corporate firewall, unless you have an external proxy or you run your own JXTA relay peer outside the firewall. If you have no idea what any of this means: welcome to the party. You have just discovered some of the confusion that you need to fathom while learning JXTA. It's not  for everyone.

Because JXTA turned out to be just a bit harder than the originators seemed to have anticipated, SUN and Oracle have quietly stepped back from the protocol, by no longer doing anything about it. Around 2010 the JXTA project moved to Kenai, and today it seems to have found a place at amongst a few thousand other projects. The reborn version of JXTA is called Chaupal. It's really just JXTA-the-sequel, but Oracle does not allow the use of the name JXTA by third parties.

The good news is that you do not need to know much about JXTA (or the internet) to run GPS Dancer. Step-by-step instructions on network configuration are provided in the tutorial. As soon as you discover that your local firewall will never allow you to open TCP connections to unlisted external sites or on non-standard HTTP ports, you might as well forget about trying to get it running on your system. Instead, you just run Dancer on a commercial cloud computing account, which typically solves all these problems.

If there are nonetheless users who want to learn more about JXTA, try any of these sources:

  • A free on-line book about JXTA - and another one.
  • Some Wikipedia pages about JXTA
  • Some JavaDoc pages about individual classes (only of interest to programmers, if that)
  • The book by Jerome Verstrynge about tribes living on islands (see picture above). Some cruel minds could read its title as an oxymoron of the type "military intelligence", or, to stay in IGS tradition, "friendly competition".
  • Finally, here is a download site where you can still get the JXTA binaries. Good luck.




Project details

Ultimate Browsers SupportThe GPS Dancer project started in 2007 as a voluntary project of a working group of the International Association of Geodesy.

Read more ...

Square dance algorithm

Great Docs and SupportThe GPS Dancer system was named after its "square dance" exchange algorithm. Of course, it also wants to to make the GPS reference frame denser.


Here, there be pirates

The Dancer on-line network became immune against internet connection problems by leaving the US marines, and becoming a pirate.

Read more ...

Go to top