Aina on mukava kuulla P2P-kehityksestä :)

Vaikkakin herätti suuria epäilyjä, tulisko esim. MP3:sta yhtä virheetön kuin tällä hetkellä. Vai saattasko tökkiä?

Lainaus, alkuperäisen viestin kirjoitti aaxxeell:

---

Aina on mukava kuulla P2P-kehityksestä :)

Vaikkakin herätti suuria epäilyjä, tulisko esim. MP3:sta yhtä virheetön kuin tällä hetkellä. Vai saattasko tökkiä?

---

Hommahan toimisi näin:
1. Joku laittaa jakoon MP3-biisin
2. Joku toinen lataa sen, muuttaa vaikkapa ID3-tagista kommentit ja jakaa eteenpäin
3. SET:n avulla loput käyttäjät voivat käyttää molempia lähteitä, sillä itse MP3-tiedosto on täsmälleen sama, tagi vain on muuttunut. Se tagi sitten ilmeisesti ladataan jommasta kummasta, luultavasti siitä, mitä on alunperin ruvettu lataamaan.

Eli MP3:sta tulisi täsmälleen yhtä virheetön kuin tavallisen P2P-verkon kautta ladattaessa. Hienolta kehitelmältä kuulostaa, vieläpä kun on vapaata riistaa. Torrent-verkkoihin implementoituna voisi olla melkoisen namu lisäys :)

Tuotahan voisi tietty kehitellä esim. lennossa toimivan rar-purkamisen lisäämisellä, jolloin voitaisiin hakea ja ladata dataa myös RAR-pakettien sisältä. Tosin tuo varmasti hidastaisi koneita melkoisesti... Tai sitten pitäisi uudistaa Checksum-järjestelmää, jolloin summakoodi kertoisi, mitä paketti pitää sisällään :)

Lainaus:

---

Vaikkakin herätti suuria epäilyjä, tulisko esim. MP3:sta yhtä virheetön kuin tällä hetkellä. Vai saattasko tökkiä?

---

Lopullinen tiedosto vastaa täysin sitä mitä olet alkanutkin imuttamaan. Kun tiedosto laitetaan jakoon esim Torrent verkkoon se jaetaan segmentteihin. SET tekniikka vertailee näitä segmenttejä jos ne on bitilleen identtiset voidaan niitä käyttää lopulliseen tiedostoon.
Esim:
Tiedosto A:n segmentit:AB SE HD MH
Tiedosto B:n segmentit:AB SS HD MT
SET tekniikassa näillä kahdella tiedostolla on 50% samaa koodia.

Se ID3 tägi josta Bleeding puhui tulisi siitä tiedostosta jonka on pistänyt imutukseen. Se torrent ohjelma kuitenkin yrittää vain saada aikaiseksi tiedoston jonka .torrent tiedosto määrää.

Varmasti toimiva "parannus" varsinkin MP3 tiedostojen kohdalla joista on monesti kymmeniä ellei satoja melkein samanlaisia tiedostoja jaossa.

Tuohan kuulostaa todella hyvältä. Jopa niin hyvältä että uskon että tuossa tulee jokin menemään vielä pahasti pieleen. Lähes kaikki hyvät uutiset liittyen P2P-verkkoon on olleet liiän hyvää ollakseen totta.

Jaa-a eipä taida kauheest auttaa.... ISP antaa kaistaa sen ver mitä antaa.. siin turha lähtee itkemää... ei se tiedosto/striimi/iha mikä tahasa tuu sen kovempaa mitä kaista antaa myöten..

LordPepsi missasi vähän SED:n idean. Kyseinen tekniikka lisää tiedostojen seedejä/lähteitä. Monesti tiedostojen lataaminen tökkii juurikin lähteiden puutteessa. Ei tuo tekniikka nopeuta lataamista niissä tapauksissa jossa lähteitä on muutenkin tarpeeksi ja kaista on ihan täysi tavaraa.

Ei tietenkään mutta tuo auttaa siinä, että kun kaistan käyttö ei ole maksimissa eli jakajia vähemmin niin nuo tiedostot nopeutuvat saadessaan uusia lähteitä.

LordPepsi vähän kujalla. Luitko otsikon lisäksi jotain muuta. :D

Yleisillä torrenttisivustoilla varmasti tervetullut parannus, koska siellä juuri yleensä pulaa jakajista. Liian helppoa tehdä hit-n-run.

