COCO is a low level Peer-to-Peer middleware that enables decentralized communication over both TCP and UDP networks. For making it easy to develop on top of this P2P middleware, COCO provides 4 popular semantics that covers a plethora of use cases:

1. Pub-Sub: popular for IoT based devices and applications
2. Messaging: popular for any Application to Application communication, e.g. chat apps, dating apps
3. Streaming: popular for multimedia content delivery application.
4. Tunneling: popular for using existing protocols like HTTP, RTSP, MQTT, over a P2P network.

Blockchain is an application that relies on P2P communication over TCP. So a developer could use COCO to implement his own blockchain. He will have to implement the layer that implements an open and distributed ledger that can record transactions in a verifiable and permanent manner. To effectively implement the distributed ledger, he will need to create a protocol that validates new blocks using the messaging interface of COCO.

A VPN or Virtual Private Network is a centralized remote connectivity technology that provides machines the ability to connect into a common network using secure and encrypted tunnels via a central server. This central server is typically maintained by a networking specialist. When your machine is connected to a VPN, you are able to access all the services and data hosted on other machines in the VPN.

In contrast, the COCONet is a decentralized remote connectivity technology that provides software services the ability to connect into a common network using secure and encrypted tunnels in a cloudless and decentralized topology. Managing your COCONet doesn’t require an IT specialist, instead, you can simply use your COCO App and perform various Network Management functions in the COCONet. Further, rather than a machine-level connection, you can have connectivity sandboxing at an application level, so if one App running on the machine is connected to the COCONet, the other apps running on this machine cannot access the COCONet. This ensures your data remains private and within the COCONet.

If you are behind a unique network topology with some firewalls that are blocking UDP packets OR a symmetric NAT, the direct connection using UDP hole punching will fail. Under such conditions, the COCONet will provision a fallback to a NAT traversal technique using a relay node. The security architecture in the COCONet is such that every node exchanges keys when they form the connection, and so even the relay node is unable to decrypt the data and the security of the network is maintained.

Such an architecture, empowers Device makers (OEMs) and App developers to provide connectivity to their customers that is designed-for-privacy. The COCO platform handles all the communication routing, network transitions, security, encryption, and graph management so that the nodes remain connected to the P2P network with very high availability.

We would humbly suggest that your apps do not need to be on the Cloud for global connectivity. Using COCO, you can enjoy global connectivity while keeping your apps and data off the Cloud. It is possible of course to secure your Cloud-based apps and data, however, why run the risk of having such data hacked when you can remain Cloudless using COCO?

Through its hybrid P2P architecture, COCO enables apps and devices to interconnect through IP networks, without any central server in the path. This network enabled by the COCO software stack is what we refer to as “COCONet”.

There are two types of COCONet:

• Developer COCONet
• User COCONet

One of the features of the COCO solution is to enable onboarding and removal of apps and devices automatically, without any burden to those using COCO. This is what we refer to as dynamic node management.

A gateway provides connectivity to the internet. Some devices may not have the capability to connect to the internet, but if they can communicate to the gateway, then the gateway can provide access to the internet to those devices. Such connectivity is what is meant by P2P device gateway installation.

P2P stands for Peer to Peer. This refers to a network architecture where apps or devices may communicate with each other directly, without going through a central server. This provides benefits such as data privacy, low-latency, offline access, and many more. etc. which are at the core of what the COCO stack brings to market.

Yes, this is one of the key differentiating features of the COCO solution. While the COCO solution works over TCP/IP, one need not have a functional public internet, for facilitating communication on-premises. Especially in India, where the reliability of the public internet connection may be spotty in residential environments, COCO can enable on-premise smart home communication even if there is an internet outage.

Perhaps the best way to explain fine-grain resource control is through an example.

Let’s assume that you have COCO installed in your smart home, and would like to control your smart door lock remotely through your COCO network.

Let’s further assume that you would like to provide your maid access to enter your home by unlocking the smart door at around 9:00 am. Your maid is not to have access to any other resources on your network, for example, she may not access a storage device on the same network.

This is possible because of fine-grain resource control, where specific resources such as your smart door lock can be unlocked, for specific durations of time, while no other resources on the same network are accessed. This is as opposed to full network access that you may find in an enterprise VPN solution.

