[Idee] Websites via Peer to Peer

[BKJ]

Het leek mij leuk om een idee van mij hier te sharen en te kijken of dit enigzins haalbaar is en of dit idee een oplossing is voor een veel voorkomend probleem.

Historie

Back in '99 had je Napster, een superproduct met helaas een fout (juridisch) uitgangspunt: de index van bestanden stond op een centrale server. De makers konden hierdoor makkelijk worden aangepakt en er werd geëist dat er een filter over de server heen moest om copyright-issues te voorkomen. We weten allemaal hoe dit is afgelopen (Napster is zo goed als verdwenen).

De oplossing lag in P2P: geen centrale server meer waardoor er geen 'centrale' plek meer was wat kon worden aangepakt. We weten hoe dit is afgelopen: nog steeds een groot succes via eerst Kazaa en later Torrents.

Probleem

Bij het zoeken naar torrents is er echter weer een probleem. De informatie over torrents staat op een website die vaak op een centrale plek staat. De sitemakers (en in mindere mate de providers) zijn traceerbaar en zijn nu in een groots gevecht met copyrightholders (denk piratebay.org). Voor nu hebben ze nog redelijk de dans kunnen ontspringen maar naar mijn idee duurt dit niet lang meer.

Parallel hieraan hebben sites met controversiële en soms illegale inhoud het ook moeilijk (bijvoorbeeld Wikileaks).

Oplossing

Waarom zouden we P2P techniek niet kunnen toepassen voor websites? Verdeel stukjes website over gebruikers en het uit de lucht halen van zo'n website is schier onmogelijk. DDOS attacks behoren tot het verleden, opschalen is een eitje en content die controversieel is (copyright, klokkeluiders) blijft voor iedereen bereikbaar.

Vraag

- Is dit technisch mogelijk?
- Hoe gaan we om met DNS?
- Hoe bouw je zoiets?
- 'What's in it' voor de gebruiker? (bij torrents is dat obvious)
- Kunnen we een gezamenlijk project hier van maken?

Ben benieuwd!

[mithras]

Distributed systemen zijn alleen handig in twee gevallen:

1) Wanneer content voor altijd hetzelfde blijft. Of je torrents van X of van Y download (iig, de data zelf dan), de inhoud zal hetzelfde zijn bij de peers (vandaar ook de checksums).

2) Wanneer je de peers kent. Bij distributed version control systems zoals git en mercurial is de vcs gedistribueerd, maar de changesets neem je van "bekenden" over. Als je de persoon niet kent, kan je ook zijn veranderingen niet overnemen.

Met websites heb je a) niet altijd dezelfde content (zeker grote dynamische sites ala digg, facebook, twitter etc) en b) je weet niet waar je de veranderde content vandaan moet halen (iedereen heeft immers een andere site voor zich).

Dus principieel is het al lastig. Met andere vormen van internet (geen websites) zou je wel heel goed p2p kunnen inzetten denk ik

[beany]

Grootste probleem is volgens mij dat je de beschikbaarheid niet kan garanderen. Wat als je tweakers.net wil openen maar er is niemand(peer) online die deze content kan aanbieden?

En misschien eens kijken naar cloud systemen(zoals google dat heeft). Heel veel systemen(servers) die allerlei content hebben. Er is alleen wel een masterindex nodig(heeft google ook volgens mij). Al staat die masterindex ook weer verspreid over meerdere servers.

[Hydra]

Voor torrents is zoiets al opgezet, zie Wikipedia: Distributed hash table voor meer info.

[RayNbow]

BKJ schreef op dinsdag 06 april 2010 @ 12:30:
Probleem

Bij het zoeken naar torrents is er echter weer een probleem. De informatie over torrents staat op een website die vaak op een centrale plek staat. De sitemakers (en in mindere mate de providers) zijn traceerbaar en zijn nu in een groots gevecht met copyrightholders (denk piratebay.org). Voor nu hebben ze nog redelijk de dans kunnen ontspringen maar naar mijn idee duurt dit niet lang meer.

Als je het alleen gaat om het decentraal verspreiden van .torrents en het zoeken erop, dan bestaat dat al. In Tribler zijn er twee componenten, nl.

1. BuddyCast,
2. Remote search,

die het mogelijk maken om .torrents te vinden via de Tribler overlay. BuddyCast is een protocol waarbij een Tribler peer periodiek met een andere Tribler peer uitwisselt wat zijn smaak is en welke torrents hij gevonden heeft. Via dit protocol kunnen ook de daadwerkelijke .torrent files worden uitgewisseld.

De remote search stelt je in staat om in naast je eigen lokale database ook in de database van andere Tribler peers te zoeken. Een Tribler peer houdt altijd een actieve verbinding met een aantal "taste buddies" (Tribler peers met dezelfde smaak) en een aantal willekeurige Tribler peers. In de database van deze peers kun je dus zoeken.

Meer informatie in o.a. hoofdstuk 6 en 7 van Tribler Protocol Specification V0.0.2.

Hydra schreef op dinsdag 06 april 2010 @ 13:40:
Voor torrents is zoiets al opgezet, zie Wikipedia: Distributed hash table voor meer info.

De Mainline implementatie van Kademlia wordt echter alleen gebruikt voor het vinden van peers in een bepaalde swarm, niet om torrents te vinden.

[jvbijleveld]

beany schreef op dinsdag 06 april 2010 @ 12:36:
Grootste probleem is volgens mij dat je de beschikbaarheid niet kan garanderen. Wat als je tweakers.net wil openen maar er is niemand(peer) online die deze content kan aanbieden?

..en vanuit de ontwikkelaar bekeken; hoe zorg je ervoor dat content up-to-date bij de client aankomt? Meerdere peers betekent ook meerdere (potentiële) versies van bestanden. Niet wenselijk dus

