Direct Connect

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.

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

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

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

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)

errõl hol lehet bõvebben hallani/olvasni?

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.

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

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?

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

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

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

húbazz de hosszú lett

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.

Az eredeti klienst is érinti ez a gond? (eddig még nem volt belõle bajom, gyorsan le is kopogom 😊 )

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.

Torta ha szeretnéd, hogy hibásak legyenek a letöltéseid, akkor kattints >ide<

nemtom
http://guinevere.no-ip.org/hungaryhublist.config

Torta
http://zdc.atw.hu/

Huh...Akkor nem kell kiszednem a 2 vinyomat

sry és thx

Észérvekkel meggyõzhetõ vagyok. Fõleg ha ennyien próbálnak...
Úgyhogy a módosítás módosítva:

---1.--- Ne osszatok 2Gigánál nagyobb DVD image fileokat (film, game .iso, .bin, .nrg, stb) az alapmegosztás részeként. Megosztásuk kizárólag akkor engedélyezett, ha legalább 10 G méretû egyéb korrekt megosztással rendelkezel, és a DVD imageket ezen felül helyezed egy külön DVD IMAGE nevû mappába. A 2G méret alatti imagek továbbra is az alapmegosztás részét képezhetik.
Kickelni akkor fogunk, ha olyan 2G-nél nagyobb DVD image(ket)t osztasz, ami(k) nélkül nem éri el a megosztásod a minimum 10G-t.

Kösz.

akkor tart sokáig a hash számolás ha nagyon sok apró filet osztasz. ha a progikat gameket korrektul tömöritve osztod akkor nem lesz sok idõ.

A mai estém abból áll, hogy azt a faq-ot másolgatom..

Nem nehéz ám kettõt kattintani 😊 Még ha nem magyarul lenne..

pl >ide<
1.16 Miért terheli a processzort (merevlemezt) a BCDC?
A 300-as verziótól kezdve mûködõ funkció a hasholás. A hash értékek kiszámítása elõször meglehetõsen sok idõt vesz igénybe, ezt türelemmel várd ki. Az értékek a BCDC mappájában lévõ "hashes" nevû fájlban kerülnek tárolásra. Amennyiben ez a fájl nem kerül törlésre, a továbbiakban a hashek számolgatása jelentõsen rövidebb ideig fog tartani. Természetesen a hasholás kikapcsolása látszólag megoldja a problémát, de ezzel elesel egy igen hasznos szolgáltatástól. Pár percet pedig megér... 😊

a magyar hublista címet írja be ide vki légyszi!

FleetCommand | ma 23:27 | Privát | Válasz | #10224

idézet a weboldalról

A Download Queue-ban az állományok jobbgombos menüjébõl többféle lehetõség közül választhatsz:

Remove (Eltávolít): A megjelölt állományokat eltávolítja teljesen a Download Queue-ból, így azok nem kerülnek letöltésre.
Válasz 'fm' üzenetére (#10220)

olvasgasd

idézet a weboldalról

A Download Queue-ban az állományok jobbgombos menüjébõl többféle lehetõség közül választhatsz:

Remove (Eltávolít): A megjelölt állományokat eltávolítja teljesen a Download Queue-ból, így azok nem kerülnek letöltésre.

nekem segítenél??

hmm.. nem szóltam. már müxik.

Valaki help ! ez miért van -->>

<23:08> *** Kapcsolódás a következõhöz: matrix-hub.no-ip.com...
<23:08> *** Idõtúllépés...
<23:09> *** Kapcsolódás a következõhöz: matrix-hub.no-ip.com...
<23:09> *** A célszámítógép megtagadta a kapcsolatot
<23:09> *** Kapcsolódás a következõhöz: matrix-hub.no-ip.com...
<23:09> *** A célszámítógép megtagadta a kapcsolatot
<23:09> *** Fájl-lista frissítve
<23:09> *** Kapcsolódás a következõhöz: matrix-hub.no-ip.com...
<23:09> *** A célszámítógép megtagadta a kapcsolatot

vki plz segítsen gyorsan,ha lehet..hogy kell leállítani végleg egy elkezdett letöltést? ha close connectionra megyek újra kezdi..a remove user queue-val kell??

Szio Mate😊
A DVD image fileok tiltasaval nem csak a filmeket teszitek ki a hubrol, ha nem pl az osszes PS2es game et is!
Amugy meg, ha vki az alapshareen felul maniakus DVD gyujto, miert gatoljatok meg benne, hogy kielje szenvedelyet?😊))
P.S.: a rarozott dvdket is nyirjatok?😊)
Best regards,

