Mesh Network - Revision history

Adamcolton at 21:58, 20 January 2014

2014-01-20T21:58:49Z

← Older revision		Revision as of 21:58, 20 January 2014
Line 3:		Line 3:
	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.		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==		== Static Broadcast Request ==
	===Request===		=== Request ===
	*Topology of requester		*Topology of requester
	*Public key of content-owner		*Public key of content-owner
Line 10:		Line 10:
	*Optional: topology of resource		*Optional: topology of resource

	===Routing===		=== 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.		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===		=== Response ===
	*Topology of requester		*Topology of requester
	*Message		*Message
Line 19:		Line 19:
	**Hash of message		**Hash of message

	==Dynamic Response==		== Dynamic Response ==
	===Request===		=== Request ===
	*Topology of requester		*Topology of requester
	*Public key of content-owner		*Public key of content-owner
Line 29:		Line 29:
	*Optional: topology of recipient		*Optional: topology of recipient

	===Routing===		=== 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.		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==		== 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).		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.		To maintain network topology, nodes will occasionally ping each other. To keep chatter down, this should be done minimally.

	===Broadcast Identity===		=== Broadcast Identity ===
	*List of public keys (that this server holds the private key to)		*List of public keys (that this server holds the private key to)
	*Protocol		*Protocol

	===Identity Response===		=== Identity Response ===
	*Dictionary of public keys and latency		*Dictionary of public keys and latency
	*Optional: protocol (if requesting different)		*Optional: protocol (if requesting different)

	===Ping===		=== Ping ===
	*One byte		*One byte
	*Optional: perceived latency		*Optional: perceived latency

	===Ping Response===		=== Ping Response ===
	*Return sent		*Return sent
	*Optional: Delay request		*Optional: Delay request
Line 57:		Line 57:
	**Retry request (if server was busy and ping time may not be accurate)		**Retry request (if server was busy and ping time may not be accurate)

			== Econ ==
			This gets really complex. I'm not sure how to actually achieve it.

			While maintaining the self-organizing nature of the network, nodes also need to be in competition. Devices automatically choose a route based on speed, cost and reliability. Every node utilized along the way gets a cut.

			This of course brings in all sorts of complications. There needs to be a pseudonym and reputation system. There needs to be a way for user to build and collect tabs. Or, alternatively, there needs to be an entirely new way to think about both networks and wealth.
	== Phases ==		== Phases ==
	=== 1: Nodes ===		=== 1: Nodes ===

Adamcolton: /* Phases */

2014-01-20T21:53:24Z

Phases

← Older revision		Revision as of 21:53, 20 January 2014
Line 63:		Line 63:
	=== 2: Point-to-Point ===		=== 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.		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.

			=== 3: Growth ===
			As individuals on the periphery find the network useful, adoption should spread. I hope that the draw of earning money from running nodes as well as having access on an a-la-carte basis should bring people in. In this phase there should start to be connections between nearby cities and efficient bridges (people or organizations with access to high bandwidth internet).

			=== 4: Replacement ===
			At a certain point, individuals should start to feel comfortable without a traditional wire. Reverse bridges (connecting to the traditional network through the mesh) should start to arise. Somewhere around this time we should see a tipping point.

	[[Category:Unsorted]]		[[Category:Unsorted]]

Adamcolton: /* = 1: Nodes */

2014-01-20T21:48:45Z

= 1: Nodes

← Older revision		Revision as of 21:48, 20 January 2014
Line 58:		Line 58:

	== Phases ==		== Phases ==
	=== 1: Nodes ==		=== 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.		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.

Adamcolton at 21:47, 20 January 2014

2014-01-20T21:47:52Z

← Older revision		Revision as of 21:47, 20 January 2014
Line 56:		Line 56:
	**Return ping (also one byte)		**Return ping (also one byte)
	**Retry request (if server was busy and ping time may not be accurate)		**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.

	[[Category:Unsorted]]		[[Category:Unsorted]]

Adamcolton at 20:18, 15 February 2013

2013-02-15T20:18:30Z

← Older revision		Revision as of 20:18, 15 February 2013
Line 57:		Line 57:
	**Retry request (if server was busy and ping time may not be accurate)		**Retry request (if server was busy and ping time may not be accurate)

	[[Category:~~Half-Baked~~]]		[[Category:Unsorted]]

Adamcolton: Created page with "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 ..."

2012-11-20T16:58:56Z

Created page with "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 ..."

New page

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)

[[Category:Half-Baked]]