Peer-to-peer skildrar korleis applikasjonspakkar reiser, og ikkje noko meir. Peera måtte framleis finne kvarandre, prove kven dei er og stundom falle tilbake på ein relay når ein direkte bane ikkje kunne byggjast. Det er tre separate tenester, og ei utrulling kan vere peer-to-peer for data medan ho er fullstendig sentralisert for alt anna. Å samanlikne design betyr å samanlikne dei oppgåvene, ikkje pila på diagrammet.

Eit diagram utan ei sentral videresendingspil kan skjule ein påmeldingsstyresmakt, ein oppdagingsteneste og ein relay, som alle er operative avhengnader.

Direkte bane, delt kontrollplan

To maskinar som utvekslar pakkar direkte kan framleis avhenge av ei felles styresmakt som utferda sertifikata deira, og av ei teneste som fortalde kvar av dei kvar den andre held til. Ingen av rollene videresender applikasjonstrafikk, og difor lèt topologiteikninga dei ute. Når den styresmakta eller tenesta er nede, kan eksisterande økter halde fram medan ein ny peer ikkje kan bli med. Skilnaden mellom å starte ei økt og å halde henne fram er det første spørsmålet å stille til eitkvart design.

Teikn kvar oppgåve separat sjølv når ein einaste vert utfører alle. Elles viser teikninga eit desentralisert dataplan og skjuler den operative røyda at kvar ny peer treng dei same to tenestene.

Oppdaging, tillit og relay er tre oppgåver

Designet til Nebula er eit nyttig døme fordi dokumentasjonen held dei frå kvarandre. Vertar ber sertifikat for identitet, fyrtårn svarar på kvar-er-spørsmålet og hjelper med NAT-traversering, og relayar videresender trafikk når ein direkte bane ikkje kan etablerast. Relayrolla er medvite skild frå fyrtårnsrolla, så eit tilgjengeleg fyrtårn lovar ikkje at eit gjeve par kan snakke saman. Andre produkt dreg grensene andre stader, og difor er dette eit døme og ikkje ein mal.

For ei føreslått utrulling, skriv ned den støtta fallbacken for eit par som ikkje kan kople til direkte. Ein mislukka hole-punch er eitt datapunkt om eitt nettverk, ikkje eit prov på at to NAT-peers aldri kan møtast; den motsette påstanden, at direkte tilkopling verkar under vilkårleg policy, er like uunderbygd.

Kva kvar avhengnad feilar på

Vurder fire tilfelle kvar for seg medan avhengnaden som blir testa er utilgjengeleg: eksisterande peertrafikk, ei heilt ny peer-tilkopling, ein peer der endepunktet er endra, og tilgang som nettopp er trekt tilbake. Kvart tilfelle byggjer på ulike tenester og feilar ulikt. Eksisterande økter kan overleve eit oppdagingsutfall medan ein tilbaketrekt nøkkel framleis blir avvist, og ein ny peer kan feile av grunnar som ikkje har noko med videresending å gjere. Test dei individuelt i staden for å konkludere frå eitt tilfelle.

Ei tilkopling som overlever eitt einskilt utfall etablerer ikkje ubegrensa sjølvstende. Ho etablerer at utfallet du årsaka ikkje var det som bryt den banen, noko som framleis er nyttig informasjon så sant du skreiv ned kva du årsaka.

Spør kva utfall du kan overleve

Krav som høyrest like ut fører til ulike design. Å unngå ein einaste videresendingsflaskehals er ikkje det same som å unngå eit leverandørhosta kontrollplan, og ingen av dei svarar til å halde drifta i gang medan ein koordinator er nede. Namngje kva av dei tre utrullinga må oppfylle, og kontroller deretter mappinga. Eit design som oppfyller det første og feilar det andre er vanleg og ikkje uærleg, så lenge ingen kallar det fullt desentralisert.

Skriv ned kven som driv oppdaging, tillit og relayar, og korleis kvar av dei blir erstatta. Den registreringa er det som lèt den neste personen svare på eit reelt spørsmål: kva feil overlever dette nettverket, og kven vedlikeheld tilstanden som blir verande delt?

Ordet desentralisert fortener plassen sin når det namngjev dei feila. Utan den lista skildrar det eit diagram i staden for eit system.

Relaterte artiklar