Maci

Némi announcement, köszönöm a figyelmet.

SZABÁLYVÁLTOZÁSOK ELITE HUBON

---1.--- Ne osszatok nagyméretû DVD image fileokat (film, game .iso, .bin, .nrg, stb). Sajnos a jelenlegi átlag netkapcsolatok nem alkalmasak
a 4-5 Gigás állományok DC stilusú letöltésére, igy a megosztási méret ilyesmivel való kitöltése nem korrekt. Kickelni 2G feletti imagefileért fogunk.

---2.--- Programokat, gameket csak image, .exe file vagy tömörített formában osszatok. A sok fileból álló telepíthetõ verziokat is tömörítsétek be.
A nagyszámú file kezelése terheli a hubot és hiányos letöltésekhez vezethet (egy-egy filet véletlenül nem töltesz át). Be nem tömörített
programok megosztásáért kickelni fogunk.

---3.--- Terjedelmes tömörítetlen vagy gyengén tömörített hangfájlokat ezután se osszatok. Eddig zenei .wav -ért kickeltünk, 30Mega felett, mostantól
az 1Gigát meghaladó szinkronwavokért is morcosak leszünk.

---4.--- Növeljük a hubon megengedett kliensek minimális verziószámát: DC++ból 0.300 és e feletti, BCDC-bõl 0.300 és e feletti, oDCbõl 5.212
és e feletti kliensek a megengedettek. Az újabb verziós kliensek fejlettebbek, érdemes használni õket. Ajánlott a legfrisebb verziók használata.
A korábbi verziókban egy komoly biztonsági rés van, amelynek kellõ rosszindulattal történõ kihasználása károkat okozhat a gépeden.
Haladó érdeklõdõknek további részletek a biztonsági résrõl: http://dcplusplus.sourceforge.net/forum/viewtopic.php?t=6838
Ajánlott: Elite Special Edition kliens 0.306 (más hubon is okés) http://bcdc.webhop.org/?page=elite ,
DC++ 0.306 www.dcplusplus.com ,
BCDC 0.306 http://bcdc.webhop.org ,
oDC 5.31 http://gempond.com/odc
A verziószámokat a hubprogram fogja belépéskor ellenõrizni, 0.300 ill 5.212 alatti klienssel nem fogsz tudni a hubra lépni.

