Hello and welcome for a short update!
There’s not much and it’s not very nice code. But it’s something, right?
I decided to postpone Settlers II itself as I need transport layer. I decided ZMTP is the best one for me (why is the topic on the other blogpost incoming!) so I started doing something basic with it. According to ZMTP 3.1 specs first octet (8 bits) follows this convention:
- bits 7-3 are reserved for future use and are 0
- bit 2 indicates if frame is message (0) or command (1)
- bit 1 indicates if frame is long(1) or short(0)
- bit 0 indicates if there are more frames (1) after this one or not (0). For command it’s always 0.
Now for some clarification. “Bit 0” means “right-most bit”. Short message has body of 0 to 255 octets. Long message has body of 0 to 2^63 – 1 octets.
Next we have size field – it’s one or eight octets, depending on LONG flag. What’s important that size doesn’t include flags and itself – so empty frame has a size of 0 even if it has flags and size set.
Lastly we get SIZE octets of body.
In the commit we have simple encode/decode for frame with SIZE = 1, LONG = false. There’s a difference between Command and Message.
I am sure that “reserved” is redundant and code itself is not something clean and nice. But it’s a little start that I will continue working on and either refactor or throw it away.
Bytes are represented in Elixir as <<values>>. It’s quite useful to get working, but we can get better than I got here.
As for functional language specific stuff, please take a look at multiple definitions of private method decode_flags. It’s the pattern matching on functions (yup, can do it better here) – elixir will look for matching function and will call it. It’s simple and quite powerful feature.
In the next commit(s) and post I will make those encode/decode functions more general to be able to work on all sized frames. And hopefully more 😉