Supernodes: Difference between revisions

From Bay Area Mesh
Jump to navigation Jump to search
No edit summary
No edit summary
Line 14: Line 14:
 
* KN6PLV-BAM-SUPERNODE
 
* KN6PLV-BAM-SUPERNODE
   
=== Oklahoma City Mesh ===
+
=== [[Oklahoma City Mesh]] ===
   
 
* KI5VMF-CLOUD-TUNNEL-SUPERNODE
 
* KI5VMF-CLOUD-TUNNEL-SUPERNODE
   
=== Southern California Mesh ===
+
=== [[Southern California Mesh]] ===
   
 
* W6BI-BACKBONE-NODE (pending)
 
* W6BI-BACKBONE-NODE (pending)
  +
  +
=== [[Willamette Valley Mesh]] ===
  +
  +
* (pending)
   
 
== Alternate Approach ==
 
== Alternate Approach ==

Revision as of 22:16, 20 August 2023

Supernodes are a mechanism to connect multiple meshes together, without just making one giant mesh. The original proposal can be found here.

The Basic Idea

Essential Supernodes.png

The basic idea behind a supernode connected mesh, is that each mesh is it's own self contained "zone", but these zones can communicate with each other by routing inter-zone traffic through a set of supernodes. Supernodes know about all the nodes in all the meshes and take care of routing traffic to where it needs to go, without burdening your average mesh node with this information.

Maps of Connected Meshes

arednmap.xojs.org

Current Supernodes

Bay Area Mesh

  • KN6PLV-BAM-SUPERNODE

Oklahoma City Mesh

  • KI5VMF-CLOUD-TUNNEL-SUPERNODE

Southern California Mesh

  • W6BI-BACKBONE-NODE (pending)

Willamette Valley Mesh

  • (pending)

Alternate Approach

Mark Herson N2HM has been operating an alternate supernode approach since 2016. He uses a Hub node which connects to many other meshes, but doesnt share any of the connected meshes data between each other. It's possible the browse these connected meshes by using a web proxy pointing at this hub.

It is not currently possible for one mesh node to connect directly to a node on another mesh. Redundant hubs are not currently provided.