# Question on packet encoding (payload length)

_General · started by deavmi on Fri, Sep 25, 2026 5:20 PM_

---

## Original post

**deavmi** · Fri, Sep 25, 2026 5:20 PM

I am working on my own implementation of Reticulum in Go, decided I hadn't coded
a fun project for sometime (I don't use LLMs) and decided that, given how cool I think Reticulum is, that it would be a great way to learn various things (crypto especially).

That being said I have my streaming encoder/decoder routines mostly finished but the one thing that I feel lost about is how does one determine the length of a packet's payload? Everything else is pretty much fixed (solely depending on certain flags) but I don't see a prefix length anywhere?

(Also hi Mark, I came to post here as suggested!)

---

## Reply 1

**Mark** · Sat, Sep 26, 2026 8:25 AM

The difference between *packets* and *frames* is a common point of confusion for beginners. There is (and should be) no prefixed length field or similar in a *packet*; it is an abstract representation, already bounded by whatever memory structure it is held in. The payload length is directly inferrable from that.

A *frame* is an actual, physical instance of the bitstream that corresponds to that packet on *some kind of wire/medium* in *some kind of encoding*. It is up to the interface driver and physical interface to ensure the correct framing of a packet, so that it can correctly be encoded, decoded and delimited. This framing/deframing may happen multiple times over the physical data path.

Various Reticulum interface types use HDLC framing, for the simple reason that it is as close to an optimal framing methodology we can get. See:

99efa20b2cca9df14d30804f834b9808:/page/entry.mu`zim=wikipedia_en_all_nopic_2026-06.zim|entry_path=HDLC

Alternative node:

eb7ffc2aa94dd39cf671dabfc6112bf7:/page/entry.mu`archive_path=/storage/wikipedia_en_all_nopic_2026-03.zim|entry_path=HDLC

It is efficient, simple to implement, fast and self-healing. The "naive" method of prefixing a payload length field is not very robust, and prone to cascading failure on physical medium errors.

In some special cases, there *may* be good reasons for using other framing methods, but generally, there isn't.

---

## Reply 2

**Mark** · Sat, Sep 26, 2026 8:33 AM

Also, I realize that this is simply an educational and "for fun" project you're doing to learn more, which is great. For specifics of how to do things in Go, as opposed to the Python refernce, you can probably learn a lot from Ivan's Reticulum-Go implementation, which is more or less fully functional already.

https://github.com/Quad4-Software/Reticulum-Go

---

## Reply 3

**deavmi** · Sat, Sep 26, 2026 11:45 AM

Two follow-up questions:

1. UDP and TCP

I can understand how it's easy to do framing with say datagram-based transmission (over UDP of a UNIX domain socket) as those themselves contain a length. But for stream-based, like TCP I still feel confused. You mentioned HDLC framing but am I to believe that people are currently using HDLC framing for TCP Reticulum peers?

2. Interpretation of the trailer/payload

Okay, so I think maybe I should change my question then. Based on the header fields, things like the destination type and so forth. I would be able to know what the content/payload is. Because if so then that simplifies things a bit. For example, knowing when there is a path request.

On that note are there any specifications for what that looks like on the wire. I see your have a "Size examples of different packet types" but I don't see the spec for them. I have read on to the other sections regarding the crypto stuff already and I do see what the contents may be but not a wire specification.

---