It seems as if I start every piece here with an apology for taking so long to continue writing. That’s the nature of my life right now, it seems. I’m sorry.

So let’s dive right in. Last time, I was writing about how different channels interact with each other, and what that means about messaging in fairly abstract terms. I also wrote before how I’m not a big fan of negotiating protocol features, and prefer to instead iterate to a new and improved protocol faster. I’ll touch on that in this post again. Also, I wrote that packet headers will have to include some reserved bits, which I will also refer to here.

Consensus

OK, so we left things off with establishing …

As is usual these days, I don’t write here half as much as I would like to. In recent weeks, this is because I have been very busy preparing for a number of conferences and writing papers. Since they all relate in one way or another to the protocol work I have been writing about, I figure people might find them interesting.

I have mentioned before that I am working part time at AnyWi Technologies B.V.. The two jobs are fairly complementary; at Interpeer, protocol design is for peer-to-peer networks, while in the latter, it is for autonomous vehicles, in particular for drones. Really, the Venn diagram between the two, if you would draw it, would probably have about 90% overlap or so. So …

Since I took such a long break before my last post, I figured I should forge ahead and write them while I can. Previously, I outlined the packet envelope information we’re going to send over the wire. Today’s topic is the basic messaging framework, handshakes and some considerations on channel establishment.

To recap, every packet belongs to a channel, and may contain one or more messages. In the absence of any other established channel, packets will belong to a default channel. This default channel shall be used for initiating connections.

This handshake can come in a number of different forms, to be discussed in detail at a later date. For now, let’s recall that we like …

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. That idea remains, but I would like to expand on this a little. The reason I gave is that for UDP (IP, really) there already exists routing equipment all over the Internet, which means that any protocol built on it should be routable almost everywhere. Also, it …