---5.--- Ezután kötelezõ jelleggel kérjük a szabályzatban már régóta szereplõ részt, mely szerint a descriptionban kötelezõ feltüntetni a névleges
download és upload sávszélességeket. Ez Elite Special kliens használatával ( http://bcdc.webhop.org/?page=elite ), vagy a description mezõ
(file-settings-general) szerkesztésével kivitelezhetõ. Ez utóbbi esetben az alábbi formai megoldások közül válassz, a rád vonatkozó érték behelyettesítésével:
/64K vagy /2M, avagy 384K/64K, 4M/2M ahol a K kbitet az M Megabitet jelent és a /jel utal az upload mivoltra.
A description mezõt a sávszélesség megadásával kezd, ha egyéb szöveget is beírsz, akkor az a sávszélesség után következhet.
A slotszabályokban elõírt "Chello" "FastDSL" "Fiber" illetve "Korlátozott koli" beírási kötelezettsége változatlanul él, ezt is a sávszél mögé helyezd.
Pl.: /512K Munkaidõben --vagy 1M/128K Új Mátrix 4. Trailer nálam! --vagy 512K/128K CHELLO
Kizárólag ezeket a formákat tudjuk elfogadni, mert ez szükséges az ellenõrizhetõséghez.
A saját neted névleges sávszélességét illik tudnod, ha mégsem akkor nézz utána a netszolgáltatóval kötött szerzõdésben,ill. kérdezd
a rendszergazdád, végsõ esetben használj speedtesteket és próbálj következtetni. Ne minket terhelj ezzel, elég feladat lesz nekünk a valótlan
adatokat megadók banolása. Az upload sávszélek megadására helyezünk majd hangsúlyt, a download felett tovabbra is szemet hunyunk ha
netán hiányzik.

---6.--- Bekerült a szabályzatba két új bekezdés a Hubon való viselkedés részbe, ezekre figyelj oda:
- tartózkodj a caps lock és a halmozott írásjelek használatától, nem kelt jó benyomást,
- tartózkodj a chat színvonalának ismerkedõs-pasizós-csajozós szöveggel való züllesztésétõl, ez nem az a hely.
No comment. Akinek erre külön kell felhívni a figyelmét annak nemigen való a DCzés.


Az új szabályok be nem tartására január 27.-étõl kezdõdõen kickel hivjuk fel a figyelmeteket, illetve bannal honoráljuk az együttmûködés
elutasítását.

A szabálymódosítások belátható módon nem kekeckedés végett, hanem a ésszerû okokból jöttek létre. Köszönjük hogy elfogadod.
Elite Op Team

az tényleg gáz,a sok buzi reklám miatt is..
de itt nem értem:lefelé 12k-val jön,de felfelé meg 230-al! grr..miért van ez?

Kazaa-nál még mindig jobb, az csak zenére jó, programokra viszont förtelmes. Anno a FIFA2003.rar rippelt Jedy Knight II - Jedy Outcast-nak bizonyult...

thx a segítséget,ez még nagyon bonyi nekem. ezek a slotok meg miegymás...

ja..és tvnetwork-ös mikrohullámú netelérésnél milyen kapcsolatot állítsak be? mi függ a kapcsolatbeállításomtól? 13k-val való letöltés elfogadható?

mostmár megy a connect😊 csak azt nem vágom,hogy mivan pl ha elkezdek 1 cd-s bint szedni és az illetõ lelép örökre,vagy törli a gamét. illetve szabadon csatlakozhatok-e hubokra,össze-vissza,vagy ez jár vmi "felelõsséggel"?

Válasz 'keopsz' üzenetére (#10180)

Jóvanna, gondolhattad, hogy nem arra írtam 😄

ZoneAlarm kommentek:

Q: What is a Rollback Inconsistency? (#6537)
<..> the data has become corrupted during a transfer, and is usually because one of the users, either you or the one you are downloading from, are using a bad firewall, such as ZoneAlarm intercepting some packets.

Q: How to set up active mode with a hardware firewall/router? (#6518)
What about ZoneAlarm?
Forget it. ZoneAlarm is a known issue with DC++, it causes corrupted downloads/uploads, this is directly linked with the 'Rollback Consistency' error message. You need to completely uninstall it, just disabling it will not help, and then get another firewall.

Ugyanezek itt is..

Azon kívül:

BCDC++ changelog:
= 0.305b =
gmt: added ZoneAlarm detection. it will bug you every 13th time

azért ennyien nem tévedhetnek

#9759

Szívesen

zizi a hozzászólás elejét lécci úgy kezdd, hogy "ZA Pro leszed" .. 😊

ZA Pro feltesz / Programok menüpontnál minden funkciót kipipálni a dc-re(mail küldést nem kell) és restart pc
Elvileg nálam anno így ment.

Outsider milyen tûzfal?

Sopi biztos nem utolsó infó, csak ez a szabályzat hubonként különbözõ (szerencsére többé-kevésbé egységes), ezért ez, amit beírtál, nem vonatkozhat mindenkire és minden hubra. Errõl mindig annak a hubnak a szabályzatában kellene meggyõzõdni, amelyikre felléptél.

Ambrus:

A fórum csak technikai kérdésekre van, warezt ne kérjetek

**********

0.306 a legújabb.. http://dcplusplus.sf.net

sziasztok melyik a legjobb dc verzió?
én most 305 öt hasznalok és azt mondjak hogy bugos
Melyiket hasznaljam?