The GPSdancer network connections are defined according to the needs of the square dance algorithm, in which data contributions from each individual network node are efficiently passed to every other node in the network. However, the square dance algorithm only works because all nodes know when to start a new exchange. For incidental data broadcasts from one network node to all others, an alternative approach is available.

Network broadcast data can originate at any active GPSdancer process (for instance, an administrator logs in to an existing process to which he has access, and publishes a software update or input file update from that GPSdancer instance). This network node will send a short message on all its existing network connections (...there will be $$\log_2{N}$$ connections per CORS process, where $$N$$ is the total number of CORS stations in the network), announcing a publication with a certain unique identifier and publication time.

The network neighbours that receive this message will download the published file from the source node, unless they already have this publication. If a network node already has the publication indicated by the incoming signal, the signal is simply ignored to avoid infinite recursions. After downloading the published data from the source - which each network node will do once, and only once -  the receiving network node will publish it on all its own network connections. This includes the connection to the source of the information, but that node already has the data, and will ignore the incoming publication signal.

The above approach to spreading information from one network node to all others is extremely efficient, and implicitly finds the fastest network connections to sdistribute the data: a network neighbour with a fast network interface will download the data faster than neighbours with slow connections, and the fast computer will therefore re-publish the data before slower computers. Other neighbours, who do not yet have the data, will typically be advised sooner by a fast neighbour than by a slow neighbour, etc.

The broadcast system is used to inject software updates of the GPSdancer software itself, but also to spread e.g. new ANTEX input files, bulletin B a priori earth rotatin information, etc.. Files and other information may be injected at multiple points more or less simultaneously, to speed up the process and to avoid single-point-of-failure (... i.e. the source).

The above approach allows external data files to be retrieved by any existing GPSdancer process. For instance, if a new input Bulletin B file is needed, it will download it from the public internet and then publish it to all other GPSdancer network nodes. Most of the other network nodes will receiver this new file before their own analysis discovers that the new file is due. This avoids the situation that all active GPSdancer processes simultaneously download the same external input file, which would probably be experienced by the poor remote server as as denial-of-service attack.

### Project details

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

### Square dance algorithm

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