Peer-to-peer: nytt og nyttig eller gammelt og galt?

Det nye ropet har vel alle fått med seg: "Peer-to-peer er det nye store for Internett".

Trykket i Nettverk & Kommunikasjon nr.4/2001
(c) Anders Fongen 2001
Artikkelen bygger på et foredrag holdt under IT-expo 26.04.2001. PowerPoint-presentasjonen fra foredraget finnes her.

Anders Fongen er høgskolelektor og fagsjef ved Den Polytekniske Høgskolen, og skriver sin doktoravhandling innenfor peer-to-peer-området. Web-stedet hans er på www.fongen.no.

Peer-to-peer-teknologi (p2p) innebærer at distribuerte applikasjoner ikke utføres i en tradisjonell klient-tjener-løsning (c/s), men ved at partene (klientene) kommuniserer direkte med hverandre og løser oppgavene gjennom et symmetrisk samarbeid. En definisjon av p2p bør inneholde disse to ordene: tjenerløs og symmetrisk.

P2p har vi hatt rundt oss ganske lenge. Er det noen som husker UUCP, en tjeneste for overføring av E-post og filer mellom Unix-maskiner (fantes for MS-DOS også), basert på vanlig oppringte telefonlinjer uten bruk av sentrale tjenere? Dette var før TCP/IP og lokalnett var vanlig, og tilbød de vanligste "wan"-tjeneste til grupper av maskiner som ikke hadde et wan tilgjengelig.

P2p handler ikke om bruksmønstre: Internet E-post er ikke p2p, selvom brukerne samhandler symmetrisk når de utveksler meldinger. Det er den underliggende arkitekturen som avgjør dette, og Internet E-post er en klient/tjener arkitektur (selv om E-post-tjenerne samhandler symmetrisk er det altså ikke p2p). Det samme gjelder E-konferanser og gruppevare.

Hva er det som er nytt?

Dersom p2p har vært kjent lenge, hva er det da som er nytt? Det nye siden UUCP sine dager er at det nå finnes hundervis av millioner PCer rundt om i verden, knyttet sammen gjennom et ganske brukbart transportnett, nemlig Internet. I 98% av tiden venter disse maskinene på noe å gjøre, og de har ofte mye ubrukt plass på disken. En del typer oppgaver med ekstremt stort plass- eller regnebehov kan med fordel deles opp i små biter, som utføres hver for seg på noen av disse maskinene. En del p2p-prosjekter følger nettopp denne tankegangen, og vi skal nevne to av dem:

SETI@home

(www.seti.org)
Et forskningsprosjekt som søker etter tegn til intelligent liv i verdensrommet bruker radioteleskoper for å samle inn radiosignaler utenfra og analyser dem for å finne mønstre i signalene. Dette krever mye mer regnekraft enn hva de har råd til, så de har laget en skjermsparer som laster ned en bit av de innsamlede dataene og analyserer dem for å finne eventuelle mønstre. Slik kan alle som ønsker å være med på "CPU-dugnaden" installere denne skjermspareren og sørge for at maskinen er tilkoplet Internet fra tid til annen. Analyseprogrammet kan laste ned rådata og laste opp de analyserte resultatene mens maskinen er tilkoplet Internet, mens selve regneoperasjonene kan utføres uten tilkopling.

Det finnes flere prosjekter som verver ledig CPU-kraft på denne måten, bl.a. innenfor kreftforskning. Mangelen på kommunikasjon mellom maskinene gjør at enkelte mener at dette strengt tatt ikke er p2p, men til gjengjeld er den enkle kommunikasjonsmodellen en fordel når et slikt prosjekt skal gjenomføres i stor skala.

Napster

(www.napster.com)
Et ganske kjent p2p-program er Napster, som lar alle dem som har musikkfiler (mp3) på sin egen disk dele dem med andre i en slags "disk-dugnad". Napster-programmet registrerer dine filer i en sentral katalog som er søkbar for alle. Om en annen søker i katalogen og finner dine filer, så setter han opp en forbindelse direkte til din maskin og overfører dataene. Katalogen ligger altså sentralt og søkes på c/s-manér, mens dataoverføringen skjer på p2p-manér. Kombinasjonen av disse to behandlingsmåtene er etter vår mening interessant, fordi de har hver sine fordeler og ulemper og kan med hell komplettere hverandre.

Gnutella

