When two people want to meet up at a large event, they may be hampered when a pre-arranged rendezvous point turns out to be inconvenient, while any centralized services for real-time coordination are overwhelmed by demand. Peer-to-peer calculations between participating devices could guide the two friends to meet at an intermediate location, regardless of the continued movement of the two friends and participating devices in the area.

Code samples and illustrations from a simulation:

Using some of Protelis’s special operators and syntax (purple), a small number of functions (blue) can be defined and applied to variables (green). “Alice” and “Bob” can be directed toward each other (red dots) through the peer-to-peer calculations performed on participating devices (blue dots).

The function distanceTo computes the minimum distance from any device to the nearest “source device” (a device where source is true). The field d is initially Infinity everywhere, but is set to 0 on sources and set to the minimum across neighbors of the sum of d and the estimated distance to the current device.

def distanceTo(source) {
  rep(d <- Infinity) {
    mux (source) { 0 }
    else { minHood(nbr(d) + nbrRange) }

The function descend follows the gradient of a potential field down from a source. Given an original device (self) and a potential potential field, this function builds a path of intermediate devices connecting the original device with the source of the potential field. The original device is marked as part of the path. Other devices are identified as being on the path if one of their neighbors is already on the path, and they are the closest of that neighbor’s neighbors to the destination.

def descend(source, potential) {
  rep(path <- source) {
    let nextStep = minHood(nbr([potential, self.getId()]));
    if(nextStep.size() > 1) {
    let candidates = (nbr([nextStep.get(1), path]));
    source || anyHood([self.getId(), true] == candidates)
    } else {

The rendezvous function uses the descend function to identify the path between two people, whose devices have been marked with the owner property.

def rendezvous(person1, person2) {
  descend (person1 == owner, distanceTo(person2) == owner))

map with blue dots

Imagine an initial configuration where a number of individuals carrying participating devices (blue dots) are attending a large event, and two of them (Alice and Bob, as two yellow squares) wish to meet up.

map with blue and a few red dots

Alice and Bob activate their rendezvous application, and nearby devices that are on the shortest path between them start to be selected as part of their rendezvous path (red dots).

map with blue and more red dots

No central information service is needed for peer-to-peer calculation of the shortest path.

map with blue and even more red dots

The complete path is calculated, and will update automatically as Alice and Bob walk toward each other, and as intermediate devices move around.

For more information, see Protelis: Practical Aggregate Programming, Danilo Pianini, Mirko Viroli, Jacob Beal, ACM Symposium on Applied Computing 2015, April 2015.

In addition to peer-to-peer calculations, Protelis applications can take advantage of peer-to-peer communications to distribute software updates. This is an accelerate video of an Alchemist simulation of an upgradable crowd tracking applications. Each block dot represents a device with the Protelis process scheduler installed, but with no specific crowd tracking application running. Blue dots represent randomly selected devices injected with the crowd tracking application, which spreads through the aggregate scheduler to nearby devices. The red shadow shows detection of overcrowding by this version of the crowd tracker, which is judged to be too conservative. An updated version of the crowd tracker with a corrected overcrowding detection algorithm is then injected and spread through the aggregate scheduler, and the red shadow shrinks as the better danger estimation scheme takes over.

For more information, see this paper.