1
0
mirror of https://github.com/matrix-org/pinecone.git synced 2026-10-24 11:59:18 +03:00
Files
pinecone/docs/introduction.md
Neil Alexander 1ce778fcde Soft-SNEK (#43)
* Initial soft-state testing

* Fix `pineconeip`

* Try raising the intervals a bit

* Tighter expiry

* Tweaks

* Try to speed up convergence but reduce idle noise

* More tweaks

* Handle disconnections on destination ports, tweak next-hops

* All traffic is either bootstrap or not, more tweaking

* Protocol calming, loop detection, bootstrap signatures

* Tidy up sim

* Fix unit test

* Don't drop pong responses as looping traffic

* Remove unused snake path id

* Remove unused variable from nextHopsSNEK

* Unassign setup acks capability from soft state capabilites

* Cleanup comments to reflect new softstate logic

* Remove unused candidate variable from state

* Update sim and events to reflect softstate changes

* Update wireshark dissector to match softstate frames

* Add unit test for snake bootstrap

* Fix incorrect comment about bootstrap forwarding conditions

* Add `queue` interface

* Initial docs update for softstate algorithm

* Softstate doc updates

* Fix logic for selecting lowest latency links

* Update docs with watermark information (#52)

* Update docs with watermark information

* Further clarifications to watermark docs

* Fix `pinecone.lua`

Co-authored-by: Devon Hudson <devonhudson@librem.one>
2022-07-08 14:52:11 +01:00

2.9 KiB

title, has_children, nav_order, permalink
title has_children nav_order permalink
Introduction true 1 /introduction

Introduction

Pinecone is an implemenatation of the Sequentially Networked Edwards Key (SNEK) name-independent routing scheme that combines two network topologies in order to build an efficient and scalable overlay network.

Pinecone is:

  • Name-independent:

    • Node identifiers are not related to the physical network topology;
    • They do not change as the node moves around the network;
    • The address space is considered to be global — there is no subnetting;
  • Built up of equal players:

    • Nodes will forward traffic on behalf of other nodes;
    • There are no specific points of centralisation;
    • A node can join a larger network by connecting to any other node;
  • Self-healing:

    • Tolerates node mobility far better than Batman-adv, Babel and many other routing protocols;
    • Alternative paths will be discovered automatically if possible when nodes go offline or connections are lost.
  • Transport-agnostic:

    • The only requirements for a peering today are that it is stream-oriented and reliable;
    • Any connection medium that can offer these semantics is appropriate for a peering, including TCP over regular IP networks, WebSockets, Bluetooth L2CAP (with infinite retransmit) or RFCOMM etc.

Note, however, that Pinecone is:

  • Not anonymous:

    • Anonymity networks make significant trade-offs in order to achieve anonymity, both in overall complexity and in path/routing cost, which are unacceptable in resource-constrained environments;
    • It is not a goal of the Matrix project to guarantee anonymity — at best Matrix can provide pseudonymity and the same is true with Pinecone public keys;
  • Not strongly resistant to traffic analysis:

    • Although traffic packet contents will be encrypted end-to-end by default, the source and destination fields in the packet headers are visible to intermediate nodes;
    • In some cases, source addresses could be sealed/encrypted, although this is not implemented today;
  • Not fully resilient against malicious nodes:

    • If a node peers with malicious nodes which (for instance) drop traffic, then connectivity will inevitably be disrupted. This can never be fully mitigated (for instance, if you are in a 2 node network and the other node is malicious, there is nothing you can do) — but work is ongoing to detect and route around malicious behaviour where possible.

The Pinecone routing scheme effectively is built up of two major components:

  • A global spanning tree:

    • Provides efficient, low-stretch and strictly loop-free routing;
    • Effective means of exchanging path setup messages, even before SNEK bootstrap has taken place;
  • A virtual snake (or SNEK) — a single-linked linear routing topology:

    • Provides resilient public key-based routing across the overlay network.