After a short hiatus imposed by a broken elbow, it’s high time for an update again. This time around, I want to focus on some basic design considerations that are derived from the requirements I explored in previous posts. The aim is to clarify some concepts, and as a result get a decent idea of the information we need to transmit in packet headers. In the previous post, I wanted to start with UDP as the base on which to build.

Following my last post in which I worked through various definitions of reliability in networking, it’s time in this post to look at the main protocol contenders, and examine how they measure up to those definitions. Let’s recap quickly with a list. Reliability can mean… Soft delivery guarantees. Hard delivery guarantees. Hard delivery guarantees along the entire path. (This wasn’t mentioned last time, but we’ll get to it.) Strict ordering of packets.

In the past months, I have not written much. I pushed forward with work for the Interpeer Project. But more recently, I also started as a researcher at AnyWi Technologies, joining friends from a past job. There, we participate in public/private research projects into next generation commercial drone platforms. While both domains have a multitude of differences between them, one strong overlap exists in the need for reliable and performant networking connections over the public Internet.

It’s not what you think it is. A few weeks ago, I led my connections to a single-question survey, asking what the currently most utilized distributed consensus algorithms is. This isn’t the largest group in the world, but it’s also a fairly mixed bunch: a majority is in the tech industry, but almost as many are not. Some or old guard, some entered the field only a while ago. Some are more research inclined, some more practically oriented.