"SET:issä voi kuitenkin olla loppukäyttäjälle yksi ikävä ominaisuus, sillä tekniikka ei pysty erottelemaan tekijänoikeudella suojattua materiaalia ilmaisesta tai vapaasta materiaalista. Tämän vuoksi käyttäjän jakama ilmainen musiikkikappale saattaa sisältää samoja osia kuin tekijänoikeudella suojattu musiikkikappale, jolloin tekijänoikeuksia valvovien tahojen hälytyskellot saattavat tehdä väärän hälytyksen, kun käyttäjä jakaa omaa laillista osaansa heille, jotka ovat "varmuuskopioimassa" tekijänoikeudella suojattua materiaalia."

Tuo em. tarkoittanee kääntäen, etteivät myöskään tekijänoikeuksia valvovat tahot pysty todistamaan onko kyseessä tekijänoikeuden alainen tiedosto vai ei. Varsin mielenkiintoista, erittäin mielenkiintoista ...

Niin jos en ihan väärin ymmärtänyt, niin tulisikohan jostain DC++:ta uusi versio tämän vuoden puolella joka tukisi tätä tekniikkaa? Kyllähän tää edistää tätä koko ajan, mut tosiaan tuntuu et liian hyvää ollakseen totta. Kyllä siellä joku kehistysvaiheessa menee pieleen...

Lainaus, alkuperäisen viestin kirjoitti LoBer:

---

Niin jos en ihan väärin ymmärtänyt, niin tulisikohan jostain DC++:ta uusi versio tämän vuoden puolella joka tukisi tätä tekniikkaa? Kyllähän tää edistää tätä koko ajan, mut tosiaan tuntuu et liian hyvää ollakseen totta. Kyllä siellä joku kehistysvaiheessa menee pieleen...

---

Koodi ja algoritmit tulevat joka tapauksessa vapaaksi, joten _JOS_ siinä koodissa nyt jotain vikaa sattuisi olemaan, on se suurella todennäköisyydellä heti korjattu harrastelijoiden toimesta.

MP3-tiedostojen lisäksi esimerkiksi videotiedostot, levykuvat ym. tiedostot, joista liikkuu useita samantapaisia versioita, saisivat hyvän määrän lisää puhtia nopeuteen.

Lainaus:

---

SET tekniikka vertailee näitä segmenttejä jos ne on bitilleen identtiset voidaan niitä käyttää lopulliseen tiedostoon.

---

Mitenköhän tämä tapahtuu? Jos meinaat verrata segmentin jokaista bittiä tarkistaaksesi, että se on sama, kuin toisen segmentin vastaava bitti, niin silloinhan sinun on pakko ladata molemmat segmentit kokonaisuudessaan. Siinä vaiheessa tuskin sillä on enää väliä ovatko ne samoja, kun kerran olet jo segmentin ladannut, niin ei uudet lähteet varmaan hirveesti siitä segmentistä kiinnosta.. eli siis eiköhän tuo vertailu tapahdu käytännössä checksumien ja vastaavien avulla. Tällöin tietenkin jää ainakin teoreettinen mahdollisuus, että segementit eivät todellisuudessa olekaan samat, vaikka niillä onkin sama tarkistussumma. Se on tietysti eri asia, että huomaako perus ihmisen kuuloaistilla, jos biisin jostain segmentistä on pari bittiä pyörähtänyt ympäri. Siitä asiasta minulla ei ole tietoa.

EDIT:
Niin mut siis fiksulta jutulta kuulostaa noin niinkun yleisesti. Erityisesti noiden mp3:sten yhteydessä voi hyvin kuvitella, miten suuri hyöty tuollaisella tekniikalla voidaan saavuttaa.

Hieman kyllä ihmettelen, tuota kommenttia, siitä että tekijänoikeudellinen matsku ja laillisesti jaossa oleva matsku voisi mennä sekaisin. Aika mouho pitää kyllä käydä, jos kaksi segmenttiä tiedostoista, joilla ei ole mitään yhteyttä, sattuu vaan olemaan samat. Tietysti jos tiedostot jaetaan ihan tolkuttoman pieniin segmentteihin, niin se on sitten asia erikseen. Ja siis toki se mahdollista on, isoillakin segmenteillä, mutta, mutta...

Onpas taas tosi hienoa uutta tenkniikkaa...

GNUnet on käyttänyt samaa tekniikkaa alusta asti. Kylläpä on hieno uutuusarvo. GNUnet pilkkoo kaikki tiedostot kilon blokkeihin riippumatta tiedostosta ja tallentaa tiedot datan hashilla. Näin ollen se on ihan sama mihin tiedostoon blokki kuuluu jos sisältö on sama. Samoin pakettejen sourceja lisätään automaattisesti tarpeen vaatiessa. Tässä on jo kaksi tekniikkaa jotka tehostavat olennaisesti verkkoa, mutta ei ole silti monissa P2P softissa käytössä.

Kumpikaan ideoista ei todellakaan ole uusi.

