Mesh Network

This is meant to sit above the TCP layer, but with the modification that routers and computers should connect directly.

Requests fall into two categories, static broadcasts and dynamic response. A static broadcast of a resource means that any node can fulfill the request. A broadcast has two parts, the message and the signature. The message is the data and is unencrypted. The signature is a hash of the message signed with the originators key. A dynamic response follows the same format, but is encrypted for the originator of the request.

Static Broadcast Request

Request

• Topology of requester
• Public key of content-owner
• Resource Id (up to 1kB)
• Optional: topology of resource

Routing

The message is routed until someone has the resource at which point a response is sent. The responder does not have to be the content-owner, they can simply have the resource cached. If the topology of the resource is included, it will be followed. This can be modified by any node along the way. This may happen if a better topology is found. Nodes also have the option of attaching a processing time before re-broadcasting to help establish local topology.

Response

• Topology of requester
• Message
• Signature (signed with public key)
  • Hash of message

Dynamic Response

Request

• Topology of requester
• Public key of content-owner
• Encrypted (with recipient public key) message
  • Request-data
  • Signature (of requester)
    • Hash of request-data
• Optional: topology of recipient

Routing

The message is routed to a server that can answer on behalf of the requested public key. Again, the topology can be modified along the way if a better topology is found. Nodes also have the option of attaching a processing time before re-broadcasting to help establish local topology.

Topology

This will be very complex (and I need to research it more) but every node knows their immediate surroundings with reasonable accuracy. When a node enters the network it identifies itself (sends a list of public keys) to all its neighbors. The neighbors respond with a list of public keys and the latency to get to them (any public keys they hold will be marked 0).

To maintain network topology, nodes will occasionally ping each other. To keep chatter down, this should be done minimally.

Broadcast Identity

• List of public keys (that this server holds the private key to)
• Protocol

Identity Response

• Dictionary of public keys and latency
• Optional: protocol (if requesting different)

Ping

• One byte
• Optional: perceived latency

Ping Response

• Return sent
• Optional: Delay request
• Optional: Do not send latency
• Optional (Only ONE of the following):
  • Return ping (also one byte)
  • Retry request (if server was busy and ping time may not be accurate)

Phases

1: Nodes

Get a design out for a simple bridge node. This lets devices on the local network connect to the mesh and use the internet as a bridge. These nodes can also be used as servers. Hopefully, we can create a design using cheap hardware like the RasPi.

2: Point-to-Point

Again, the hope is to use cheap hardware. But this time, it's for longer distance, narrow beam communications. Something like off the shelf laser diodes pointed at each other over a few miles (I have no idea what realistic distances would actually be). At this stage, the network could start to be useful, at least in more populated areas. Just a few people connecting with point-to-point and running servers would give people access to resources without utilizing traditional network hierarchies.