Git-Mirrors/veilid-dot-com
1
0
Fork 0
mirror of https://gitlab.com/veilid/veilid-dot-com.git synced 2024-10-01 01:05:53 -04:00
Code Issues Packages Projects Releases Wiki Activity
1ed2142524
veilid-dot-com/pages/docs/networking.md
Alice Rhodes 604f55ccec Reorganizing pages 
- framework pages are now under docs
- removed pages that just dupe repo content
- made the code repositories pages the download page
- docs home page advertising the documentation work push
2023-08-23 12:24:30 -04:00

2.9 KiB
Raw Blame History

title description weight layout
Networking An overview of the networking used in Veilid 22 subpage

All devices are welcome and treated fairly.

You can use the public Veilid Network or build your own.

Nodes help each other like mutual aid for connectivity

All Veilid applications running veilid-core are 'nodes', and they are all equal in the eyes of the network. No nodes are 'special'.

Nodes are only limited by the resources they bring and the configuration of the network they are on.

DNS is only used one time during ‘bootstrap'; it is not required though.

SSL is optional and only for HTTPS Websockets for Veilid Webapps.

Protocols

Veilid uses UDP, TCP, and Websockets.

Low level protocols supported by Veilid are kept simple, to minimize complications. Everything uses framed RPC operations up to 64KB in size. Protocol support is extensible and may add WebRTC and other specialized protocols in the future.

Network Topology

A topology graph for Veilid networks

To zoom in on the details, view the full size image directly.

Bootstrapping

Bootstrap nodes not 'special' nodes. Any node can bootstrap a Veilid network. Networks can be 'keyed' to keep nodes off that don't have the key. You can join the ‘big Veilid network' or make your own isolated network.

  • Ask Bootstraps To ‘Find Self'

    A single initial DNS TXT record request returns some bootstrap nodes that are known to exist. Those are asked to return nodes that are ‘close' to your own node.

  • Public Address Detection

    Nodes are often behind various forms of NAT. Validating one's own public ‘Dial Info' is essential for publishing one's Node Info and answering Find Node requests.

  • Relay Configuration

    Low-capability network classes may require the use of Inbound or Outbound relays in order to achieve reachability Nodes help each other out to the best of their ability and incur no penalty for not being able to assist other nodes.

  • Peer Minimum Refresh

    Nodes in your routing table are asked to return nodes that are near you as well. Finding nodes close to your own is always harder than finding nodes far away, so we focus on that with our requests.

  • Network Class Detection

    Determining NAT type and what mechanisms can be used to achieve connectivity. Direct connection techniques like reverse connections and UDP hole punching may be inappropriate for some network classes.

  • Ping Validation

    Nodes come and go, change address, and are unreliable. Checking routing table nodes for proof-of-life is done with exponential backoff. Nodes are removed from the routing table on a LIFO basis.