Peer-to-peer popisuje, jak cestují pakety aplikací, a nic víc. Partneři se stále museli najít, prokázat, kdo jsou, a někdy se uchýlit k relay, když nešlo postavit přímou cestu. Jsou to tři samostatné služby a nasazení může být peer-to-peer pro data, zatímco pro všechno ostatní je zcela centralizované. Porovnávat návrhy znamená porovnávat tyto úlohy, ne šipku na diagramu.

Diagram bez centrální šipky předávání může skrývat registrační autoritu, vyhledávací službu a relay, což jsou všechny provozní závislosti.

Přímá cesta, sdílená řídicí rovina

Dva počítače, které si přímo vyměňují pakety, mohou stále záviset na společné autoritě, která vydala jejich certifikáty, a na službě, která každému řekla, kde je ten druhý. Ani jedna z obou rolí nepředává provoz aplikací, a proto je výkres topologie vynechává. Když je tato autorita nebo služba nedostupná, existující relace mohou pokračovat, zatímco nový partner se nemůže připojit. Rozdíl mezi zahájením relace a jejím pokračováním je první otázka, kterou je třeba položit každému návrhu.

Nakreslete každou úlohu zvlášť, i když je všechny vykonává jeden hostitel. Jinak výkres ukazuje decentralizovanou datovou rovinu a skrývá provozní realitu, že každý nový partner potřebuje stejné dvě služby.

Vyhledávání, důvěra a relay jsou tři úlohy

Návrh Nebula je užitečný příklad, protože jeho dokumentace je drží oddělené. Hostitelé nesou certifikáty pro identitu, majáky odpovídají na otázku kde a pomáhají s průchodem NAT, a relay předávají provoz, když nelze navázat přímou cestu. Role relay je záměrně odlišná od role majáku, takže dostupný maják neslibuje, že daná dvojice spolu může mluvit. Jiné produkty kreslí hranice jinde, a proto je to příklad, nikoli šablona.

U navrhovaného nasazení zapište podporovanou záložní cestu pro dvojici, která se nemůže připojit přímo. Neúspěšné proražení díry je jeden datový bod o jedné síti, nikoli důkaz, že se dva partneři za NAT nikdy nemohou setkat; opačné tvrzení, že přímé spojení funguje za jakékoli politiky, je stejně nepodložené.

Na čem každá závislost selhává

Vyhodnoťte čtyři případy odděleně, zatímco testovaná závislost není dostupná: stávající provoz mezi partnery, zcela nové partnerské spojení, partner, jehož koncový bod se změnil, a přístup, který byl právě odvolán. Každý se opírá o jiné služby a selhává jinak. Stávající relace mohou přežít výpadek vyhledávání, zatímco odvolaný klíč je stále odmítán, a nový partner může selhat z důvodů, které nemají nic společného s předáváním. Testujte je jednotlivě, místo abyste usuzovali z jednoho.

Spojení, které přežije jediný výpadek, neprokazuje neomezenou nezávislost. Prokazuje, že výpadek, který jste způsobili, nebyl ten, který tuto cestu přerušuje, což je stále užitečná informace, pokud jste si zapsali, co jste způsobili.

Zeptejte se, který výpadek přežijete

Požadavky, které znějí podobně, vedou k různým návrhům. Vyhnout se jedinému úzkému místu v předávání není totéž jako vyhnout se řídicí rovině hostované dodavatelem, a ani jedno neodpovídá pokračování provozu, když je koordinátor nedostupný. Pojmenujte, který z těch tří musí nasazení splnit, a pak zkontrolujte mapování. Návrh, který splňuje první a selhává ve druhém, je běžný a není nečestný, dokud ho nikdo nenazývá plně decentralizovaným.

Zapište, kdo provozuje vyhledávání, důvěru a relay a jak je každý z nich nahrazen. Právě tento záznam umožňuje dalšímu člověku odpovědět na skutečnou otázku: které poruchy tato síť přežije a kdo udržuje stav, který zůstává sdílený?

Slovo decentralizovaný si zaslouží své místo, když tyto poruchy pojmenuje. Bez tohoto seznamu popisuje diagram, nikoli systém.

Související články