Connection Management - How Blocks Builds A Network
When the public Primary Server starts up it sits and listens for connections.
New servers are explicitly told the location of the Primary Server and
Both sides then create a session key based on a 512bit Diffie-Hellman Key
The connecting server (if it has a listening port) then advertises itself
to the Primary Server.
If the Primary Server has more than 10 connections it tells the connecting
server to disconnect once it has enough connections of its own.
The Primary Server forwards the advert to any other connected servers (the
advert includes the IP address and port of the new server).
Each server which receives the advert may choose to conect to the server
(choice determined by a PRNG and how many connections it already has),
or to forward the advert to other connected servers.
If the new server was told by the Primary Server to disconnect, it does
so once it has more than 4 connections.
Servers with less than 6 connections may readvertise to adjacent servers
periodically (every hour or so).
Servers with no connections may elect to reconnect to the Primary Server.
And thats how the Blocks 'network' gets built.
When a file is uploaded a hash of the encrypted contents of the file is
This hash, along with the filename, and filesize, is sent to all adjacent
When each server receives the advert (and decides that it is a new advert
and not one which has been routed round in circles) it attaches a character
A-P noting which connection the advert came from.
The advert is then added to the advert cache unless an advert for the same
file (same hash) already exists with a shorter route.
If the routing length (TTL) is less than 6 then the advert is sent to all
NOTE: At some future point the routing character will probably be encrypted
with the servers main encryption key before being appended to the route.
When the user requests a file he is really just requesting the first 'header'
block identified by the hash value from the File Advertisement. He strips
off the first routing character and sends the request to the appropriate
The server receiving the request attaches a character A-P noting which
connection the request came from.
If the server receiving the request has the data block in cache it strips
off the first character for the return route and sends the data block (with
the return route) to the appropriate connection.
Otherwise it strips off the first character of the sending route and sends
the request to the appropriate server.
Servers receiving a data block with a return route strip off the first
character of that route and send the block to the appropriate adjacent
Once the requesting server has the first data block (the 'header') it then
gets the block IDs for the rest of the file out of the header block and
requests each one in turn.
Once the requesting server has all the blocks for the file, it is reconstructed
by joining all the datablocks together and decrypting the file with the
key contained in the header block. (NOTE: this decryption is simply there
so that if the same file is uploaded twice, all the data blocks have different
content hashes... no zero blocks, or duplicates... this is not for security).
The Disk Cache (not really part of the protocol, but what the hell)
The disk cache is just a big ring buffer full of 64Kb
data blocks. All blocks are encrypted using a block cipher using a random
key. This key is created on startup from user supplied entropy (mouse clicks)
and is only stored in memory. Thus, once the program is dead, the key is
lost forever in user space (might still be in your swap file or sitting
in your unused memory somewhere though :-). Similarly the advert cache
file which keeps a list of all the file adverts and the header block ID
for each file stores the header block ID encrypted with main random key.
Cipher: Main cipher is a homebrew based on a 20 round version of
Wheeler and Needham's XTEA algorithm.
Hash: upper 128bits of RIPEMD-160
D-H: uses the Karatsuba square and multiply method.