This article will focus on the way in which new processes are encorporated in the existing on-line GPSdancer network, and existing processes can leave the network, without leading to inconsistencies of the square dance exchange process. Before that, it will briefly explain how the first on-line network node can be launched, as it will not have a Dancer network to connect to.

Starting up of the Dancer network

In order to start-up a GPSdancer network on-line, the first process needs to acquire administrator priviliges. On a server or other network ("headless") computer this is done by defining the administrator password as environment variable, before launching the Dancer process. If the Dancer peer runs on a normal computer (with a keyboard and screen) the administrator can also logon by entering a special combination of keys in the GUI, and then typing the administrator password.

The GPSdancer project aims at having a single, global reference frame for all GPS receivers in the world. For this reason there will only be one single GPSdancer network on-line. The adminsitrator passwords that are needed to start-up the on-line network are not published, because a normal user will never need to do this anyway. The GPSdancer project (better said the Global Geodetic Grid Foundation, being the IPR owner of the global output products) launches the first process in the world. Any further GPS Dancer peer that goes on-line will either find this existing network on the web, or it will stop with an error message.

Connecting to the existing network

The sequence of network interactions that allow a new peer to join the Dancer network is explained here in a step-by-step approach.

(a) Your process connects to an existing peer

As long as you know the IP address and port of one existing GPSdancer process on the internet, your own process can connect to the network. The GUI menu allows for input of these connection details, and pressing the run-button will deal with the connection process. The connection details can also be entered via a configuration file (see the software documentation elsewhere on this site).

If your process connects to the serevr socket of an existing GPSdancer process on the web, this remote process will know that it is a new process, because its name is not included in its existing network map. If it exists, your process will not be considered as a new process, and the socket will close. This also ensures that no CORS station can be included twice in the same solution (...there is another check, namely GPSdancer excludes receivers that have a baseline to another receiver that is shorter than some threshold).

(b) The remote peer checks in your process

At the end of each nominal GPSdancer run, the GPSdancer peers will check-in their own CORS station in a global square dance exchange that produces the complete list of network stations. If a process has gone off-line, it will obviously not check in, and it will not be part of the updated network list. If your new GPSdancer process has connected to an existing process, it will not only check-in itself, but it will also check-in your new process, which does not yet have a proper network node number.

The process of checking-in accumulates a table of GPSdancer process names (CORS names), the associated IP address and port, and the node numbers in the square dance exchange scheme. After completion of the each active GPSdancer process in the network will have the latest list of active stations, which may include new stations that do not yet have a node number. With some basic rules, unique numbers are assigned to these new processes (each GPSdancer applies the same rules and therefore finds the sme numbers for each new process). If there any gaps in the number sequence - because a process has gone off-line - the highest-numbered nodes are renumbered to fill the gaps. The updated network list therefore always has a clean, consecutive series of node numbers (most of which will be identical to the previous process).

(c) The remote peer sends your process the network list

After updating the entire network list, your new process also has a proper node number, and is considered to be part of the official GPSdancer network by all other on-line instances. However - your own process does not yet know about it, so it cannot yet make its square dance network connections. Fortunately the remote GPSdancer instance to which your new process connected will remember that you are waiting for initialization of your network data. It will send your process the entire (up-to-date) network list, which not only means that you now know all other GPSdancer processes in the network, but your process also knows its own node number.

(d) All connections are made

On the basis of the up-to-date network map, all peers in the network will now create a precise set of \(\log_2{N}\) socket connections to other GPSdancer peers in the world, as dictated by the square dance algorithm. This is less straightforward as it may seem. A socket connection is created by one computer to the serversocket of a remote computer. If the two computers would do this independently, there would be two parallel sockets between the computers and each computer would be listening on the wrong line. Some rules are followed by all peers, for instance a lower numbered node will never connect to a higher numbered node, but expect the connection to come from the other side.

After this step, your new network process is fully incorporated in the network, while any nodes that had gone off-line since the penultimate network update have been completely forgotten by the existing network.

Going off-line

If your process goes off-line in a controlled manner - i.e. you instruct it to go off-line via the GUI - the only thing that happens is that your process will complete the on-going solution process (if any), and simply not check in for the next process. this implies to all other processes that you have gone off-line, and any existing connection to your computer will be closed.

A much more difficult problem to solve is the issue of dealing with peers that go off-line in an uncontrolled manner, at arbitrary moments during the Dancer process. This happens if a cleaning lady unplugs your computer to use her vacuumcleaner, or when lightning strikes and your building evaporates. You can read about this problem here.





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