Block Server (blksrv)

In POSIX tools/, there's a program called "blksrv" which is a
"block server", that is, a program that sends and receives
blocks to/from a serial link.

Admittedly, the goal of this program is very much pre-collapse,
but we can imagine some post-collapse uses for such a setup too:
I use it to facilitate the synchronisation between my retro
machines and my modern environment.

At some point during Collapse OS' development, I began
developing Collapse OS from within Collapse OS from a retro
machine. It worked well, but because I published Collapse OS on
something we called the "internet", I needed to fetch my work
from my retro machine and into my modern machine.

I tended to do this only once in a while, and even worse,
sometimes my modern machine also had some changes on it. Merging
was complicated.

Also, because I tended to not remember exactly what I had
modified recently, I tended to transfer the whole blkfs each
time (to be sure), which is a bit time consuming on a 9600 bauds
link.

The idea with the Block Server is that the retro machine is "in
charge". It controls what to push/pull and when, so the modern
machine is a slave to it. Because it's easy to do so while
working on the retro machine, then I can do it more often and
avoid tricky merging problems down the road.

How it works

Very simple. There are 2 commands: Get and Put. The client (the
retro machine) initiates a command by sending a 'G' or a 'P'
followed by a formatted 16-bit hex number (this means 4 chars).

If it's a 'G' command, the server reads the asked block from its
local file and spits its 1024 bytes as-is. Then, it spits the
checksum of those 1024 bytes as a hex-formatted 16-bit number.

The checksum is a simple sum of all bytes.

If it's a 'P' command, then it's the client that sends its block
in the same fashion. If the checksum matches, it writes it to
its local file.

The client and the server don't tell each other of checksum
failures or anything. You're supposed to see those because you
have access to both ends locally. At least that's the idea.

You remember when I talked about spitting contents as-is? You're
thinking that it could possibly cause transmission problems in 
the ASCII control chars range, don't you? Well yes, it can, but
this system is designed to send text blocks. Those blocks don't
contain ASCII control chars.

So, don't transmit binary data through this system or you're
going to have a bad time.