14341
A fórum csak technikai kérdésekre van, warezt ne kérjetek!
DC info: dcinfo.dynu.com, dchun.hq.hu
-
norti #10291 Picikét olvass vissza és megtalálod miért... -
norti #10287 Hát én mesélhetnék róla... :DDDD
Az egy hiba, magyarul "végzetes kivétel" és a progi lelövi magát. Ha csak ritkán kapod az jó, ha nem ritkán az kellemetlen :) -
#10285
tölts Kazaarol többszalon. -
#10282
35 perc alatt 15 mb :(( -
#10281
thx !
már töltök is :) -
#10280
Legalább 2 slotot kell nyitnod, így tőled egyszerre 2 ember tud majd tölteni.. beállításoknál a megosztás oldalon (file - settings - sharing - upload slots)..
ajánlom amúgy valami faq elolvasgatésát, egy kicsit körülnézhetsz a directconnect.hu -n, ott elég sokmindent találhatsz -
#10279
<Hub-Security> This hub is running PtokaX DC Hub 0.3.2.6 TestDrive 3 (UpTime: 93 hours, 6 minutes)
Private message from newgnr.com - Bot: <newgnr.com - Bot> Open at least 2 upload slots.
ez mit jelent ?? -
#10278
ui még1x, habár már többször leírtam, de sose elég, még a végén besértődik valaki :)
A kliens ha tetszik, használjátok, de a többszálas letöltést NE, az a dc halála ilyen koncepciók mellett -
#10277
Cart azt javaslom, hogy ne akard letölteni sehonnan, amúgy zdc.atw.hu .. de NE használjatok addig többszálas klienst, amíg nincsen meg az a két feltétel, hogy
a) normális hashing van benne
b) CSAK olyan felhasználótól tölt több szálon, akinek a megosztása hashelve van..
harmadrészt a hashelési módszere ha létezik egyáltalán :) egy kicsit elavult, nem a legjobb megvalósítás több-forrású klienshez.. -
#10275
A DIRECT CONNECT MAGYAROKNAK OLDAL MÁTÓL ELÉRHETŐ ITT IS:
www.directconnect.hu.
Kicsit szebb domain ,mint ami eddig volt.
-
#10274
köszi -
#10273
ha megis külön könyvtarba teszed akkor ird felül az összes .xml filet a regiekkel -
#10272
telepítsd rá az előzőre, minden beállítást átvesz és folytatja a letöltéseket -
#10271
az hogy mit irsz a DCdbe az csak informacio, nem fugg attol a sebességed egyáltalán. a valóságot írd, mert ellenőrizhető. javasolt a sávszélességed is beírnod, azt pedig a description (megjegyzés) mezőbe, ami a szerződésben van annál a csomagnál amire előfizetsz/fizettek, pl 512K/256K formában.
a sebességed az alábbiaktól függ
-hány filet töltesz egyszerre (annyi részre oszlik a te sávszélességed)
-milyen kapcsolata van annak akitől töltesz
-hányan töltenek attól akitől te is akarsz (annyi felé oszlik az ő sávszélessége)
- milyen kedve van a vezetékeknek :)
-
#10269
az van írva hogy tvnetwork kábelen..más nincs. szted ettől a beállítástól függ a letöltési sebességem,vagy csak a megosztó kapcsolatától? -
norti #10268 Olyat állíts be, ami a szerződésedben van: ADSL-DSL, kábel-cable, T1, T3, stb. -
#10267
ha 200-250-el tölt gyakran a netem,milyen kapcsolatot állítsak be? ettől függ a letültési sebességem? -
#10266
A slotok számának növelésével a sávszéled több részre oszlik, lassabbak lesznek a le ill. feltöltések. -
#10264
Megvan, T800 a neve, de hát nincs se cím se IP.
Mert le van tiltva, ahogy mondtad.
Vkinek nincs meg az IP? -
#10263 "Nemrég kaptam egy popup-ba DC-n 1 invitálás"
na akkor az engedély nélküli hubreklám miatt letíltottak közt keresd.
-
#10262
Nem tudjátok véletlenül mi a cime annak a HUB-nak (magyar) ahol T1-T3-gyors kábel kapcsolattal vannak fennt a userek. Nemrég kaptam egy popup-ba DC-n 1 invitálás, de már nem emléxem a címre. -
#10260
bocsi, félreérthető volt, a több sloton való letöltés úgy jön össze, hogy 1 slot/felhasználó :)
amúgy a maximum simultaneous download-ot be lehet állítani, de az összességében vonatkozik -
#10258
több felhasználótól több sloton, de ha pl egy kicsit elolvasod, az előtted levő fél oldal kb arról szól, hogy ez milyen bibikhez vezethet..
hibás fájlok, stb.. -
norti #10255 Ehhez annyit tennék, hozzá, hogy nem kimondottan a DC-nek van gondja a ZoneAlarmmal. Edonkey kliensek és bittorrent is szintén szenved a betegségtől, s mint kiderült hálókártya- és hálókártyabeállításfüggő is. Nekem pl. amíg ZA-t használtam semmi gondom se volt se a letöltésekker se a feltöltésekkel. Outpost nem produkálja ezt soha, viszont eszi a swapot néhány nap állandó dczés után után ha log be van kapcsolva...
-
#10254
www.google.co.hu -
#10253
Igen. A többszálas letöltés hibamentességét a hashelés garantálhatja, az egy szálon >belüli< hibákat pedig a safe and compressed transfers opcióval, ami crc-ellenőrzést is végez (habár ennek engedélyezése bcdc-ben nem javasolt, még egy kicsit összeakad valamivel és néha file not available-t ad ki, de már jobb, mint a 305-ben) -
#10251
erről hol lehet bővebben hallani/olvasni? -
#10249
Pl mi lenne, ha esetleg megbeszélnéd vele? Persze ezzel a stílussal nem biztos, hogy sikered lesz, még akkor sem, ha tényleg nem te voltál. -
#10247
Nem. Elképzelhető, hogy lassúra fog váltani, amúgy ezt pont előtted írta Harder (read back it will rule).. szóval az akkor keres alternatívát, ha megszakad a letöltés valami miatt -
#10246
Ha a DC++ v.0.305-ös kliensben beállítom, hogy magától keressen másik letöltési helyet akkor autómatikusan átvált a gyorsabbra? -
#10245
Kezdem kapisgálni a dolgot .. :)
Ezek szerint 1 szálas letöltésnél, ha az uccsó pl. 64k-ban van hiba, akkor kiküszölhető a gond, viszont ha én pl. elkezdtem leszedni egy 700MB-os linux iso-t, amiből lejött mondjuk 100MB-t, és az az 50. MB-nál tartalmaz egy hibát, akkor ilyen esetben az 1 szálas letöltéssel sem küszöbölhető ki a hiba, ugye?
Akárhogy is nézem, ez a "hibás letöltés" gond mindenképp fennáll (hisz valszeg az a gyakoribb, hogy a hiba nem az utolsó pár kb-ban van, hanem már jóval előtte, akár több helyen is), igaz az 1 szálas letöltéssel kicsit kisebb az esély rá.
Ejjj de várom már hogy a hash funkció elterjedjen .. :) -
#10244
Az a különbség, hogy amikor egy szálon töltesz és azt folytatod másik felhasználótól, akkor a beállított Write Buffer és Rollback értékeknek megfelelő darabbal összehasonlítja a már letöltött állományt a letöltendővel. Pl ha a rollback meg van adva 64 k-ra, akkor letölt az új fájlból 64 k-t, és csak akkor folytatja a letöltést, ha a letöltött 64 k megegyezik a korábban letöltött (félbehagyott) fálj utolsó 64 kbájtjával. (jó a write buffer is bejön a képbe, de az más téren, a write buffer értéke az levágásra kerül a fájlból)
Multi-source letöltésnél viszont nincs <mihez> ellenőrizni, mivel <korábban letöltött> rész nem létezik, a kliensnek összerakáskor kellene ellenőrizni a darabokat, ami viszont kimaradt (legalábbis a jelek szerint nagyon úgy néz ki). -
#10243
Np, köszönöm a részletes választ, még ha nem is teljesen értek vele egyet. :)
Azt is megmondom, miért:
Amiről most beszélünk, az ugye a többszálú letöltés, több klienstől egyszerre.
Miben tér el ez attól, hogy 1 szálon töltök le vmi más klienssel, de minden nap mástól és mástól folytatva a dolgot? Nagyon nagyon ritka dolog, hogy 1 fil.. akarom mondani fájlt ugyanattól az embertől szedek le teljesen.
Szerintem ez a 2 módszer semmiben nem tér el egymástól, max itt egyidőben történik a dolog, ott meg egymás után.
Ez a hash dolog így nagyon szimpatikusnak tűnik, kár hogy jelenleg még nem bevált módszer/nem túl támogatott :(
Ha tévednék javítsatok ki légyszi. :) -
#10241
húbazz de hosszú lett 
-
#10240
Mindenkinek saját magának kell megítélnie a dolgot, de egy kis utánagondolás után: Ha több forrásból töltesz le egy fájlt, akkor mi garantálja, hogy a darabok valóban ugyanabból a fájlból származnak-e?
A fájnév? Az mennyiben garancia? .. (ez meggondolható, hogy semennyiben). A fájlméret és fájlnév? Jaham. Így eljutsz oda, hogy >valószínűleg< ugyanaz a két fájl, de mi van, ha mégse? Ez megtörténhet pedig, ez mindenkinek ismerős az egy forrásból való töltéskor is előforduló Rollback inconsistenc y hibáról.
Akkor ha több forrásból való töltést csinálsz, akkor ugyanezek a módszerek (fájlnév és méretellenőrzés) vajon miért lenne nagyobb garancia arra, hogy a fájlok egyeznek?
Erre a megoldást az ún. hashelés jelentheti, ami a fájloknak a tartalma alapján rendel hozzájuk azonosítót, így ha két fájlnak a hash értéke egyezik, akkor garantált, hogy a 2 állomány bájtra pontosan megegyezik egymással.
Ezt >ezen< a screenshoton is láthatod. A képen lévő fájlok ugyanazok, mivel a hash érték megegyezik, holott a nevüknek semmi köze egymáshoz. OK, az oszlopok nem látszanak teljesen, de elhiheted, hogy ugyanaz :) (amúgy ez a hash alapján történő alternatíva-keresésnél jött ki találatként).
Szóval ez egy valóban működő megoldás arra, hogy a fájlintegritást garantáljuk. Az a bibi, hogy ez a hasholós módszer jelenleg csak a BCDC-ben van, ami viszont nem támogatja a több forrásból való letöltést.
Az ndc az a zdc kicsit-módosított magyar változata, ezért a két program megegyezik funkcionalitásában ilyen téren.
A kazaa-n is ugyanez a kérdés merül fel. Ott töltöttem már le videokli.. izé.. linux iso-klippet úgy, hogy a videóban mindig máshol volt a képhiba, pedig a fájlméret és név egyezett. Végül meguntam, és a 4-5 példányt feldaraboltam és összeraktam belőle egy normális verziót. És ez veszélyes, hiába mondjuk, hogy ellenőrizni kéne a fájlokat visszaosztás előtt, ezt senki nem teszi meg, főleg, ha egy videóról van szó. Most istenkém, van benne egy hiba az 50. perc környékén és kockásodik egy kicsit és pattan egyet a hangfal, emiatt senki nem fogja még1x letölteni az egészet, hanem visszaosztja a videót 1 hibával.. aztán 2-vel.. aztán 3-mal... aztán elérkezünk a kazaa-effektushoz
Remélem, hogy ez csak az én rémképem, de hash nélkül a több forrásból való letöltést senkinek nem javaslom. És egyelőre olyan kliens még nincs, ami megbízatóan üzemelne ilyen téren. -
#10239
Az eredeti klienst is érinti ez a gond? (eddig még nem volt belőle bajom, gyorsan le is kopogom :) ) -
#10238
Még mielőtt félreértés történik: jó kliens, használd, ha tetszik, csak ne több forrásból való letöltésre. -
#10237
Torta ha szeretnéd, hogy hibásak legyenek a letöltéseid, akkor kattints >ide< 
-
#10235
nemtom
http://guinevere.no-ip.org/hungaryhublist.config
Torta
http://zdc.atw.hu/
-
#10233
Huh...Akkor nem kell kiszednem a 2 vinyomat 