Admin: 1 revision imported

2022-11-09T14:49:53Z

1 revision imported

← Older revision	Revision as of 16:49, 9 November 2022
(No difference)

Admin at 02:49, 4 December 2010

2010-12-04T02:49:24Z

New page

=== Design decisions ===
# Route discovery on demand, instead of route announcements
# Explicit per packet, source specified route
# End to end NaCl encryption
# Loop detection based on NaCl public keys
# Supports many different types of addresses and protocols, including IPv4 and IPv6

=== Other features ===
* Cheap source specified routing (just one byte per hop)
* Optional load balancing over multiple routes (will also reduce the impact of a failing route)
* Broken routes are not detected, and thus not used (the discovery has to travel the entire path in both directions)
* Allows for meshes of any form to be built
* No "broadcast" traffic resulting from route announcements
* No more ghost routes
* Actual network topology is mostly hidden from anybody in the network
* Individual IP addresses are authenticated using NaCl public key cryptography

=== Limitations ===
* Maximum of 255 hops
* Need for broadcasts for route discovery
* Discovery packets are rather large
* Data broadcast packets tend to get rather large because of the key based loop detection

=== Protocol spec (alpha version) ===

P2P cloud protocol

* After a Resource Discovery, the IP address and remote private key are cached
* During renewals, the lookup targets the remote private key, the IP address is not queried again
* If multiple private keys announce the same IP address, the IP address should be blocked, until administrator intervention has occured
* Data packets may be encrypted end-to-end (recommended)
* Resource and path discovery packets have a small encrypted data field to verify authenticy of the key
* All packets may be encrypted between peers, but this is not required
* Resource lookups include IPv4 addresses, IPv6 addresses, IPX addresses, and other resources for which recurring communications are useful
* Actual data packets are routed as specified by the originator.

Routes are specified using local peer ID numbers, these consist of 1 octet per peer, and are meaningful only to a specific node
* It's meaning is comparable to a port number on an ethernet switch
* A local peer ID must be unique within the context of one node
* A local peer ID should not be reused for another peer within a certain time interval
* A local peer may have multiple local peer IDs to hide the network topology
* A node may insert artificial peer IDs to hide the network topology, but this must be done sparingly!
* A node may insert additional peer IDs, if it has more than 255 peers, it can simply use two octets as a 16 bit integer, and pretend to be 2 nodes
* Route specifications for a certain path are usually different in both directions!
* The source of a route lookup may add a one or two octet session identifier, that it associates with the remote public key

Packet type
# Resource discovery - origin resource, destination resource, trace, keys
# Route discovery - key, trace, keys
# Route confirmation - route, trace
# Route ping - route, trace, data
# Route pong - route, data
# Data - route, data
# Broadcast data - destination resource, keys

Packet contents
* Flags / Type - Packet type code
* Origin resource (type, value) - Resource that originated a resource discovery
* Destination resource (type, value)- The resource to discover
* Key - The key to discover, or the key that was discovered in a resource discovery
* Route (length, values) - list of peer IDs (bytes), which specifies the intended route
* Trace (length, values) - list of peer IDs (bytes), which specifies the traced route (in a trace/discovery request)
* Keys (count, values) - list of unique keys to prevent loops (in broadcasts)
* Data

Initializing communication with another node consists of a few steps:
# Path discovery, either:
## Resource discovery - if the remote public key is not known
## Path discovery - if the remote public key is known
# Reverse path confirmation
* Both ends cache the discovered paths, and should regularly verify the known paths (PING).
* Either end may at any time request a new path discovery, if it has insufficient routes, or simply to detect possibly faster/better paths.

Resource discovery
# The initiator broadcasts a 'Resource discovery' packet to all it's peers
#* Type = resource discovery
#* Optional: Origin resource = initiator resource
#* Destination resource = resource to locate
#* Route = [ initiator session ID ]
#* Keys = [ initiator public key ]
# On reception, a node checks whether it serves the requested resource
## If so:
### It creates a session for the initiator public key (if it does not already exist)
### It adds the traced route to the list of routes for that session
### It sends a Reverse path confirmation via the traced route:
###* Type = route confirmation
###* Origin resource = located resource
###* Key = located public key
###* Route = [ local session ID ]
## If not:
### It checks whether it's key is listed in the Keys field, if so, the packet is discarded
### If the Route field has reached 255 entries, the packet is discarded
### It adds the local peer ID of the sending peer to the Route, and it's local key to Keys
### It broadcasts the packet to all of it's peers (except the sending peer)
### Step 2 repeats

Path discovery
* This is used when looking for a public key.
* After a resource discovery, the located public key should be cached, and can be re-used in a path discovery.
* The procedure is very similar to the Resource discovery

== Alternative less promiscuous protocol ==
A sends to X:
A sends discovery to peers B and C, hopcount=1
B sends discovery to C and D, hopcount = 2
C sends discovery to B and D, hopcount = 2
C ignores discovery from B (higher hopcount)
B ignores discovery from C (higher hopcount)
D sends discovery to X (hopcount=3)
D ignores second discovery (time out)
X answers D (hopcount=1, return=4)
D answers B (hopcount=2, return=4), request from B arrived first with equal hopcount
B answers A (hopcount=3, return=4), request from A arrived with lowest hopcount

Peer2Cloud - Revision history

Admin: 1 revision imported

Admin at 02:49, 4 December 2010