Peer-to-peer opisuje, ako cestujú pakety aplikácií, a nič viac. Partneri sa stále museli nájsť, preukázať, kým sú, a niekedy sa uchýliť k relay, keď sa nedala postaviť priama cesta. Sú to tri samostatné služby a nasadenie môže byť peer-to-peer pre dáta, zatiaľ čo pre všetko ostatné je úplne centralizované. Porovnávať návrhy znamená porovnávať tieto úlohy, nie šípku na diagrame.

Diagram bez centrálnej šípky preposielania môže skrývať registračnú autoritu, vyhľadávaciu službu a relay, ktoré sú všetky prevádzkové závislosti.

Priama cesta, zdieľaná riadiaca rovina

Dva počítače, ktoré si priamo vymieňajú pakety, môžu stále závisieť od spoločnej autority, ktorá vydala ich certifikáty, a od služby, ktorá každému povedala, kde je ten druhý. Ani jedna z dvoch rolí nepreposiela prevádzku aplikácií, a preto ich výkres topológie vynecháva. Keď je táto autorita alebo služba nedostupná, existujúce relácie môžu pokračovať, zatiaľ čo nový partner sa nemôže pripojiť. Rozdiel medzi začatím relácie a jej pokračovaním je prvá otázka, ktorú treba položiť každému návrhu.

Nakreslite každú úlohu zvlášť, aj keď ich všetky vykonáva jeden hostiteľ. Inak výkres ukazuje decentralizovanú dátovú rovinu a skrýva prevádzkovú realitu, že každý nový partner potrebuje tie isté dve služby.

Vyhľadávanie, dôvera a relay sú tri úlohy

Návrh Nebula je užitočný príklad, pretože jeho dokumentácia ich drží oddelene. Hostitelia nesú certifikáty pre identitu, majáky odpovedajú na otázku kde a pomáhajú s prechodom NAT, a relay preposielajú prevádzku, keď nemožno nadviazať priamu cestu. Rola relay je zámerne odlišná od roly majáka, takže dostupný maják nesľubuje, že daná dvojica spolu môže hovoriť. Iné produkty kreslia hranice inde, a preto je to príklad, nie šablóna.

Pri navrhovanom nasadení zapíšte podporovanú záložnú cestu pre dvojicu, ktorá sa nemôže pripojiť priamo. Neúspešné prerazenie diery je jeden dátový bod o jednej sieti, nie dôkaz, že sa dvaja partneri za NAT nikdy nemôžu stretnúť; opačné tvrdenie, že priame spojenie funguje za akejkoľvek politiky, je rovnako nepodložené.

Na čom každá závislosť zlyháva

Vyhodnoťte štyri prípady oddelene, zatiaľ čo testovaná závislosť nie je dostupná: existujúca prevádzka medzi partnermi, úplne nové partnerské spojenie, partner, ktorého koncový bod sa zmenil, a prístup, ktorý bol práve odvolaný. Každý sa opiera o iné služby a zlyháva inak. Existujúce relácie môžu prežiť výpadok vyhľadávania, zatiaľ čo odvolaný kľúč je stále odmietaný, a nový partner môže zlyhať z dôvodov, ktoré nemajú nič spoločné s preposielaním. Testujte ich jednotlivo, namiesto toho, aby ste usudzovali z jedného.

Spojenie, ktoré prežije jediný výpadok, nepreukazuje neobmedzenú nezávislosť. Preukazuje, že výpadok, ktorý ste spôsobili, nebol ten, ktorý túto cestu prerušuje, čo je stále užitočná informácia, ak ste si zapísali, čo ste spôsobili.

Opýtajte sa, ktorý výpadok prežijete

Požiadavky, ktoré znejú podobne, vedú k rôznym návrhom. Vyhnúť sa jedinému úzkemu miestu v preposielaní nie je to isté ako vyhnúť sa riadiacej rovine hostovanej dodávateľom, a ani jedno nezodpovedá pokračovaniu prevádzky, keď je koordinátor nedostupný. Pomenujte, ktorý z tých troch musí nasadenie splniť, a potom skontrolujte mapovanie. Návrh, ktorý splní prvý a zlyhá v druhom, je bežný a nie je nečestný, pokiaľ ho nikto nenazýva plne decentralizovaným.

Zapíšte, kto prevádzkuje vyhľadávanie, dôveru a relay a ako je každý z nich nahradený. Práve tento záznam umožňuje ďalšiemu človeku odpovedať na skutočnú otázku: ktoré poruchy táto sieť prežije a kto udržiava stav, ktorý zostáva zdieľaný?

Slovo decentralizovaný si zaslúži svoje miesto, keď tieto poruchy pomenuje. Bez tohto zoznamu opisuje diagram, nie systém.

Súvisiace články