(www.gnutellanews.com)
Et annet program for disk-dugnad er Gnutella, som i motsetning til Napster ikke har noen form for sentral tjener, heller ikke til søkefunksjonen. Når du starter Gnutella-programmet vil det søke seg frem til andre Gnutella-programmer og danne et "spontant nettverk" sammen med dem. Søking i et Gnutella-nettverk skjer ved at søkeordet utbres til alle (eller flest mulig) av maskinene i nettverket, og alle dem som har data som passer til søkeordet returnerer opplysninger om det. Så kan den som søkte sette opp forbindelser til disse maskinene og overføre data.

Gnutella har et stort skaleringsproblem: Et søk genererer veldig mye nettverkstrafikk når det utbres på denne måten, og når mange brukere er inne i dette nettverket er det nesten uråd å få noe svar. Designet av Gnutella er ikke godt gjennomtenkt, også protokollene som brukes for å informere maskinene om hverandre er dårlig laget.

Anonymitet

Men en interessant side ved Gnutella er anonymitet, og spørsmålet om behovet for å lage programvare som skjuler kilden til informasjon. Noen ser for seg at en totalitær regjering lett kan overvåke alle borgere dersom all kommunikasjon foregår via web og e-mail, og at det derfor er nødvendig med slik programvare. Gnutella innretter seg slik når den videresender en søkeoperasjon at den ikke overfører søkerens adresse, men husker bare fra hvem den mottok dette spørreordet. Svaret som kommer i retur sendes videre bakover i denne kjeden og ender til slutt hos spørreren. Ingen enkeltmaskin har oversikt over denne kjeden av maskiner, og hver enkel maskin glemmer alt når først svaret er ekspedert. Det er derfor heller ingen logg som kan inspiseres i ettertid. Dette gjør det helt umulig å finne ut hvem som har spurt.

Om selve dataene (ikke bare opplysningene om at de finnes) skal overføres, skjer dette gjennom en direkte filoverføring (med ftp- eller http-protokoll), som jo både kan avlyttes og spores. Gnutella er derfor ikke komplett anonymisert.

Freenet

(freenet.sourceforge.net)
Freenet er bygget over en lignende tanke, at nettverket skal dannes spontant og at kun naboer skal vite om hverandre. Med Freenet knyttes et dataobjekt til en nøkkel, og dersom du søker med denne nøkkelen, kommer selve dataene til maskinen din, overført gjennom en kjede av maskiner hvor ingen kjenner begge endepunktene. En annen interessant side ved Freenet er at dataobjektene korttidslagres (caches) der de overføres, slik at lignende forespørsler "fra den kanten" kan besvares raskere. Dataene flytter seg med andre ord dit de trenges oftest.

Freenet er komplett anonymisert, og fremhever dette som en av hovedidéene ved designet. Og selv om vi også er tilhenger av ytringsfrihet, er vårt dilemma dette: Det er ikke kinesiske dissidenter som først tar slik programvare i bruk, men narkohaier, terrorister og barnepornografer. Dem som vi aller minst ønsker å hjelpe er altså de som først får hjelp. Hmmmm...

NetMeeting

Microsoft leverer et gratisprogram sammen med IE5 som er av typen "synkront samarbeidsverktøy". Det tilbyr chat-konferanser, audio- og video-samtaler, delt whiteboard, filoverføring og applikasjonsdeling. I likhet med Napster finner vi også her en sentral katalogfunksjon (basert på LDAP), mens dataoverføringen mellom partene skjer direkte på p2p-manér. Katalogregistreringen er utelukkende basert på brukerens egne opplysninger, og det er ikke helt enkelt å spore opp endepunktet til den du snakker med (du trenger en enkel nettverksanalysator el.lign).

NetMeeting tilbyr dermed også i stor grad anonymisert kommunikasjon, og en titt inn i katalogdataene bekrefter våre bange anelser: Her flommer det over av slibrige invitasjoner, og det forekommer åpenlys omsetning av barneporno.

Noen tekniske betraktninger over p2p

Når vi bygger en klient/tjener anvendelse, er det ofte med tanke på deling av informasjon. Denne informasjonen skal være tilgjengelig, sikret og gyldig. Tjeneren som lagrer informasjonen og tillater operasjoner på den får dermed flere oppgaver enn bare å kopiere informasjon til klientene: Tjeneren skal sørge for sikkerhetskopi, brukerautentisering, og fremfor alt transaksjoner. Transaksjoner innebærer at sammensatte operasjoner blir utført i en "alt-eller-ingenting" sammenheng, slik at ingen skal komme til å benytte data fra en halvveis utført operasjon. Støtte for transaksjoner krever et nøye samarbeid mellom maskinvaren, operativsystemet og evt. mellomvare, og i distribuerte miljøer beror transaksjoner på sentrale "dirigenter" kalt transaksjonsmonitorer. Uten sentrale tjenere er det vrient og upraktisk å få til transaksjoner, selv om det teoretisk sett er mulig.