Kannattaa lukea erilaisten kehitteillä olevien p2p verkkohen whitepaperit ja tekniset kuvaukset läpi jos on epäselvyyksiä. Open source softissa voi katsoa myös koodista detailit jos jää dokumentoinnin suhteen jotain epäselvää.

Esim Rsharen kehittäjä sanoi suoraan, ettei aijo tehdä automaattista sourcejen lisäystä kun sitä hänelle ehdotin. Harmillista, koska se olennaisesti tehostaa verkon toimintaa, samalla myös olennaisesti vähentäen riskiä siihen ettei tiedostoja löydy kokonaisena.

Yksi tehostava tekniikka on myös ecc jolla saadaan tiedot hajautettua siten, että muutama puuttuva blokki ei estä tiedoston saamista kokonaisena perille.

Ainakin Direct Connect -hubeilla/verkossa on ollut käytössä jo pitkään tämätapainen ratkaisu. Kyseessä on siis StongDC++ -asiakasohjelma, joka pystyy lataamaan useasta lähteestä samaan aikaan. Tämä tosin edellyttää samaa sisältöä sekä tageja. Tämä asiakasohjelma on kielletty tosin melkein kaikilla hubeilla, koska se vie ylimääräisiä slotteja turhaan, jos vaikka latausnopeus on 50kt/s, yhdeltä käyttäjältä 45kt/s, toiselta 4kt/s ja kolmannelta 1kt/s. Eli nuo kaksi jälkimmäistä ovat siis periaatteessa turhia latausnopeuden kannalta, mutta ne vievät slotteja ja rasittavat verkkoa.

Lainaus:

---

Ainakin Direct Connect -hubeilla/verkossa on ollut käytössä jo pitkään tämätapainen ratkaisu. Kyseessä on siis StongDC++ -asiakasohjelma, joka pystyy lataamaan useasta lähteestä samaan aikaan. Tämä tosin edellyttää samaa sisältöä sekä tageja.

---

Toisin sanoen toi ei ole sama ominaisuus vaan kyseessä on monesta lähteestä lataaminen kuten Revconnect tekee. SET tekniikka lataa monesta eri tiedostosta monelta eri lähteeltä vaikka ne tiedostot eivät olisi täysin samanlaisia.

Lainaus:

---

[quote]Ainakin Direct Connect -hubeilla/verkossa on ollut käytössä jo pitkään tämätapainen ratkaisu. Kyseessä on siis StongDC++ -asiakasohjelma, joka pystyy lataamaan useasta lähteestä samaan aikaan. Tämä tosin edellyttää samaa sisältöä sekä tageja.

---

Toisin sanoen toi ei ole sama ominaisuus vaan kyseessä on monesta lähteestä lataaminen kuten Revconnect tekee. SET tekniikka lataa monesta eri tiedostosta monelta eri lähteeltä vaikka ne tiedostot eivät olisi täysin samanlaisia.[/quote]Kuten varmasti huomaat, sanoin:

"on ollut käytössä jo pitkään tämätapainen ratkaisu."

En missään nimessä tarkoittanut että se on sama ominaisuus, onhan tuo SET paljon parempi ratkaisu. Tosin sekin vienee turhaan slotteja ja rasittanee hubeja.

Lainaus:

---

Tosin sekin vienee turhaan slotteja ja rasittanee hubeja.

---

Kun puhutaan p2p-verkkojen liikenteen tehostamisesta, on varmastikin jo nykypäivänä unohdettu vanhanaikaiset liikennettä rajoittavat tekijät, kuten DC++:n slotit. Toki hubit, trackerit yms. joutuvat varmasti käyttämään enemmän kaistaa tarkistussummien vertailuun ja käyttäjien "yhdistämiseen", mutta kyseessä ei pitäisi olla mitenkään ylivoimainen este.

Lainaus:

---

[quote]Tosin sekin vienee turhaan slotteja ja rasittanee hubeja.

---

Kun puhutaan p2p-verkkojen liikenteen tehostamisesta, on varmastikin jo nykypäivänä unohdettu vanhanaikaiset liikennettä rajoittavat tekijät, kuten DC++:n slotit. Toki hubit, trackerit yms. joutuvat varmasti käyttämään enemmän kaistaa tarkistussummien vertailuun ja käyttäjien "yhdistämiseen", mutta kyseessä ei pitäisi olla mitenkään ylivoimainen este.[/quote]Tarkoitinkin lähinnä DC++:n kaltaisia ratkaisuja, joissa on slotit käytössä. Tämän takia tuollaiset ratkaisut ovatkin kiellettyjä.

Yhdistämisestä on haittaakin... Bustaaminen helpottuu...

http://torrentfreak.com/youre-caught-dow...ow-or-go-broke/