Én már csak azon a híren csodálkoznék, hogy "Operációs rendszert fejleszt a Microsoft" :))
"A vállalat természetesen hangsúlyozza, hogy a technológia segítségével kizárólag legális anyagok terjesztésével illik foglalkoznunk, bár az nem világos, hogy milyen módon szûrnék ki az illegális másolatok csereberélését." Mindjárt gondoltam.. Ha õ elterjedne mint fájlcserélõ akkor már cska egy következõ verzió kell, és.....
"maga a .torrent file sem egy szervert ír elõ"
pedig torrent készítésnél meg kell adnod a tracker URL-jét, a torrent fájlban pedig mindjárt az elsõ sorban ott is van.
Hmm, elmentünk személyeskedés irányba? :). Amúgy a donkey (legalábbis az mlDonkey) folyamatosan olyan szerverek irányába megy, ahol a keresett file-ok gyakrabban / nagyobb részben megtalálhatóak. Tehát a szerverlistában a mozgás is elég dinamikus, arrafelé mész, ahol több hasonló érdeklõdésû emberrel találkozol. (Legalábbis így magyaráz Taki Árpi...)
A BT azért durvább ennél. Többiek már leírták jórészt miért. Én talán azt nem láttam még leírva, hogy maga a .torrent file sem egy szervert ír elõ, akármennyi lehet benne. Az meg hogy hol tárolódik, hát szinte bárhol :). Sõt sokan még a torrenteket is anonimizáló proxykon keresztül hirdetik meg... Tény, hogy egy adatbázis szerver kiesése fennakadás lehet, de nem az adatok/file-ok, hanem a jól-megszokott keresés lehetõségének kiesése miatt. (Emberi, nem gépi faktor :)).
Jó, mondjuk játék közben is sok. Bár egy 4 éves gép (ami valszeg 4 éve sem csúcsgép volt) amúgy sem a legjobb jétékra.
Ha semmi más nem futna, nem zavarna... Valszeg fogalmad nincs róla, milyen egy az enyémhez hasonló configon a mai programokat futtatni (lehet régen neked sem volt jobb, de akkor a programok sem ettek ennyit). Az nem ad objektív képet a helyzetrõl, ha a haverodnak vagy az iskolában is kb ilyesmi van és elszöszölsz rajta fél órát... Egyébként jól mondod, pont a nagy gépigénye miatt nem használom már, pedig szvsz egyik legjobb kliens volt már akkor is, amikor megismertem (pedig ez nem ma volt).
Megkérdezhetem, miért zavar annyira az a (nálad) 20%? Renderelsz közben? Ha nem, csak azt akarod elkerülni, hogy a mindennapi feladatokban (amik nem jelentenek folyamatos erõs terhelést) esetleg zavarjon, állítsd alacsonyabb prioritásra. De erre szvsz nincs szükség. De persze nem kötelezõ az Azureust használni. :)
20% az nálam egyetlen programra igenis sok... Lehet neked minden alkalmazásod ennyit eszik, lehet neked ez az átlagos, de nekem ez már rég az "igen sokat zabáló prg" kategória...
Mondom, mai átlagos proci. Ez alatt 2000+-os Athlon-t, vagy 2GHz-es P4-et értettem, tehát nem a mai csúcsot. Ezeken 5-10%-ot eszik az Azureus. A te gépeden legyen mondjuk 20.
Az alaprendszerben nem teljesen az, mert persze kellenek a trackerek. (De mint írtam, már korábban is válhatott bármelyik peer, legalábbis pl. Azureus-használó maga is trackerré.) Most meg a DHT-vel fõleg decentralizált lett. (Bár ez csak opcionális, mert kicsit korlátozottabb így a dolog.)
Ha a seederekhez sokan csatlakoznak, és nem superseedelést csinálnak, akkor is kell várnod, míg te következel a queue-ban. Minden esetben, ha másnál épp nincs meg a szelet...
Nem tudom, lehet-e célirányosan keresni egy szeletet. Nem nagyon. Csak annyit tehetsz, hogy szépen sorra veszed a peereket, és az egyiknél talán megvan már.
Kicsit olvasgattam. Nincs kölön DHT-szerver. A peerek maguk válhatnak ilyen DHT-noddé. Csak továbbra sem teljesen tiszta, hogy jön létre a legelsõ kapcsolat a peerek között.
Tulképp nem értem, mirõl is beszélünk még :) Amit a torrent decentralizáltságáról mondtam (azaz, hogy véletlenül sem az), az megáll a lábán, te is pont ezt fejtegetted...
Hát ha seederhez is csatlakozol, ami egy egészséges swarmnál alap, akkor nem gond ez :)
Ha lineárisan töltöd, akkor szépen úgy csatlakozik a kliens, hogy keresi azokat a peereket, akiknek megvan az adott rész és utána is bizonyos darab.. így megy elõre és szépen keresi az új peereket, ha a régiek közül vkinek már nincs meg. Legalábbis szerintem, mert ez tûnik a leglogikusabbnak. A véletlenszerû szeletek töltésénél a sebességprobléma olyan 95% után kezd el jelenktezni, mert akkor a még le nem töltött szeletek mint lyukak jelentkeznek a .torrent tartalmában, azokat kell összevadászni..
Mármint a lineáris töltés? Hát... Legalábbis ha több gigás cuccot töltenek egyszerre sokan, akkor fordul elõ, hogy egy adott szelet (ami épp jönne neked a sorban) olyanoknál van csak, akiknez épp nem csatlakozol. Vagy akár mások sem, mert mások sem csatlakoznak mindenkihez.
Bittorrentnél alapesetben most is véletlenszerû a letöltés (vagy inkább áttöltés). (Átkapcsolható folyamatosra, csak az sokszor lassabb, mert egymásutánban nem mindíg rögtön elérhetõk a darabok.) Nem a file végérõl hiányzik a töltés vége felé az adat, hanem véletlenszerû helyekrõl, amik véletlenül csak kevesebb helyen vannak meg, így lassan jutnak el hozzád (fõleg, ha sokan vannak, és nem tudsz mindegyikhez kapcsolódni).
Azt mondjuk nem tudom, ebben bizonyos "decentralized tracking" rendszerben hogy van megoldva a peerek elsõ egymásratalálása. Talán van 1/néhány szerver, ami összehozza õket - asszem, egyszerûen úgy, mint rendszer-tagok, tehát nem .torrent file alapúan, azaz nem vádolható véletlenül sem illegalitással. (Hacsak nem nyilvánítják az egészet illegálisnak, ami érdekes lenne.)
Mond az valamit, hogy p2p? :) Hogy jön ehhez egy néhány mirroros ftp-szerver?
Mint írtam, most már a centralizált tracking sem feltétel.
Csak a .torrent file-okat kell megszerezni (amik azonosítják és hitelesítik az adatot, így nem kihagyhatók), de az már nem olyan nagy gond. Sokszor ezek sem csak egy helyrõl megszerezhetõk (kivéve, ha ez szándékos törekvés), azaz ezek sem centralizáltak.
Kicsit el vagy tévedve , a LimeWire , a BearShare , a KaZaa és az eDonkey , WinMX, Gnutella, Shareazaa .. etc etc , mind mind egy központi szerverre csatlakoznak. Az Exeem is centralizált, mert ott is van pár fix pont, amik segítenek legalább 1-2 node-hoz való kapcsolódásban.
Ha tényleg decentralizált p2p-t akarunk, akkor az nem nagyon mehet másként, mint hogy valamiféle csoda folytán rátalál a "hub"-ra a csatlakozni kívánó. Ez lehet egy csomó weboldal is, ahol vannak fenn ip-k, de lehet hogy végignéz 200 000 ip-t mindegyiknél próbálva kapcsolódni az XY portra , hogy hátha ez a peer már tagja a naagy naaagy p2p mennyországnak.
Apropó... Nekem sincs teljessen igazam, mert az eXeem tulajdonképpen a majdnem tökéletes decentralizált torrent kliens. A baj ezzel csak az, hogy nem terjedt el túl nagy mértékben, mindenki csak tölteni szeretne (persze csak lefelé), nincs megosztás, nincsenek userek, nincs mit tölteni... Pedig igen jó kezdeményezésnek tartottam annó, nagy kár, hogy megdöglött... :(
A dolognak az a része, hogy miéknt kapod el a seedereket, már tulajdonképpen lényegtelen, ha a decentralicálásról van szó. Mert ugye a *.torrent filet valahonnan mindenképp meg kell szerezned. Ilyen alapon a webes (http, ftp) letöltést is lehetne decentralizáltnak nevezni... Mert ugye ott is mirror szerverekkel lehet gyorsítani a letöltést, és ezeket a mirrorokat fel lehet fogni seedereknek. Nem, a decentralizált P2P az a LimeWire, BearShare, KaZaa, és sorolhatnám, de a torrent sajna még messze van a decentralizálságtól... :(
Azért én elgondolkodnék, milyen hátsó szándéka lehet a MS-nak ezzel...
"Próbálnak a decentralizálásra törekedni, ám eddig még nem igazán sikerült..."
Azért ezt nem mondanám. Az új Azuban teljesen jó a decentralizált tracking. Nálam (hazai ajánlásoknak megfelelõen) alapból ki van kapcsolva, de ha nem tudok csatlakozni egy külföldi trackerhez, vagy az regges (és nem akarok 101. helyre reget), akkor bekapcsolom arra az egy torrentre (jobb klikk menü), és már csatlakoznak is a peerek. (Ha egy csatlakozik, már jó, mert - azt hiszem - küldi a többi címét is.)
Csak a .torrent file kell, de azt általában több helyrõl meg lehet szerezni. Olyan is lehet, hogy valaki a saját gépén futtatja a trackert. Vannak is páran, akik rá is álltak erre.
"[...]Másrészt a BT abszolut decentralizált, nincs _EGY_ központ, kifejezetten úgy tervezték meg, hogy ne lehessen nyomonkövetni a dolgokat.[...]" BT egyik legnagyobb hátránya, hogy kell neki egy kozponti dolog, ahonnan beszerzed a *.torrent fileodat, ami nélkül nem kezdheted el a letöltést. Próbálnak a decentralizálásra törekedni, ám eddig még nem igazán sikerült...
"[...]Nomeg felteszem a protokoll zárt lesz és csak a saját kliensükkel használhatod.[...]" Errõl nem tlehet tudni semmit egyelõre, sztem kár is találgatni. Fõleg azért totál lényegtelen, mert ha a gyakorlatban is életképes MS ötlete, akkor valószínüleg a BT kienseket fejlesztõk heteken belül integrálják majd a megoldást.
Ezek a sebességnövekedések elvi és labormérésekbõl vegyítése :). Emlékszel még a modem idõkre? V42b meg ilyesmi? Mivel itt azt akarják csinálni, hogy a részekbõl összekódolnak letölthetõ részeket, tehát _elvileg_ kevesebbet kell letöltened. (És mivel a kódolt már tömörített, így az ilyen minták keresése nyilván nehezebben megy, míg egy kódolatlan text-nél lazán 90% is lehet.) Ez a "tömörítés" hoz tehát valamennyi növekedést, gyanítom ez a nagyobbik része. A többi része pedig - szerintük - abból adódik, hogy ezáltal jobban-gyorsabban elterjednek a file-ok, tehát kevesebbet kell üresen várni. Ez utóbbira nyilván majd csak éles nagyüzemi teszt adhatja meg a konkrét számadatokat. (Valaki találkozott már ilyen problémával? Valós igény ez? :))
De számomra még mindig kétséges, hogy mégis mit akarnak ezen terjeszteni? Másrészt a BT abszolut decentralizált, nincs _EGY_ központ, kifejezetten úgy tervezték meg, hogy ne lehessen nyomonkövetni a dolgokat. Most képzeljünk el egy, termékfelelõst, akitõl megkérdezik: "Na, és hányan és honnan töltötték már le a sw-frissítést? Háát, nemtom." Ugye ez így nagyon nem életszerû MS viselkedés :)). Szerintem szinte biztos, hogy rátesznek valami DRM cuccot, amivel nyomon akarják követni a végeredmény file-okat (különben 5 perc, míg bajszot akasztanának a jogvédõkkel, a media-playerben is van ilyen DRM-kezelõ, elõírhatják, hogy csak ilyen aláírt file-ok kerülhetnek bele a hálózatba) Nomeg felteszem a protokoll zárt lesz és csak a saját kliensükkel használhatod. De ezek csak feltételezések hasból, még akár az is elõfordulhat, hogy mégsem :)).
És vajon mit fogunk megosztani?.....vagy esetleg letölteni?...
ezek a beígért sebesség növekedések szerintem nagyon sántítanak. Mert itt is az lesz a lényeg, hogy a seederek feltöltése hogyan aránylik a letöltõk sebességéhez. Ha sokan csüngenek kevés seederen, akkor ez is lassú lesz, ellenkezõ esetben meg a BT sem lassú.
superseed esetén ki lehet hozni 1-re is a superseeder arányát, akár végtelen seeder egyidejû megjelenése mellett is , csak hát az idõ tényezõ erõsen változik ;]
MS Akamai-n keresztül teríti az anyagját.. meg gondolom van pénze sávszélre.. akkor igazából nem tudom mire jó neki ez a P2P.. gondolom csak azért hogy LEGYEN
Hm, lehet collisiont csinálni, de akkor majd áttérünk a duplán hashelésre. MD5-el meg SHA-1-el is , sõt a Tiher hash-ról még nem hallottam h. collideolható..
"kódolt adatátvitel esetében 20-30 százalékkal, míg a kódolatlan adatátvitelnél akár 200-300 százalékkal is meghaladhatja a jelenlegi fájlcserélgetõ szoftverek által nyújtott sebességet" -hogyhogy?
bt ált. maxszal tölt... persze nem nekem, persze hogy nem használom, naná hogy a buickot.
Hmm, nagyon belelendültem, conspiracy theory-nál tartok :). Az MS kb. fél éve bevállalta azt, hogy kiemelt ügyfeleinek (amerikai hadsereg, állam, stb.) GARANTÁLJA hogy a frissítés eljut minden gépükhöz a kiadástól számított x percen (talán felóra?) belül. A feladat adott, a mérnökök ezt a megoldást hozták ki. Azt senki nem mondta, hogy ehhez nem használja fel a többi ügyfele gépét ily módon :)).
Ööö, megyek lehûtöm magam, nagyon meleg van :).
Igen-igen, de ezt a BT jelenleg checksum alapján dönti el. Elvileg lehet olyan részeket csinálni, aminek a tartalma más, de a checksum-ja ugyanaz (ha valaki nagyon-nagyon táp, nem bizonyított :).) Itt a tényleges tartalom-részlet visszanyerhetõ és nincs ilyen probléma.
Hmm, ha azt termékupdate-ekre akarják használni, akkor szerintem csak a sok központi szerver terhelésmegosztására (esetleg vállalati proxy-zásra) lehet használni. A "lehet" szót itt leginkább jogi értelemben veszem. Mert míg a BT-né l ez úgy mûködik, hogy én is adok, te is adsz és mindenki happy. Addig itt felmerül a kérdés, hogy vazz, én a progiért fizettem egy zsák pízt, még én is terjesszem helyette a fizetett sávszélembõl, na ne má... Ugye, kicsit sérül az üzleti modell :).
Hát, biztos én vagyok butuska, de még mindíg nem kapizsgálom, hogy egy superseed-es torrentnél ez mivel lesz jobb. Ugyebár minél elõbb van fent az anyag, annál jobb, valamint minél kevesebb feltöltött adatmannyiséged mellett minél több seed-er lett. Superseed-el 1,1-szeres adatfeltöltés mellett lett 3-4 seeder egyszerre. Ezt nem tudom hogy lehet überelni?
Viszont az is igaz, hogy ezzel iszonyatosan be lehet tenni azoknak a progiknak, amik fake file-okat akarnak bejuttatni a rendszerbe (mint pl. Viralg). Hiszen ha nem arra használjuk ezeket a letöltött részeket, hogy a file különbözõ részeire visszakövetkeztessünk belõle; hanem arra, hogy _összehasonlítsuk_ vele, máris egy õrült hatékony ellenõrzõ rendszert kaptunk. Dodge this :)).
Jah, tehát ezt akarja jelenteni az a lineáris kombináció :]]
Mennyire nagy a különbség a BT és e között ? Ha jól látom itt arra mennek rá , hogy végülis hamar növekedjen a seederek száma, ami nem rossz, csak mi van, ha seeder lelép, otthagyja a bolyt (swarm) ? Míg leecherként muszáj seedelnie is valamennyit, különben nem kap semmit.. vagy MS arra (is) épít, hogy sokan hagyják majd a windows updatet bekapcsolva, és QoS-el együtt majd a felesleges sávot használják erre?
Áh, ok. Õk gyakorlatilag azt csinálják, hogy a letöltött részek bizonyos szabályok szerint _átlapolódnak_ (ezt nevezik õk kombinációnak), tehát egy letöltött részlet az tulajdonképpen a file több részletébõl tevõdik össze. Durván fogalmazva tehát nem a file a letöltött részek lineáris kombinációja (mint ahogy a cikk írja), hanem a letöltött részek a file részeinek lin. kombinációja. Nem mindegy :). (Ez a rajzból látszik [img] http://www.hwsw.hu/kepek/hirek/2005/06/avalanche.gif[/img] igazán, leírva elég hülyén hangzik :)).
BT ennek az ellenkezõjére hajt, minél kisebb részleteket tölt le (pár kB), és azt igyekszik a file minél szélesebb tartományából venni (szórás), hogy a terjesztés elején minél több helyen legyen meg minél több részlet. Ebben is van ráció, mérni kéne, hogy melyik a jobb. Az MS megoldása imho nagyobb forgalmat fog generálni, meg kéne nézni, hogy idõben hozza-e a várt gyorsulást. De laborkörülményekben ez nem fog menni, épp a viselkedés kiszámíthatatlansága miatt, élesben fog majd kiderülni :).
Ha az MS ír egy progit, és azon ötleten lovagolva ír egy ugyanerre való progit, de jobban meg van csinálva, akkor az MS szar, az MS béna köcsög...
itt gondolom valaki más ír u. ilyen progit, nem?
Amúgy MS-t tényleg sokszor alaptalanul támadják, pl. az elmaradott üzletpolitikája, ami végülis egyet jelent azzal hogy üzleti cég , nem karitatív szervezet, alapítvány.. a szar programjairól meg annyit, hogy sokat ül a babérjain, ha meg másol, akkor gátlástalanul teszi..
Egyébként már itt évek óta egy pár ember a következõt csinálja(megpróbálom körülírni):
Ha az MS ír egy progit, és azon ötleten lovagolva ír egy ugyanerre való progit, de jobban meg van csinálva, akkor az MS szar, az MS béna köcsög...
Ha valaki ír egy progit, és azon ötleten lovagolva ír egy ugyanerre való progit az MS, de jobban meg van csinálva, akkor az MS szar, az MS köcsög mert lop...
Akkor más ezek szerint lophat? Teccik érteni... vagy csak sexuális orgazmusba jut itt egyes ember, ha az MS valamit rosszul csinál, illetve szívinfarktust kap, ha valamit jól??? Ezt nem inkább betegségnek hívják?
Fantasztikus , M$torrent.. úgyis azt mondják majd h. õk találták fel a spanyol viaszt..
nemhiszem hogy sok igazi újdonság lesz ebben azért. az edonkey/emule se sorban tölti és a ritkákkal kezdi. már régóta.
Kíváncsi vagyok, akkor is ennyi postban fog-e szerepelni a "lopás" szó, amikor arról fonak cikkezni, hogy megjlent az elsõ, új, módosított torrent kliens, amibe beleépítették ezt az új ötletet...? :)
a ms mindig is nagyoin értett mások 5leteinek az ellopásához, ez a cikk is ezt tükrözi
Hwsw-n kicsit részletesebben van mint itt -> http://www.hwsw.hu/hir.php3?id=29174&count26=1 De ha az kevés, és tényleg jobban érdekel, nézd meg itt: http://www.research.microsoft.com/~pablo/papers/nc_contentdist.pdf Bár lehet, hogy kicsit túl részletes lesz:)
úgy náz ki, h pl bittorentnél 1 file darabka pl az 1. tartalmazza, a következõ fájl rész megtalálásához szûkséges adatokat. a 2. a 3.-ékt stb. stb. és így sorba végûl letölti az egészet. ez meg vmi olyan lehet, h rohangálnak a hálóban a darabkák, a kliens meg figyeli, és látja, h jé ez az 5. ez a 3. az az 1. ott megy 122. és szépen ahogy éri õket elkezdi letölteni.
Vagy esetleg véletlenszerûen töltik a darabkákat, így elkerülve azt, hogy bizonyos "kiemelt" (filevégi) darabok ritkábbak legyenek. Egyenletes elosztás :)
szerintem kicsit tulértékeled a dolgot a lineáris az itt arra vonatkozik, hogy egymás után sorbarakja a töredékeket
Értem, ezt az apróságot elfelejtették megemlíteni :).
Akkor már csak azt a lineáris kombinációs izét nem értem. Amennyire szegényes ismereteimbõl telik, ez azt jelenti, hogy független dimenzióknak kell lenniük a file-ban; ez kódosztásnál azt jelenti, hogy generátorpolinomok vannak, amivel az egyes dimenziókból a teljes file legyártható. Magyarul meg kell adni a dimenziókat (ezek "merõleges, azaz nem keveredõ" minimális kódszavak), és a kombinációt (a fentiekbõl vett mennyiségeket), amivel legyártható a file maradéktalanul. Ööö, hogy a fenébe lehetne ezt szemléletesen leírni. :(
De ha ilyen létezik, akkor miért nem azt publikálják, hiszen elég lenne azt letölteni és magadnak összerakni a file-t, nem kéne az egész file-t letölteni :))). (Nomeg feltáltuk volna a melegvizet, ld. futásidõben memóriába önkitömörítõ file-ok, arj-hez is volt ilyen :)). Szóval, hol van itt a bukfenc?