[BKJ]

jvbijleveld schreef op dinsdag 06 april 2010 @ 13:56:
[...]


..en vanuit de ontwikkelaar bekeken; hoe zorg je ervoor dat content up-to-date bij de client aankomt? Meerdere peers betekent ook meerdere (potentiële) versies van bestanden. Niet wenselijk dus

Maar zijn al deze argumenten onoverkomelijk? Ik kan me voorstellen voor dit probleem dat je een aantal peers random een soort van 'master'status geeft die leidend zijn qua content.

[sariel]

Tsja, ik zie het niet zitten. Freenet is een dergelijk netwerk en het is niet alleen zeer onhandig in het gebruik, het is gigantisch baggertraag. Bij P2P moet je 500 verschillende sites af om 1 pagina op te halen, 500 dns requests dus, hopen dat de andere mensen snel genoege lijntjes hebben om sneller dan 28k8 te internetten, etc.

Laat maar.

[HMS]

Bedoel je misschien iets als Coral Caching / CoralCDN?

Linkje: http://www.coralcdn.org/

[Soultaker]

Goed idee, en zeker werkbaar, want het bestaat al in de vorm Freenet en diverse varianten. Het klopt wel dat het traag is. Dat is met torrents ook zo: een torrentfile downloaden van een website gaat zo tienduizend keer zo snel als wanneer je die metadata via de DHT moet binnenhengelen. Maar bij torrents is het natuurlijk zo dat metadata (het .torrent bestand) klein is ten opzichte van de daadwerkelijke data, dus dat het downloaden van de .torrent relatief traag is geeft niet. Bij websites is het natuurlijk wel een bezwaar als alle content opeens duizend keer zo traag laadt.

sariel schreef op dinsdag 06 april 2010 @ 14:08:
Bij P2P moet je 500 verschillende sites af om 1 pagina op te halen, 500 dns requests dus, hopen dat de andere mensen snel genoege lijntjes hebben om sneller dan 28k8 te internetten, etc.

Je kunt ook routen over bestaande openstaande verbindingen. Nog steeds traag, maar een peer hoeft dan niet zo vaak nieuwe verbindingen te openen. Verder zijn de meeste DHTs geïmplementeerd op basis van IP dus DNS requests komen er helemaal niet bij kijken.

[Grijze Vos]

Daarnaast zit je ook nog met de situatie waarin je 5 snelle peers hebt, en 500 trage. Als dat ene CSS bestand dan via een trage peer binnengehengeld wordt zit je 15 seconden met een brakke site layout en dat soort shit.

[naam]

Dat zou je misschien op kunnen vangen door bestanden in kleine delen te doen 2KB per block bvb, Ander groter nadeel wat ik zie is dat het alleen gaat werken voor statische bestanden, niet voor dynamische php pagina's, omdat anders alle nodes van elkaar moeten weten wat iedere node doet..

[ZpAz]

Wat ik me altijd afvraag met peer to peer eigenlijk, bijvoorbeeld Gnutella werkt zonder centrale server.. maar hoe weten de nodes dan van elkaars bestaan af? Wordt er gewoon een lading 'ip adressen' gescand om te kijken of er een client op draait, en van de eerste beste client die ze tegen komen vragen ze een lijst op of? Want dat moet toch ergens vandaan komen lijkt me.

[RayNbow]

ZpAz schreef op dinsdag 06 april 2010 @ 18:51:
Wat ik me altijd afvraag met peer to peer eigenlijk, bijvoorbeeld Gnutella werkt zonder centrale server.. maar hoe weten de nodes dan van elkaars bestaan af? Wordt er gewoon een lading 'ip adressen' gescand om te kijken of er een client op draait, en van de eerste beste client die ze tegen komen vragen ze een lijst op of? Want dat moet toch ergens vandaan komen lijkt me.

Dat is het bekende bootstrap probleem. Op een of andere manier moet je toch minstens 1 andere peer vinden. Vaak wordt een P2P programma geleverd met een file met daarin een paar adressen van bootstrap servers. Tribler wordt bijv. geleverd met een file superpeer.txt met 8 adressen, maar het Japanse P2P Share daarentegen verwacht dat de gebruiker zelf een paar adressen aanlevert. Die adressen kan de gebruiker op bepaalde sites vinden (en die sites zijn makkelijk te vinden via Google).

Edit: Nog een voorbeeldje, de BitTorrent clients Mainline en uTorrent maken gebruik van router.bittorrent.com en router.utorrent.com als bootstrap nodes voor de DHT.

[ Voor 8% gewijzigd door RayNbow op 06-04-2010 19:13 ]

[kunnen]

Bestaat al: http://freenetproject.org/.

[leuk_he]

ThomasB schreef op dinsdag 06 april 2010 @ 22:59:
Bestaat al: http://freenetproject.org/.

En meer soortgelijke projecten, gnunet en entropy.

Omdat deze als belangrijkste feature anonimiteit hebben, wordt al het verkeer via meerdere nodes gebounced. Dat kan het netwerk heel traag maken (relatief gezien).

Het zijn wel in feite een netwerk van proxies. Nadeel is dat je dus eigenlijk alleen statische html sites of files ermee kunt versturen. ziet er dus nogal web 1.0 achtig uit.

RayNbow schreef op dinsdag 06 april 2010 @ 13:49:
[...]
De Mainline implementatie van Kademlia wordt echter alleen gebruikt voor het vinden van peers in een bepaalde swarm, niet om torrents te vinden.

In eMule wordt een andere KADemilia implemntetie gebruikt om eMule serverloos te laten werken. (inclusief zoeken van files, wat in torrent ontbreekt)

[ Voor 29% gewijzigd door leuk_he op 06-04-2010 23:32 ]