OK, so in the last post, I was getting into some channel capability flags, and how they impact handling of lost packets. The main conclusion for the purposes of that post was that we need some kind of sequence numbering in every packet, unless we just so happen to switch all reliability flags off.

Saving bits is a noble goal to be sure, especially when you have WiFi induced low MTU on the path. But I’m not sure that the extra branch you have to take for one of currently nine cases is worth saving them. You know what, let’s leave this decision for later. Personally, I am leaning to always sending sequence numbers, which can sometimes be ignored.

This post is all about how the …

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 …

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 …