To enable rapid IoT development, the COCO App SDK is available on Operating Systems like Linux, Android, iOS, OS X, etc. and in various languages like C, C++, Java, Swift, and Javascript. Device manufacturers may use the COCO Device SDK on Operating Systems like Embedded Linux, FreeRTOS and ThreadX, and can be cross-compiled into various MCU and ARM architectures.

A node is part of only one cluster, and can only communicate with other nodes of that one cluster. Communication between different clusters is not possible. Having said that, It is possible for an application to start two instances of the Control Plane (CP), so it appears as two nodes. While from the cluster protocol point of view there can be no communication between two different clusters, the application will have access to two clusters in this case, and can in principle relay messages from one cluster to another.

Fig. Three different Apps/IoT Devices that are part of a cluster. 

In this example, A and B communicate directly with each other, as do B and C. Nodes A and C can also communicate with each other through node B (grey line).

Each node in a cluster has a unique name and its own public/private keypair. Each node maintains an encrypted database of information of other nodes that are visible to it, i.e. part of the same sub-cluster and the core cluster. This encrypted database does not always have to contain information about all nodes that belong to a cluster; it just has to know a few other nodes so it can make connections to them. When a connection is established between two nodes, they will exchange their knowledge of the cluster with each other, and potentially complement the information in each other’s databases.

The database contains information like the names of nodes, their public keys, and their last known IP addresses. Using this information, nodes can try to establish connections with each other over the Internet. Information about established connections is also shared with other nodes, such that all nodes have knowledge of the whole graph of connections within the cluster at any given point. If there is a path between two nodes in the graph, these two nodes can always communicate with each other.

A Data Plane provisions for all data transfers within the COCO P2P network occur using a cloudless data transfer mechanism. So, in essence, all data transfers go directly between the two nodes under most network topologies. The Data Plane of the COCO P2P network is used for various data transfer activities like:

• Message routing
• Message encryption
• Message signing
• Message authentication
• Providing direct channels of communication between all nodes
• Providing a pub-sub framework of communication between all nodes
• TCP semantics over a UDP connection

Using well-known techniques, the data plane connections can also be used when the two nodes are behind NAT devices. This is achieved by taking help from a third node with a public IP address aka “network management node” that is part of the control plane to perform UDP hole punching [https://en.wikipedia.org/wiki/UDP_hole_punching]. Even though 85% of the traffic in Control Plane (CP) is likely to traverse using UDP hole punching, CP provides TCP semantics to applications that require QoS guarantees provided by TCP. 

The Control Plane of the COCO P2P network is used for various network management activities like:

• Onboarding of new nodes into a network
• Removal of nodes from a network
• Discovery of nodes for performing UDP Hole Punching during data plane transfer
• Packet Relay as a fallback for NAT/Firewall Traversal when UDP Hole Punching fails

Under typical usage for Home Automation we expect users to be well within the free limit of 100MB/month on the Control Plane. You can use the COCO App to track your control plane bandwidth usage. Download COCO App.

As the name suggests, P2P enables communication directly between peers. Peer entities may be apps or devices created using either the COCO Client SDK or the COCO Device SDK respectively. We refer to such apps and devices as being “Buzzed on COCO”. For example, an app running on a smartphone communicating with a smart doorbell in your home. Or a chat app that is completely designed for privacy with no central server storing or inspecting the messages.

If you are a deep diver, then start exploring the self-help guides here .

Unlike the client-server architecture that defines distinct roles for clients and servers, in P2P networks there is no distinction, and all network participants are called nodes. A P2P node is both a client and a server and maintains a connection with at least 1 other P2P node to participate in the P2P network.

A mesh topology used by COCO is refered to as a ‘Cluster’. A mesh topology is the fundamental principle that connects the infrastructure nodes in a COCONet which makes it completely customisable for a given application while considering trade-offs around costs, on-device computing and storage capabilities, bandwidth availability, reliability and latency requirements.

In contrast to a star or a tree network topology, a unified P2P IP Mesh Overlay Network that works over TCP/IP and UDP/IP self-organises, auto-heals and provides low-latency communication between the nodes.

A mesh topology enables developers to eliminate this single point of failure and spread the data storage across user devices. This helps reduce their risks of security breaches and data theft that can attract large fines via new data privacy legislatures like GDPR and CCPA.