Deling av data med p2p-teknologi støter på mange slags problemer som er vel forstått og forlengst løst i et c/s-miljø: Transaksjoner er vanskelig å få til, likeså er det vanskelig å vite hvem som skal ta backup av hva, hvem som skal ha "originalen" av et dokument og hvem som skal ha "kopier" osv.

Dessuten er ikke p2p-teknologi særlig god venn med brannvegger, som helt ser at tjenere står "på utsiden" og klienter "på innsiden". Asymmetriske aksessnett er noe lignende: De er laget med ulik overføringshastighet for sending og mottak av data, ut fra en betraktning om at en Internet-bruker mottar mer data enn han sender (sikkert riktig når det gjelder www).

Skaleringsproblemet

Når man bygger distribuerte løsninger tar man ofte høyde for at den kan inneholde et stort antall maskiner, og er derfor på jakt etter å identifisere flaskehalser som på ett eller annet stadium hindrer videre utvidelser. I tradisjonell c/s-arkitektur er dette nesten alltid tjeneren, fordi den får en arbeids- og overføringsmengde som er noenlunde proporsjonal med antall klienter i systemet.

Det er kanskje nærliggende å tro at vi fjerner flaskehalsen ved å fjerne tjeneren. Men om fraværet av en sentral tjener medfører at alle klientene må snakke sammen parvis, da har vi ikke spart noe som helst. Da får hver klient en arbeidsmengde proporsjonal med antall klienter, og den samlede overføringsmengden i nettet er blitt en kvadratisk funksjon av antall klienter. Altså: Vi sparer ingenting på å fjerne tjeneren med mindre klientene (nå partene, siden vi vil bruke p2p-terminologi) snakker sammen på en litt "smart" måte.

Sikkerhets- og pålitelighetsproblemet

En smart måte å la partene snakke sammen på, er ved å organisere dem slik at de kan videresende data for hverandre. Veien fra A til B kan da gå gjennom C, og veien til D likeså. Skal A sende data til både B og D, sendes én kopi til C, som sender to kopier videre. Dette kalles multicast og er godt kjent i nettverksteorien. Slikt er bra for skaleringen av systemet.

Problemet oppstår når C ikke er pålitelig: Dersom den krasjer i tide og utide har trafikken A-B og A-D problemer. Påliteligheten til en maskin er ikke lenger et privat anliggende, men påvirker påliteligheten andre steder i systemet også.

Et lignende, og kanskje enda alvorligere problem er sikkerheten. C kan vise seg å være en regelrett fiendtlig maskin, som avlytter dataene som overføres, endrer dem (f.eks. setter inn virus i overført programkode) og utgir seg for andre enn seg selv.

Nå vet forskerne mye om hvordan man sikrer data som overføres i usikre omgivelser, og svaret ligger i bruk av public-key kryptering. Dette er derimot tungvint og sentralisert teknologi, som slett ikke passer veldig godt til den "anarkistiske" p2p-teknologien.

Generelt kan vi gjette at et p2p-system som skal autentisere brukere uten sentrale tjenere blir mer omstendelig i bruk enn et c/s-system, som vanligvis er fornøyd om du oppgir brukernavn og passord. Andre hevder at p2p-teknologi kun egner seg for anvendelser med lavt sikkerhetsbehov.

Men hva kan da p2p brukes til?

Til tross for alle disse forbeholdene ser vi at p2p-teknologi har noen fordeler fremfor c/s:

