Picos are designed to form heterarchical, or peer-to-peer, networks by connecting directly with each other. Because picos use an actor model of distributed computation, parent-child relationships are very important. When a pico creates another pico, we say that it is the parent and the pico that got created is the child. The parent-child connection allows the creating pico to perform life-cycle management tasks on the newly minted pico such as installing rulesets or even deleting it. And the new pico can create children of its own, and so on.

Building a system of picos for a specific application requires programming them to perform the proper lifecycle management tasks to create the picos that model the application. Wrangler is a ruleset installed in every pico automatically that is the pico operating system. Wrangler provides rules and functions for performing these life-cycle management tasks.

Building a pico application can rarely rely on the hierarchical parent-child relationships that are created as picos are managed. Instead, picos create connections between picos by creating what are called subscriptions, providing bi-directional channels used for raising events to and making queries of the other pico.

This diagram shows a network of temperature sensors built using picos. In the diagram, black lines are parent-child relationships, while pink lines are peer-to-peer relationships between picos.

There are two picos (one salmon and the other green) labeled a "Sensor Community". These are used for management of the temperature sensor picos (which are purple). These community picos are performing life-cycle management of the various sensor picos that are their children. They can be used to create new sensor picos and delete those no longer needed. Their programming determines what rulesets are installed in the sensor picos. Because of the rulesets installed, they control things like whether the sensor pico is active and how often if updates its temperature. These communities might represent different floors of a building or different departments on a large campus.

Despite the fact that there are two different communities of temperature sensors, the pink lines tell us that there is a network of connections that spans the hierarchical communities to create a single connected graph of sensors. In this case, the sensor picos are programmed to use a gossip protocol to share temperature information and threshold violations with each other. They use a CRDT to keep track of the number of threshold violations currently occuring in the network.

The community picos are not involved in the network interactions of the sensor picos. The sensor network operates independently of the community picos and does not rely on them for communication. Astute readers will note that both communities are both children of a "root" pico. That's an artifact of the way I built this, not a requirement. Every pico engine has a root pico that has no parent. These two communities could have been built on different engines and still created a sensor network that spanned multiple communities operating on multiple engines.

Building decentralized networks of picos is relatively easy because picos provide support for many of the difficult tasks. The actor model of picos makes them naturally concurrent without the need for locks. Picos have persistent, independent state so they do not depend on external data stores. Picos have a persistent identity—they exist with a single identity from the time of their creation until they are deleted. Picos are persistently available, always on and ready to receive messages. You can see more about the programming that goes into creating these systems in these lessons: Pico-Based Systems and Pico to Pico Subscriptions.

If you're intrigued and want to get started with picos, there's a Quickstart along with a series of lessons. If you want support, contact me and we'll get you added to the Picolabs Slack.

The pico engine is an open source project licensed under a liberal MIT license. You can see current issues for the pico engine here. Details about contributing are in the repository's README.