Saját fájlcserélõt fejleszt a Microsoft

Oldal 1 / 3Következő →

Jelentkezz be a hozzászóláshoz.

#125
Ez szerintem buktatásra szolgál 😛

[ Dj Doky Music Site - http://djdoky.tx.hu

mrzed001
#124
Én már csak azon a híren csodálkoznék, hogy "Operációs rendszert fejleszt a Microsoft" 😊)

Star Trek fan vagyok, tehát egy IDEALISTA. Viszont magyar is vagyok, tehát egy HARDCORE REALISTA.

#123
"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.....

Yossarian
#122
"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.

Nieleen

#121
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 😊).
#120
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.

#119
Sztem ebbõl a dologból nem lehet többet kihozni, meg már kezdem unni is, szal sztem hagyjuk 😊
#118
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).
#117
Bár ez az "alap" nagyon gyenge lábakon áll, azaz már nem is alap. 😊

#116
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. 😊

#115
Jó, akkor legyen igazad, "ilyen alapon" nincs semmi külöbség az ftp és a bittorrent között.

#114
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...
#113
Az erõs, már-már tulzásba vitt, eröltetett belemagyarázás pont az, amit most csinálsz 😊
#112
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.

#111
De, értem, mire akartál célozni, csak nem talált, mert egy erõs belemagyarázás a hasonlat. Érted? 😊

#110
Nincs mindenkinek arra se igénye, se pénze, hogy maprakészen tartsa a gépét... Nekem pl se pénzem, se igényem rá 😊 ~ 4 éves a configom...
#109
Arról nem én tehetek, hogy nem érted 😊
#108
Hát, nem b@szogatni akarlak, de ha egy mai átlagprocin mérhetõ 5, néha 10% sok... 😊

De már a Brad Cohen-féle alap BitTorrent kliensben is van ilyen.

#107
A hasonlatnak általában van valami értelme... 😊

#106
Ok, látom semmit nem mond a hasonlat szó 😊 Van ilyen...
#105
Lépett néhány verziót az Azureus, amióta legutóbb próbáltam, de majd belenézek. Nincs erõmûvem és az egy igen sokat zabáló prg. 😞
#104
Hát, ha neked egy központi szerverrõl tölteni az adatokat egyforma dolog a bittorrenttel...

#103
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.)

#102
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.

#101
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.

#100
"Mond az valamit, hogy p2p? 😊 Hogy jön ehhez egy néhány mirroros ftp-szerver?"

Mond az neked valamit, hogy hasonlat? 😊
"Ilyen alapon a webes (http, ftp) letöltést is lehetne decentralizáltnak nevezni... <...>"
#99
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...
[HUN]PAStheLoD
#98
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..

hátö .. az elõzõ aláírásom sokkal jobb volt :]

#97
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.

#96
Azt látom. 😛

[HUN]PAStheLoD
#95
BT-nél a .torrent file adja meg h. mekkora egy szelet/rész mérete, és ezután a kliens dolga kérni a megfelelõ szeletet ;]

hátö .. az elõzõ aláírásom sokkal jobb volt :]

[HUN]PAStheLoD
#94
Azért egy nagyobb swarm-ban ez nem probléma.. ameddig rendsen töltöd visszafele is..

hátö .. az elõzõ aláírásom sokkal jobb volt :]

[HUN]PAStheLoD
#93
Az azureusnál a DHT-hez való kapcsolódás a sarkallatos, ezt pedig saját szerverrel hajcsák meg , ha jól tévedek.

hátö .. az elõzõ aláírásom sokkal jobb volt :]

#92
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).

#91
nem, csak tippelgetek.
#90
Fantáziálsz? 😉

#89
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.)

#88
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.

[HUN]PAStheLoD
#87

hátö .. az elõzõ aláírásom sokkal jobb volt :]

[HUN]PAStheLoD
#86
Az exeem még mindig a 0.24-es bétálnál tart .. túl sokszor nem tudsz keresni, túl sokszor szakad szét a hálózat, ilyesmi. De idõvel majd alakul ez..

hátö .. az elõzõ aláírásom sokkal jobb volt :]

[HUN]PAStheLoD
#85
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.

hátö .. az elõzõ aláírásom sokkal jobb volt :]

#84
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... 😞
#83
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... 😞
#82
Azért én elgondolkodnék, milyen hátsó szándéka lehet a MS-nak ezzel...

#81
"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.

#80
"<...>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.
#79
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 😊).
Yossarian
#78
családi videókat

Nieleen

#77
És vajon mit fogunk megosztani?.....vagy esetleg letölteni?...

Tuborgs are better than one... two beers or not two beers?..thats the question :)

Yossarian
#76
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ú.

Nieleen

Oldal 1 / 3Következő →