I anvendelser der mange maskiner må gjøre en "dugnad" ved å slå sammen sine ressurser for å løse et problem. Vi kan tenke oss CPU-dugnader (SETI@home) og disk-dugnader (Napster, Gnutella, FreeNet). Denne typen anvendelser bør ikke ha et stort kommunikasjonsbehov mellom partene.
I anvendelser hvor kommunikasjonsbehovet er stort, og hvor det derfor er nødvendig å spre nettverkstrafikken over et stort antall forbindelser for å unngå trafikkork. I slike sammenhenger vil vi også finne databehandlingen distribuert. Eksempler på slik anvendelser er distribuerte databaser og distribuert web-søking.
I såkalt tjenestefokusert gruppevare hvor partene ikke deler informasjon og data, men tjenester. Slike programmer er på eksperimentstadiet, og lar en bruker tilby f.eks. en skattekalkulator som han selv har laget til fellesskapet. Eller brukeren kan tilby en kompleks c/s-tjeneste som opererer på data som han selv lagrer og kontrollerer operasjonene på. Tjenester kan ikke flyttes rundt og kopierers slik som data kan, og tjenestefokusert gruppevare er derfor godt egnet for å realiseres med p2p-teknologi. Plattformen for slik gruppevare kan være en web-tjener i hver maskin som kjører asp- eller cgi-baserte programmer, eller være et java-miljø som tilbyr tjenester gjennom fjernobjekter og flyttbar klientkode.

Hvordan skal p2p-programmene skrives?

Ethvert program vil trenge å være tilstandsorientert, dvs. at det trenger å kunne ta avgjørelser basert på kunnskap om sine omgivelser. Er et dokument låst for endringer eller er det ikke? Er backup-jobben ferdig eller er den ikke?

I et distribuert system vil det på grunn av forsinkelser og feil i dataoverføringen hele tiden være uenighet mellom partene om slike spørsmål. Den maskinen som tar backup kan mene "ja, den er ferdig", mens en annen maskin mener noe annet, fordi den ennå ikke har mottatt meldingen om dette.

Der hvor det er viktig at slike uenigheter ikke skaper feil i databehandlingen kan vi innføre distribuerte transaksjoner basert på en sentral transaksjonsmonitor. Men om vi ønsker å lage p2p-programmer er slike sentrale tjenester ikke nødvendigvis tilgjengelig. Da må programmet designes slik at feil og forsinkelser ikke er kritiske for programmet, men i verste fall føre til redusert kvalitet i resultatet. Det er ikke alltid mulig, men alltid komplisert å programmere på denne måten. Men det er nødvendig dersom man ønsker et p2p-program som smidig skal manøvrere seg gjennom oppgaven mens nettverkstrafikken skjer rykkvis og mangelfullt, mens andre maskiner krasjer og restarter i hvilken som helst rekkefølge.

Teorien rundt distribuerte systemer kan gi deg innsikt i designteknikker for å lage programmer som har disse egenskapene, men dette er ganske avansert faglitteratur. Poenget vårt er at programmering av p2p-anvendelser ikke har den støtten hverken i metodene eller utviklingsverktøyene som c/s-anvendelser har, og at du står ganske alene og på egne ben mens du holder på med slike oppgaver.

Gruppevare som p2p - Groove Networks

(www.groove.net)
Et mye omtalt p2p-prosjekt er Groove, som tilbyr gruppvare med p2p-teknologi. Det er laget av sjefen bak Lotus Notes, noe som har gjort at Groove har mottatt mye opperksomhet. Groove er nylig lansert i sin første versjon.

Vår innvending mot p2p-basert gruppevare er knyttet til slike systemers behov for sentral kontroll: Er jeg sikker på at det er Anders som har skrevet dette dokumentet? Hvor ligger originalen til dette dokumentet akkurat nå? Jeg skulle gjerne ha sjekket Olavs kalender, men maskinens hans er slått av for øyeblikket...

Tradisjonell gruppevare basert på p2p støter etter vår mening på mange av problemene med p2p uten å høste noe særlig av fordelene. Derfor tror vi ikke at Groove vil bli et teknisk vellykket produkt.

Oppsummering

P2p-teknologi er noe som har vært kjent en stund, men har fått nye mulige anvendelsesområder med utbredelsen av PCer og Internet. Det er derimot så mange uløste spørsmål og problemer knyttet til p2p at vi tror at det først og fremst vil gjøre nytte i form av nisjeteknologi innenfor de området vi har trukket frem.

Vi er spesielt spent på utviklingen av metodegrunnlag, verktøyteknologi og mellomvare for p2p-anvendelser. Og selvom vi uttrykker mye skepsis til p2p, tror vi at p2p vil sette fantasien i sving og skaffe nye produkter på markedet som ingen hadde tenkt på å lage før.

Dem som trenger en "kalddusj" kan lese:

http://www.darkridge.com/~jpr5/doc/gnutella.html
http://slashdot.org/features/01/03/27/1820213.shtml