Peer-to-peer-VPN-er har fortsatt sentrale avhengigheter

Peer-to-peer beskriver hvordan applikasjonspakker reiser, og ingenting mer. Peerne måtte fortsatt finne hverandre, bevise hvem de er og noen ganger falle tilbake på en relay når en direkte bane ikke kunne bygges. Det er tre separate tjenester, og en utrulling kan være peer-to-peer for data mens den er fullstendig sentralisert for alt annet. Å sammenligne design betyr å sammenligne de oppgavene, ikke pilen på diagrammet.

Et diagram uten en sentral videresendingspil kan skjule en påmeldingsmyndighet, en oppdagelsestjeneste og en relay, som alle er operative avhengigheter.

Direkte bane, delt kontrollplan

To maskiner som utveksler pakker direkte kan fortsatt avhenge av en felles myndighet som utstedte sertifikatene deres, og av en tjeneste som fortalte hver av dem hvor den andre befinner seg. Ingen av rollene videresender applikasjonstrafikk, og derfor utelater topologitegningen dem. Når den myndigheten eller tjenesten er nede, kan eksisterende økter fortsette mens en ny peer ikke kan bli med. Forskjellen mellom å starte en økt og å fortsette den er det første spørsmålet å stille til ethvert design.

Tegn hver oppgave separat selv når én enkelt vert utfører dem alle. Ellers viser tegningen et desentralisert dataplan og skjuler den operative virkeligheten at hver ny peer trenger de samme to tjenestene.

Oppdagelse, tillit og relay er tre oppgaver

Nebulas design er et nyttig eksempel fordi dokumentasjonen holder dem fra hverandre. Verter bærer sertifikater for identitet, fyrtårn svarer på hvor-er-spørsmålet og hjelper med NAT-traversering, og relay-er videresender trafikk når en direkte bane ikke kan etableres. Relay-rollen er bevisst atskilt fra fyrtårnsrollen, så et tilgjengelig fyrtårn lover ikke at et gitt par kan snakke sammen. Andre produkter trekker grensene andre steder, og derfor er dette et eksempel og ikke en mal.

For en foreslått utrulling, skriv ned den støttede fallbacken for et par som ikke kan koble til direkte. En mislykket hole-punch er ett datapunkt om ett nettverk, ikke et bevis på at to NAT-peers aldri kan møtes; den motsatte påstanden, at direkte tilkobling fungerer under vilkårlig policy, er like uunderbygget.

Hva hver avhengighet feiler på

Vurder fire tilfeller hver for seg mens avhengigheten som testes er utilgjengelig: eksisterende peertrafikk, en helt ny peer-tilkobling, en peer der endepunktet er endret, og tilgang som nettopp er tilbakekalt. Hvert tilfelle bygger på ulike tjenester og feiler ulikt. Eksisterende økter kan overleve et oppdagelsesutfall mens en tilbakekalt nøkkel fortsatt avvises, og en ny peer kan feile av grunner som ikke har noe med videresending å gjøre. Test dem individuelt i stedet for å konkludere fra ett tilfelle.

En tilkobling som overlever ett enkelt utfall etablerer ikke ubegrenset uavhengighet. Den etablerer at utfallet du forårsaket ikke var det som bryter den banen, noe som fortsatt er nyttig informasjon forutsatt at du skrev ned hva du forårsaket.

Spør hvilket utfall du kan overleve

Krav som høres like ut fører til ulike design. Å unngå én enkelt videresendingsflaskehals er ikke det samme som å unngå et leverandørhostet kontrollplan, og ingen av dem tilsvarer å fortsette driften mens en koordinator er nede. Navngi hvilket av de tre utrullingen må oppfylle, og kontroller deretter mappingen. Et design som oppfyller det første og feiler det andre er vanlig og ikke uærlig, så lenge ingen kaller det fullt desentralisert.

Skriv ned hvem som driver oppdagelse, tillit og relay-er, og hvordan hver av dem erstattes. Den registreringen er det som lar neste person svare på et reelt spørsmål: hvilke feil overlever dette nettverket, og hvem vedlikeholder tilstanden som forblir delt?

Ordet desentralisert fortjener plassen sin når det navngir de feilene. Uten den listen beskriver det et diagram i stedet for et system.