mboost-dp1
Novell
#2 Det er hverken broadcast (der, som du bemærker, er umuligt) eller multicast (der er alt for dyrt og upraktisk, og desuden kan lukkes ned lige såvel som en tracker kan), men god gammeldags unicast.
Det fungerer ved at hver maskine der deltager i netværket vælger en tilfældig værdi (nøgle) indenfor et bestemt interval (keyspace), og annoncerer nøglen til sine peers (andre maskiner på netværket, som den kender på forhånd).
Når en maskine på netværket vil dele f.eks. en fil, så bestemmer den hash-værdien for filen (udfra en fælles anvendt algoritme, f.eks. SHA1) indenfor samme interval, og annoncerer til sine peers at den ligger inde med filen med den hash-værdi. Hver peer, der modtager annonceringen, sender den så videre til den af dens egne peers hvis nøgle-værdi ligger numerisk tættest på den annoncerede hash-værdi, som så igen sender den videre til en af sine peers efter samme forskrift. Den proces gentager sig så indtil annonceringen af filen har fundet frem til den maskine på netværket hvis nøgle ligger aller-tættest på filens hash-værdi (dvs. den maskine som ikke kender nogle peers hvis nøgle ligger tættere på filens hash-værdi end dens egen nøgle). Denne maskine lagrer så annonceringen.
Når nogen så søger efter filen, så formidles forespørgslen på samme måde - forespørgslen videresendes igen og igen til den peer hvis nøgle ligger tættest på den efterspurgte fils hash-værdi (som fremgår af Magnet-linket), indtil den endelig når frem til den maskine der (som beskrevet ovenfor) har annonceringen af filen på lager. Denne maskine fremsender så annonceringen til den maskine der sendte forespørgslen, og udfra annonceringen kan sidstnævnte maskine så se IP-addressen på den maskine, der ligger inde med filen, og påbegynde downloadet.
Afvigelser kan forekomme alt efter netværk og protokol, men ovenstående er den grundlæggende idé. Og ja, det er ret fascinerende, og et godt eksempel på hvordan man med lidt opfindsomhed totalt kan omgå alle de dyre administrative ligegyldigheder, som et bureaukratisk misfoster som multicast ellers afstedkommer.
Det fungerer ved at hver maskine der deltager i netværket vælger en tilfældig værdi (nøgle) indenfor et bestemt interval (keyspace), og annoncerer nøglen til sine peers (andre maskiner på netværket, som den kender på forhånd).
Når en maskine på netværket vil dele f.eks. en fil, så bestemmer den hash-værdien for filen (udfra en fælles anvendt algoritme, f.eks. SHA1) indenfor samme interval, og annoncerer til sine peers at den ligger inde med filen med den hash-værdi. Hver peer, der modtager annonceringen, sender den så videre til den af dens egne peers hvis nøgle-værdi ligger numerisk tættest på den annoncerede hash-værdi, som så igen sender den videre til en af sine peers efter samme forskrift. Den proces gentager sig så indtil annonceringen af filen har fundet frem til den maskine på netværket hvis nøgle ligger aller-tættest på filens hash-værdi (dvs. den maskine som ikke kender nogle peers hvis nøgle ligger tættere på filens hash-værdi end dens egen nøgle). Denne maskine lagrer så annonceringen.
Når nogen så søger efter filen, så formidles forespørgslen på samme måde - forespørgslen videresendes igen og igen til den peer hvis nøgle ligger tættest på den efterspurgte fils hash-værdi (som fremgår af Magnet-linket), indtil den endelig når frem til den maskine der (som beskrevet ovenfor) har annonceringen af filen på lager. Denne maskine fremsender så annonceringen til den maskine der sendte forespørgslen, og udfra annonceringen kan sidstnævnte maskine så se IP-addressen på den maskine, der ligger inde med filen, og påbegynde downloadet.
Afvigelser kan forekomme alt efter netværk og protokol, men ovenstående er den grundlæggende idé. Og ja, det er ret fascinerende, og et godt eksempel på hvordan man med lidt opfindsomhed totalt kan omgå alle de dyre administrative ligegyldigheder, som et bureaukratisk misfoster som multicast ellers afstedkommer.
Men hvordan kommer man i kontakt med netværket?
Man skal vel kende mindst én peer i netværket!?
Denne peer skal vel så offentliggøres i en torrent eller en central kendt server eller noget ?
Man skal vel kende mindst én peer i netværket!?
Denne peer skal vel så offentliggøres i en torrent eller en central kendt server eller noget ?
#7 Ja, man har typisk en liste af peers til at 'bootstrappe' fra på en central kendt URL. Denne URL kan selvfølgelig lukkes ned, men i modsætning til lukningen af en tracker påvirker det ikke tjenesten for dem der allerede er på netværket (idet de har opbygget deres egen liste af peers), og skulle det ske er det ret trivielt at lægge en ny liste op på en anden URL (man kan i princippet gøre det på en regulær SurfTown-konto), mens det er dyrt og og besværligt at opsætte og drive en ny tracker - bl.a. fordi den skal håndtere så meget større mængder traffik.
Alternativt kan man drive netværket som "darknet", dvs. hvor man kun kan forbindes til det ved invitation fra en bekendt der allerede er forbundet. Derved vil der end ikke være en bootstrap-URL at lukke ned - men det vil som regel være overkill.
Alternativt kan man drive netværket som "darknet", dvs. hvor man kun kan forbindes til det ved invitation fra en bekendt der allerede er forbundet. Derved vil der end ikke være en bootstrap-URL at lukke ned - men det vil som regel være overkill.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund