Collapse OS Documentation Browser

doc/blksrv.txt

asm/ code/ hw/ algo.txt arch.txt avr.txt blk.txt blksrv.txt bootstrap.txt cross.txt design.txt dict.txt dis.txt drivers.txt ed.txt emul.txt faq.txt grid.txt grok.txt impl.txt intro.txt me.txt mspan.txt ps2.txt rxtx.txt sdcard.txt sega.txt selfhost.txt spi.txt usage.txt wordtbl.txt

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.

Collapse OS and its documentation are created by Virgil Dupras and licensed under the GNU GPL v3.

This documentation browser by James Stanley. Please report bugs on github or to james@incoherency.co.uk.

This page generated at 2022-07-05 21:05:03 from documentation in CollapseOS snapshot 20220509.