Asynchronous Communication

Asynchronous communication is communication between two endpoints that doesn’t have to happen in real time or near-real-time.

Compared to synchronous communication, asynchronous communication lets you trade latency for reliability.

Asynchronous communication is closely related to the concept of store-and-forward networking and delay/disruption-tolerant networking. In fact, most asynchronous implementations are also store-and-forward and delay-tolerant, so these terms are often used interchangably.

Let’s examine the difference with synchronous communication, which we are probably more familiar with:

With synchronous communication – such as web sites – the web browser and the web server must be in live communication. It make take 20 hops across Internet routers to reach the other end, but those routers don’t take responsibility for the onward delivery of packets; it’s up to the two endpoints to detect if packets were dropped. If the delay from one end to the other exceeds even one second, things can start to get difficult. An interruption at any point along the path from source to destination will cause the communication to fail entirely.

Asynchronous communication, by contrast, only insists that a packet be able to advance to the next hop in real time. The next hop could be anything from another node to a USB drive. Once the packet is delivered to the next hop, the next hop takes responsibility to advance it onward to its destination. This lets the overall communication path be more reliable, because an interruption at any point simply causes traffic to be delayed, not lost. The tradeoff is that it has higher latency than synchronous communication.

Examples of asynchronous communication

Email – or more particularly, the way SMTP is used – is a widely-known system. With email, SMTP is the hop-to-hop protocol. Each mail server is only responsible for delivering the message to the next hop. Once delivered to the next hop, that server takes responsibility to advance it to its destination.

NNCP and the older UUCP are ground-up asynchronous protocols. NNCP in particular is a modern asynchronous system, supporting a variety of transports from the Internet to USB drives, and using encryption and onion routing.

Syncthing isn’t usually thought of as asynchronous, but its syncing protocol certainly can and does operate in that way.


UUCP is a system for exchanging data and requesting remote execution. It dates back to 1979, and was primarily used over Modems using telephone landlines for most of its days of popularity. It is an Asynchronous Communication system, which transmits data from one machine to the next on the way to its destination. Each intermediate node may store the data before passing it on to the next.

NNCP is a powerful tool for building Asynchronous Communication networks. It features end-to-end Encryption as well as all sorts of other features; see my NNCP Concepts page for some more ideas.

Inspired by several others (such as Alex Schroeder’s post and Szczeżuja’s prompt), as well as a desire to get this down for my kids, I figure it’s time to write a bit about living through the PC and Internet revolution where I did: outside a tiny town in rural Kansas. And, as I’ve been back in that same area for the past 15 years, I reflect some on the challenges that continue to play out.

dar is a Backup and archiving tool. You can think of it as as more modern tar. It supports both streaming and random-access modes, supports correct incrementals (unlike GNU tar’s incremental mode), Encryption, various forms of compression, even integrated rdiff deltas.

This page gives you references to software by John Goerzen.

According to the NNCP documentation, NNCP is intended to help build up small size ad-hoc friend-to-friend (F2F) statically routed darknet delay-tolerant networks for fire-and-forget secure reliable files, file requests, Internet Email and commands transmission. All packets are integrity checked, end-to-end Encrypted, explicitly authenticated by known participants public keys. Onion encryption is applied to relayed packets. Each node acts both as a client and server, can use push and poll behaviour model. Also there is multicasting area support.

It seems that lately I’ve written several shell implementations of a simple queue that enforces ordered execution of jobs that may arrive out of order. After writing this for the nth time in bash, I decided it was time to do it properly. But first, a word on the why of it all.

A distributed version control system. With gitsync-nncp, can be used over Asynchronous Communication.

gitsync-nncp is a tool for using Asynchronous Communication tools such as NNCP or Filespooler, or even (with some more work) Syncthing to synchronize git repositories.

In my writing about dar, I recently made that point that dar is a filesystem differ and patcher.

Here is a comparison of various data backup and archiving tools. For background, see my blog post in which I discuss the difference between backup and archiving. In a nutshell, backups are designed to recover from a disaster that you can fairly rapidly detect. Archives are designed to survive for many years, protecting against disaster not only impacting the original equipment but also the original person that created them. That blog post goes into a lot of detail on what makes a good backup or archiving tool.

Email is one of the most common examples of Asynchronous Communication people are familiar with today. It is a store-and-forward approach which is tolerant of temporary disruptions to services and supports multiple hops.

Filespooler makes an excellent tool for handling Backups. In fact, this was the case the prompted me to write it in the first place.

When things are difficult – maybe there’s been a disaster, or an invasion (this page is being written in 2022 just after Russia invaded Ukraine), or maybe you’re just backpacking off the grid – there are tools that can help you keep in touch, or move your data around. This page aims to survey some of them, roughly in order from easiest to more complex.

You can use gitsync-nncp (a tool for Asynchronous syncing of git repositories) atop Filespooler. This page shows how. Please consult the links in this paragraph for background on gitsync-nncp and Filespooler.

Filespooler lets you request the remote execution of programs, including stdin and environment. It can use tools such as S3, Dropbox, Syncthing, NNCP, ssh, UUCP, USB drives, CDs, etc. as transport; basically, a filesystem is the network for Filespooler. Filespooler is particularly suited to distributed and Asynchronous Communication.

NNCP lets you securely send files, or request remote execution, between systems. It uses asynchronous communication, so the source and destination need never be online simultaneously. NNCP can route requests via intermediate devices – other NNCP nodes, USB sticks, tapes, radios, phones, cloud services, whatever – leading to a network that is highly resilient and flexible. NNCP makes it much easier to communicate with devices that lack Internet connectivity, or have poor Internet.

Syncthing is a serverless, peer-to-peer file synchronization tool. It is often compared to Dropbox. However, unlike Dropbox, there is no central server with Syncthing; your devices talk directly to each other to sync data. Syncthing has various effective methods for firewall traversal, including public relays for the worst case. All Syncthing traffic is fully encrypted and authenticated.

I sometimes see people read about NNCP and wonder “This sounds great! But… what can I do with it?” This page aims to answer those questions.

Sometimes we want better-than-firewall security for things. For instance:

Here are some (potentially) interesting topics you can find here:

This page describes some basic concepts of NNCP.