[worxland]

Idézet: Proz3ssoR - Dátum: 2005. aug. 15., hétfõ - 22:26

A másik problémám az, hogy a fájlok amiket leszedek iszonyatosan összetöredeztetik a vinyót. Volt egy olyan file ami 788 darabra tört (a windows szerint). Persze ez lehet hogy természetes, mert végülis töredékekbõl szedi össze, de akkor sem buena.

Természetes.

Idézet

Ill. azt vettem észre, hogy tök mind1 hogy a fileból csak 1% jött még le, attól még sok esetben az egész file métét foglalja el a vinyón. Ez normális?

Normális.

Szerkesztette: worxland 2005. 08. 15. 22:14 -kor

[ERROR 404]

Idézet: Proz3ssoR - Dátum: 2005. aug. 15., hétfõ - 22:26

...végülis töredékekbõl szedi össze, de akkor sem buena.

De nem is "Social Club"!   

A töredezettség-probléma általános, azaz nem csak az "ön készülékében fordul elö"
Ezt -szerintem- úgy szokták kezelni, hogy egy (vagy két) particiót feláldoznak a szamárnak, aztán azt úgy cincálja, ahogy akarja, feltöltéskor nem probléma, ha szanaszét heverö darabkákból kell összemazsoláznia. A fragmentálódásból eredö lassulás ilyen téren elenyészöen jelentéktelen.

Idézet

"...azt vettem észre, hogy tök mind1 hogy a fileból csak 1% jött még le, attól még sok esetben az egész file métét foglalja el a vinyón. Ez normális?"

Igen, itt ez a metódus, hogy: "elöre foglal, aztán beköltözik."
Ez szerintem se jó dolog, föleg akkor, ha nagy volumenü dolgokra nyomul a felhasználó, de ez a müködési elvéböl fakad.
Amúgy néha elöfordul, hogy mintegy rosszul méretezi a lefoglalandó részt a .part fájl számára, de menet közben korrigál.
A kliensben van egy olyan beállitási lehetöség, hogy mekkora minimálisan lefoglalható rész alatt riasszon, azaz ha nincs már elég hely, azt tudassa a felhasználóval.
Ezt érdemes a letöltési igényeidnek megfelelöen beállitani.



A port-engedélyezéses+konnektálási gondodra várjunk egy szakit/szakikat, mert itt elkél az idevágó tapasztalat mellé némi szakértelem is, én meg -úgy tünik-, hijján vagyok ezeknek. 
A hibaüzid olyasmiröl regél, hogy az IPFILTER.DAT-állományodban elöfordul annak a szervernek a cime, ahová csatlakozni szeretnél, ha jól értem.
Erre nem árt odafigyelni, a saját érdekedben.
Ha más tartományban elhelyezkedö szerverre konnektálsz, akkor megy minden hiba nélkül, ha jól sejtem?


Ide is elkél asszem a figyelmeztetés, amire egy másik eDonkey/eMule-os fórumban hivatkoznak:





Idézek:

2.2 - 2.5 mind Fakes !!!
a racorback.com -tol való hibajelentés meg igy néz ki :
There are fake servers on the network named Razorback. Be carefull, do not connect yourself to them!
There are only TWO official Razorback servers:

Razorback 2.0 at 195.245.244.243:4661
Razorback 2.1 at 195.245.244.244:3000

All the others are FAKE SERVERS whose only purpose is to log the files you are sharing!


Ez pedig egy Fake-szerverlista (idézet ugyanonnét a fórumból):

This list has been compiled by a number of users and has been previously posted on the eMule, eDonkey2k and methlab forums. It's not a complete list but it contains a listing of several spy servers.


38.119.67.93 - 38.119.67.93 , 0 , tribes
38.119.105.66 - 38.119.105.66 , 0 , tribes
66.192.117.34 - 66.192.117.44 , 0 , tribes
199.218.8.201 - 199.218.8.201 , 0 , tribes
209.61.190.154 - 209.61.190.154 , 0 , tribes
209.61.191.17 - 209.61.191.17 , 0 , tribes
209.61.191.41 - 209.61.191.41 , 0 , tribes
69.90.75.54 - 69.90.75.54 , 0 , tribes
206.161.11.16 - 206.161.11.16 , 0 , tribes
63.222.6.1 - 63.222.6.99 , 0 , tribes
204.11.19.4 - 204.11.19.4 , 0 , tribes
205.177.3.3 - 205.177.3.3 , 0 , tribes
207.226.112.18 - 207.226.112.18 , 0 , tribes
66.250.47.36 - 66.250.47.36 , 0 , Roberts Donkey Party I
66.250.47.35 - 66.250.47.35 , 0 , Roberts Donkey Party II
66.250.47.34 - 66.250.47.34 , 0 , Roberts Donkey Part III
66.250.47.33 - 66.250.47.33 , 0 , Roberts Donkey Party IV
66.250.47.30 - 66.250.47.30 , 0 , Roberts Donkey Party V
66.250.47.29 - 66.250.47.29 , 0 , Roberts Donkey Party VI
66.250.47.27 - 66.250.47.27 , 0 , Roberts Donkey Party VII
207.234.225.78 - 207.234.225.78 , 0 , MP*Masterz
207.176.22.20 - 207.176.22.20 , 0 ,SlaveServer
206.161.11.16 - 206.161.11.16 , 0 , TEENserver
63.217.27.16 - 63.217.27.16 , 0 , highSPEED
205.177.3.8 - 205.177.3.8 , 0 , bOOb.net
205.177.3.3 - 205.177.3.3 , 0 , www_guy-sex_com
63.222.6.22 - 63.222.6.22 , 0 , fast-sex
204.11.19.4 - 204.11.19.4 , 0 , !-= www.FreeSexMasters.com =-!
205.177.3.24 - 205.177.3.24 , 0 , llamaServ
207.176.22.12 - 207.176.22.12 , 0 , Cobras Emule Server
207.226.112.18 - 207.226.112.18 , 0 , TigAAAR slam
206.161.11.4 - 206.161.11.4 , 0 , YaoiCentral
64.34.162.87 - 64.34.162.87 , 0 , Sonny boy 1
64.34.161.44 - 64.34.161.44 , 0 , Sonny boy 2
64.34.161.219 - 64.34.161.219 , 0 , Sonny boy 3
64.34.161.157 - 64.34.161.157 , 0 , Sonny boy 4
63.115.148.102 - 63.115.148.102 , 0 , edonkey.linuxlabs.com
62.75.222.220 - 62.75.222.220 , 0 , www.nutten-abo.de
63.115.148.103 - 63.115.148.103 , 0 , eD2kb.linuxlabs.com
213.202.214.28 - 213.202.214.28 , 0 , www.kopftuchporno.de
69.44.156.185 - 69.44.156.185 , 0 , Family Donkey Server.
66.250.47.26 - 66.250.47.26 , 0 , (no name only ip number)
66.250.47.37 - 66.250.47.37 , 0 , (no name only ip number)
66.250.46.254 - 66.250.46.254 , 0 , Jumping Jim
66.250.46.252 - 66.250.46.252 , 0 , Jumping Jim 2
195.227.42.89 - 195.227.42.89 , 0 , ## Power Micha 1 ##
217.31.16.70 - 217.31.16.70 , 0 , pornofilme.prag.webspace24.de
64.69.78.245 - 64.69.78.245 , 0 , GasBastards
67.159.5.36 - 67.159.5.36 , 0 , Scoopy Doo's Porn Farm
213.186.60.179 - 213.186.60.179 , 0 , "Dans tes rêves" le film
213.251.133.87 - 213.251.133.87 , 0 , "Dans tes rêves" le film
216.156.142.13 - 216.156.142.13 , 0 , eHorse2000
207.176.22.17 - 207.176.22.17 , 0 , --===--The.REAL.OC--===--
207.226.112.24 - 207.226.112.24 , 0 , www.hotteensexpress.com
207.226.112.3 - 207.226.112.3 , 0 , ==Porno_Warez_4U==
63.217.27.7 - 63.217.27.7 , 0 , eMulerack 2
204.11.19.24 - 204.11.19.24 , 0 , ~69~ Island
204.11.19.22 - 204.11.19.22 , 0 , eDonkeyServer2000


Ez utóbbi figyelmeztetéseket nem a netröl szedtem össze, egy másik fórumból plagizáltam (utólagos köszönet érte Pintyónak, Petikey-nek) talán nem baj, hogy itt is publikálva lettek, igy többekhez eljut az információ.

[Proz3ssoR]

Idézet

Ha más tartományban elhelyezkedö szerverre konnektálsz, akkor megy minden hiba nélkül, ha jól sejtem?

Nem. Igazándiból egy szerverhez sem tudott még úgy csatlakozni hogy a tcp dolgok mûködjenek. És az a vicc, hogy semmit nem csináltam az IPfilter.dat-tal. Nincs is bekapcsolva az IP-szûrés...

[Satriani]

Idézet: PetruZ - Dátum: 2005. júl. 30., szombat - 12:27

Na, ha egy fájl már "vonalkódos", akkor felesleges tovább szenvedni vele.

Jókat írsz, de ezzel nem értek egyet. Nekem egy kotta (konkrétan Queensryche: Empire) volt kb. fél évig vonalkódos. Úgy voltam vele, hogy az a 20MB nem nagyon foglalja a helyet úgysem, aztán talán egyszer mégis elõbújik a gazdája... Elõbújt. Most is van egy olyan fájlom, amit május óta nem láttam teljes egészében. Mivel kb. 70MB, marad a töredék, rá fogok érni megnézni Karácsonykor is. 

Szerkesztette: Satriani 2005. 08. 16. 00:26 -kor

[PetruZ]

Idézet

Jókat írsz, de ezzel nem értek egyet. Nekem egy kotta ... volt kb. fél évig vonalkódos.

Lásd az adott hozzászólásom pont utána következõ idézet utáni részét. És hogy ismétcsak ellentmondjak magamnak: volt egy régi, nem igazán populáris tévésorozat, ami egyike a legeslegritkább cuccoknak. DVD sohasem készült belõle, csak tévéfelvételek vannak. Nos, szívós munkával megszereztem minden részét - egyet kivéve. Az az ominózus rész kábé fél éve csücsül a listám "missing" részén. DC-n, torrenten sincs meg (vagy nagyon eldugott helyen, és nem találtam rá). Nem is reméltem, hogy megtalálom, míg úgy negyedéve feltûnt a mulén. Egyetlen forrással. Azóta is "vonalkódozok" vele, de már kb. a 10%-a lejött. Olyan 8-10 ember cserélgeti egymás között a lejött darabokat, de full forrás még mindig csak egy ugyanaz maradt. A tempóból ítélve, feltételezve, hogy a forrás megmarad, talán tavaszra lejön az egész...

[PetruZ]

Idézet

Az egyik az, hogy gyönyörûen beállítom a Kapcsolatokat, TCP/UDP port teszt mûködik... Egészen addig míg nem csatlakozok egy szerverhez.

Tûzfalnak mit használsz, hogyan van beállítva?

Idézet

A másik problémám az, hogy a fájlok amiket leszedek iszonyatosan összetöredeztetik a vinyót. Volt egy olyan file ami 788 darabra tört (a windows szerint). Persze ez lehet hogy természetes, mert végülis töredékekbõl szedi össze, de akkor sem buena.

Ez a letöltési technikából következik. Bár nem írtad, hogy pontosan milyen klienst használsz, mert alapvetõen kétféle fájlkezelésük van. A mule/donkey alapú kliensek minden fájlt kb. 9.8 megás darabokra, blokkokra vágnak, ezt hívják "part"-nak, ezt látod a transfer ablakban is. Minden part saját hash értékkel rendelkezik, plusz az egész fájlnak is van egy. A két metódus a kiírási módszerben különbözik:
-Az egyik az ún. "old" metódus, amely csak egyetlen böszme fájlt használ, a part-ok ebben helyezkednek el, szépen sorrendben, ahogy a végleges helyük is lesz. Ez csinálja az elõrefoglalásokat, és ez tördeli szét a vinyót. Mint javasolva is volt (és amivel maximálisan egyetértek, és csak javasolni tudom): oda kell neki adni egy full partíciót, ami csak erre a célra szolgál. Arra persze figyelni kell, hogy ne nullázza le magát, mert ez esetben komoly bajok keletkezhetnek, mivel a kliens nem tudja visszaírni az adatokat tartalmazó met fájlokat, és onnantól kezdve a letöltött cucc elvész, csak nagyon izzadtságos munkával lehet visszabányászni. A módszer elõnye, hogy szinte csak gyors, file-on belüli seek (pozícionáló) mûveleteket használ, így kevesebb erõforrást kell fenntartania.
-A másik az új, "new" metódus, ami minden part-ot külön fájlba ír, majd a legvégén sorba fûzi õket. Ez sokkal kevésbé fragmentál, viszont a sok nyitva tartott fájl handle miatt több erõforrást zabál, és jobban igénybe veszi a vinyót, valamint lelassítja a könyvtárkereséseket is (akár több ezer part file is felhalmozódhat egy könyvtárban).
A legtöbb kliens az "old" módszert használja (többnyire nem is lehet választani), ntfs partíció esetén egyébként is az az ajánlottabb. Mindenképpen érdemes saját partíciót adni neki, amit kb. negyedévente, offline (!) mûködés mellett töredezettségmentesítünk (érdemes akkor, ha kevés cucc van rajta), de a kimeneti könyvtár (ahová a kész fájlokat rakja) lehetõleg ne ezen a partíción legyen.

Ui.: Elõfordulhat, hogy a "new" az "old", és az "old" a "new", elõre is elnézést érte, de most bizonytalan vagyok, melyik-melyik. Utánanézek és pontosítok.

[worxland]

Idézet: PetruZ - Dátum: 2005. aug. 16., kedd - 8:05

Ui.: Elõfordulhat, hogy a "new" az "old", és az "old" a "new", elõre is elnézést érte, de most bizonytalan vagyok, melyik-melyik. Utánanézek és pontosítok.

Jól írtad.

Az biztos, hogy az eDonkey a 0.53-tól már a new metódust használja.

[shoto]

Üdv!
Segitséget kérek a következõben. Az eMule-ban mindig LowId-t kapok. Kábelnetes kapcsolatom van,  tûzfalam Zone Alarm, router nincs. A 4662, 4672-es portokat beállítottam a tûzfalon de igy is csak LowId. A windows tûzfala kikapcsolva. Megpróbáltam linuxban is ott is ugyanez a helyzet. Ha ki van kapcsolva a tûzfal akkor is. Már kipróbáltam úgy is, hogy más portokat állítom be de akkor se. A test is mindig hibát jelez. A kapcsolatom 1024/384. Feltöltés álltalában 40KByte-al megy de lefele 10-20 között.
Ha tud valaki valami tanácsot adni akkor elõre is köszönöm.

[PetruZ]

Nem lehet, hogy a szolgáltatód blokkolja a szokványos p2p portokat? Egyébként pont a ZoneAlarm az, amit az emule hivatalosan sem ajánl, mert nem megy jól a klienssel. Bár a fórumokon többen az ellenkezõjét mondják. Nem ismerem a ZA-t, de azt írják, hogy nem portonként kell engedélyezni rajta a mulét, hanem teljesen, és akkor megy. Én Kerio-t használok, régebben én is portra szûrtem, de mivel az ISP-k sorban blokkolják a szokott és ismert portokat, a szerverek mindig más portokra költöznek, ami rengeteg szabállyal járt, úgyhogy most full engedélye van, pár port (21, 80, ...) kivételével.

[Proz3ssoR]

Idézet: shoto - Dátum: 2005. aug. 16., kedd - 12:58

Üdv!
Segitséget kérek a következõben. Az eMule-ban mindig LowId-t kapok. Kábelnetes kapcsolatom van,  tûzfalam Zone Alarm, router nincs. A 4662, 4672-es portokat beállítottam a tûzfalon de igy is csak LowId. A windows tûzfala kikapcsolva. Megpróbáltam linuxban is ott is ugyanez a helyzet. Ha ki van kapcsolva a tûzfal akkor is. Már kipróbáltam úgy is, hogy más portokat állítom be de akkor se. A test is mindig hibát jelez. A kapcsolatom 1024/384. Feltöltés álltalában 40KByte-al megy de lefele 10-20 között.
Ha tud valaki valami tanácsot adni akkor elõre is köszönöm.

Itt is írnak a problémárol, olvasd el a topikot, talán segít

[shoto]

Nem hiszem, hogy a tûzfallal van gond mert kiróbáltam többfélét, vagy csak úgy tûzfal nélkül is, de nem lett jó sehogy. Ráadásúl még linuxban sem sikerült rendesen mûködésre bírni.
Másra már nem tudok gondolni, minthogy a szolgáltató blokkolja a portokat, de már átnéztem sokféle fórumot és azokat a portokat amelyiket ajánlottak, de egyikkel sem mkaptam HighId-t.
Azért köszönöm, még próbálkozok.

[Hülyesamu]

Semmilyen hálózati eszköz sincsen útközben? Az ADSL-t nem ismerem, de ott szokott lenni valamilyen kis falidoboz, mittudomén. Hogyha az címfordítást végez, pl. te a helyi hálós 192.168.xxx címen éred el õt, akkor ott a gond.
A géped más módon tud szerver lenni, azaz bármilyen más módszerrel "látod" kívûlrõl? Pl. wigwam port-teszt mit mond? Látja a gépedet?

[keeper2]

Na egy pár kérdés: miért van az, hogy a beállításokban a test ports-ra kattintva "TCP connection test failed because eMule rejected the connection." hibaüzenetet kapom. Alapból a kliensben is be van állítva az ip szûrõ, sõt, emellett fent van a gépemen a peer guardian és a protowall is, a beállított adatbázisukkal. (A teszt idejére a protowallt kikapcsoltam, az emule-ban az ip szûrõ engedélyezését kikapcsoltam, illetve, amikor a test ports-ra kattintok, a gép automatikusan az emule-projects.net weblapra megy. Mivel a peer guardianban ez blokkolva van, ezért ezt a címet engedélyezem. Eztán is, akárhányszor kattinthatok a test portsra, de mindig failed lesz. És a peer guardian sem mutatja semmi jelét annak, hogy bármely más letiltott cím felé szeretne kommunikálni a program, és az továbbra is tiltás alatt van ott.) Ellenben, azt meg kell jegyeznem, hogy mindig high id-m van, tehát, elvileg mûködik minden jól.

Az ip szûrõben van egy olyan, hogy szûrõ fokozat < és itt egy szám áll, ami alapból 127. Ez mit takar?

Ha netán uninstallálom, majd újrainstallálom az emule-t, akkor melyik az a fájl, amit el kell másolnom, amiben az aktuális letöltés alatt álló fájlok vannak? Sajna totál gyökérül van megoldva. Dc-ben legalább a neve is utal rá, és a tartalma is, sõt, még kézzel is szerkesztgettem idõnként a letöltési listámat. Itt még azt sem tudom, mi tárolja. Illetve, újratelepítés után azt a fájl visszamásolva mûködni fog onnantól, ahol az aktuális letöltés tartott, feltételezem. (a letöltés part fájljait gondolom nem törli uninstallkor)

A letöltési listában, ha valamelyik fájl nevére klikkelve lenyitom, hogy kiknek van ez meg, akkor mit jelent a méret oszlopban a source exchange/kad/ed2k server/passive feliratok? A source exchange-re még csak el tudnám képzelni, hogy valami olyan beállítási mód, hogy csak akkor tölthetek a csávótól, ha én is töltök fel neki. Ez esetben viszont hogy kell elkezdeni a dolgot? Mert ha pl. én is így állítanám be, akkor mindketten egymásra várnánk. Persze, az is lehet, hogy mást jelent. Illetve, a többi jelentését sem tudom. Az ed2k az edonkey, a kad az kad, de miért lényeges ez számomra, ha ugyanúgy kezeli õket? Illetve, elég gázos, hogy ha bármelyik embernél rámegyek a részletekre, akkor ott rögtön feldobja az ember ipjét. Én eddig azt gondoltam, azért van a fájl lista letöltés megszoítás, hogy ezzel az anonimitást segítse elõ, és ezért fogadtam el, hogy jó ötlet. De ha ott az ip, akkor semmit nem ér a dolog. Mintha egyik kezével adna, a másikkal meg elvenne a rendszer.
Az állapotnál a sorban áll az egyértelmû. A sor megtelt már nem annyira. Mi a fene van ilyenkor? Ennél mégcsak sorban állni sem engednek, hogy valamikorra majd sorra kerüljek? Hiszen így soha az életben nem tudok tõle tölteni, ha még a sorba sem kerülhetek be. Ha meg csökkel a sorbanállók száma, akkor kérdés, hogyan jut be egy új várakozó a sorba. Hiszen, nem tartja nyilván, így lehet, hogy pont az épp akkor jövõ kerül be, helyettem, a régóta váró helyett. Illetve, van egy sorban áll* is. Mi plusz ez a csillag?
A prioritás: miért van, hogy egyeseknél normálisan várok a sorban, mégsincs semmilyen érték itt? Illetve, a QR-nél jó vagy roszz a nagy érték? Vagyis, akkor kezd tölteni nekem, ha az én értékem a legnagyobb, vagy a legkisebb?

Még egy kérdés, ami ugyan nem olyan sürgõs még, de úgy tûnik, szeptemberben rooter mögé kerülök, és jó lenne tudni, mely portokat kell forwardolni a rooterben, hogy ne legyek low id-s, és jól menjen minden. Láttam a leírásban egy rakat ilyen portot, de a fene tudja, ténylegesen melyiket használja.

[keeper2]

Oh, és most írta a rendszer az alsó sorban, meg a naplóban, hogy new message form XY. Átnéztem az egész klienst, de nem találom, hol lehetne az üzenetet megnéznem. Még az ügyfelek közül is kikerestem azt az emberkét, hátha a jobb gombos menüben meglesz, de ott sincs infó az üzenetrõl.

[ERROR 404]

Idézet: keeper2 - Dátum: 2005. aug. 20., szombat - 15:37

Oh, és most írta a rendszer az alsó sorban, meg a naplóban, hogy new message form XY. Átnéztem az egész klienst, de nem találom, hol lehetne az üzenetet megnéznem...

A Fö abalakban (tehát ahol a letöltéseidet látod), van felül egy ikonsor.
Ha nem piszkáltál el a kliensben semmit idevonatkozólag, akkor az lesz az egyik kis ikon alá irva (amin talán emberkék vannak), hogy: Üzenetek
Ez valahol középtájon van, ha minden igaz.


Ha ide kattintasz, akkor bal oldalon a haverok listája, alul az üzenöablak beviteli sora (ahová irod az üzit), felette meg a szöveg, amit küldtek neked, azaz az üzenöablak.
A tetején van a Nick-je a figurának, aki megkeresett.

Ha azt látod, hogy már no connected, vagy efféle, akkor sincs gáz, mert lehet, hogy mág a renszerben van, csak már becsukta az ablakot.
Irj neki vissza, hátha ott van még.

Vélhetöen azt akarja (gondolom), hogy adj már neki slot-ot, akkor elsöként tedd a barátoddá (ha még nem az), majd itt az üzenöablak bal oldalán lévö listában (a nevére jobb click-kel kibontva) adhatsz neki slot-ot, vagy ha együtt töltesz vele, akkor a föablakban az adott fájlnál kibontva megteheted ugyanezt.

[ERROR 404]

Idézet: keeper2 - Dátum: 2005. aug. 20., szombat - 11:47

"Na egy pár kérdés:..."

Nem, ez nem "egy pár kérdés", ez kérdés-áradat!  :o

Idézet

"Miért van az, hogy a beállításokban a test ports-ra kattintva..."

Ehhez a "Peerguardian + eMule + TCP Connection Test" -témakörhöz itt a fórumon nem nagyon fogunk tudni neked okosságokkal és újdonságokkal szolgálni, erös a gyanúm, hogy ilyen felállásban az ide benézö eDonkey/eMule-Userek nem tevékenykednek.

Kézenfekvönek gondolom, hogy utánanézhetnél eMule/eDonkey-FÓRUMOKON a problémádnak.
(pl. Google -> eMule+Forum+Peerguardian -szüréssel keresgélni.)

Idézet

"Ha netán uninstallálom, majd újrainstallálom az emule-t, akkor melyik az a fájl, amit el kell másolnom, amiben az aktuális letöltés alatt álló fájlok vannak?"

Ez a téma << Mp3Pintyo-fórumtársunk saját fórumán >> ( << Van Zan -szaktárs FAQ-jában >> ) elég jól ki van vesézve:

---------------------------
Idézve onnét:

"Az eMule-könyvtáron belül található Config-könyvtárban található fájlok közül meg kell tartani a következöket:
- clients.met
- preferences.dat
- cryptkey.dat

- emfriends.met (ha meg akarjuk tartani a barátok listát)
- known.met (ha nem tartod meg, az emule újrahash-eli a megosztott fileokat)
- preferences.ini (a Preferences beállításai)
- server.met (a szerverek listája)

Az elsö 3 file feltétlenül szükséges ahhoz, hogy az azonositás sikeres legyen, és a kreditek megmaradjanak."
----------------------------

A kérdésedhez kiegészitésképp:
Ezek a lecserélendö fájlok az eMule-részét képezik, tehát a megosztásodban lévö (akár teljesen meglévö, akár részben letöltött, azaz: .part-formátumú) fájlaidat nem érinti!
Ahogy a kliensprogramod beállitásainál is kitünik, azt Te adod meg, hogy hová gyüjtögesse a leszedendö cuccokat és azt is, ahol azokat a fájlokat tárolod, amiket Te magad osztasz meg, azaz komplettek.
Ha ez a két "kupac" nálad ugyanaz a könyvtár, akkor egy helyen van az egész bagázs, de ha kicsit rendet tartasz, akkor létrehozol egy saját könyvtárat a meglévö fullos megosztandó dolgaidnak és az éppen érkezöknek. Az elöbbibe másolódnak majd automatikusan azok a fájlok is menetközben, amik érkezésük alatt a másik könyvtárban várják a hiányzó szeleteket.
Tehát ezek nem sérülnek a kliensed frissitésekor.

Ha jól rémlik, akkor a Bináris-állapotú kliensek frissitésénél elég a szükséges fájlokat felül irni, tehát ott még install/uninstall sincs.

Idézet

"Sajna totál gyökérül van megoldva. Dc-ben legalább..."

Hát, ha Te mondod, akkor biztosan igy van , csak akkor azt nem értem (de szerintem más se), hogy miért az eMule-t erölteted?!  :confused:
A DC ezek szerint jobban megfelel az igényeidnek, ilyen szemellenzös hozzáállással  én a helyedben inkább azt használnám, még akkor is, ha "itt" elöfordulnak olyan dolgok, amik a DC-n momentán nem elérhetöek!

Még aktuális a régi mondás: "A számitógép utasitásaid és nem kivánságaid szerint müködik!"

Idézet

"...eddig azt gondoltam, azért van a fájl lista letöltés megszoítás, hogy ezzel az anonimitást segítse elo, és ezért fogadtam el, hogy jó ötlet. De ha ott az ip, akkor semmit nem ér a dolog..."

Szerintem ezt nem Te gondoltad, hanem akik magyarázni próbálták, hogy ez itt eleve nem igy müködik, ök hozták fel érvként, csak azt nem akartad/akarod valahogy felfogni, hogy itt nem könytárakba gyüjtött anyagokra mozdulsz rá, hanem minden egyes rohadt fájlnak egyedi azonositója van, és minden szir-szart egyenként ér el és kezel a rendszer.
Próbáldd már végre megérteni, hogy itt vannak az egyéneknél komplett fájlok, ezek felett ö rendelkezik, és vannak mozgásban lévö (szétszeletelt) fájlok, amik viszont mindenki számára, aki letölteni szeretné, elérhetö.
Más bontás nincs, és a müködési elböl adódóan nem is lehetséges.
Ha az lenne itt, amihez olyan görcsösen ragaszkodsz, akkor hiába lenne egy letöltési kivánságlistád pl. Tölem, ha a következö alkalommal kiszedek néhány fájlt a megosztásomból, akkor amire hivatkoztál elözöleg, már nem elérhetö.
Azon túl persze, hogy eleve nem engedek kotorászást a megosztásomban, tehát semmiféle komplett kivánságlistát nem tudsz magadnak eleve magadnak összeállitani.

Idézet

"Az állapotnál a sorban áll az egyértelmu. A sor megtelt már nem annyira. Mi a fene van ilyenkor?"

Ahogy sok más letölteni szándékozó, Te is kéréssel fordulsz (a kliensed utján) a számodra szükséges szeletekkel rendelkezö felhasználók felé.
Akinek ilyen értékes szelete van, annak a kliensprogramja eldönti, hogy: "kinek adjon szeletet a tortából", azaz kiknek töltsön fel ELÖBB, a többi érdeklödö kiszolgálása elött.
Ez annyiból fontos ill. elönyös, hogy ha Te adsz nekem, akkor az "én is adok Neked"-elv érvényesül, azok hátrányára, akik önzö módon inkább csak kapni akarnak.
Természetesen a várakozási idö is befolyásolja a prioritást, ill. az is, ha cimbora kerül a képbe, mert akkor a sorrakerülést némileg felülbirálva kedvezhetsz neki (és ö neked ugyanigy viszont).
Esetedben azt látod, hogy amire várakozol, ott hányadiknak fogsz sorrakerülni.
Nem kell betojni, ha kurva magas ez a szám, viszont olyan egyénnél állsz sorba, akinek  vannak számára értékes szeleteid, hisz' ö meg látja, hogy Téged érdemes mások elé engedni.

Ha azt látod, hogy betelt a sor, akkor tényleg az van, hogy: "kurva sokan állnak a mozipénztárnál".
Ezt a várakozási sort (ahol a nálad kuncsorgó partnerek sorakoznak) amúgy mindenki maga állitja be, hogy mekkora legyen, tehát lehet, hogy még csak párszázan várakoznak, és Te már csak egy "sor megtelt"-et kapsz, lévén a rövidre szabott sora megtelt.
Hogy mi értelme van a rövidre szabott sornak?
Elöfordulhat, hogy valaki régebbi op.rendszerrel használja az eMule-t, igy elképzelhetö, hogy neki akkor müködik a progi stabilabban, ha némiképp megkurtitja a beállitási alapértékeket.

Olvasd át Mp3Pintyo Fórumán << Petikey-szaktárs disszertációját >> a kérdésröl.



Némi saját kiegészités:
Érdemes a fö letöltési ablakot úgy nézegetni, hogy a Prioritás-szerint állitod be a rendezést, igy látod tisztán, hogy mikor kerülsz sorba és kiknek érdemes kedvezned.
Minél kisebb a QR (Queue Rating), annál jobb a státusod nála épp, azaz ha lecsökken 1-re az érték, akkor Te fogsz nála következni.
Ha mondjuk ez a QR pl. 50, akkor sem kell pánikolni, mert a gyorsan feltölteni képes Userek hamar feltolják a szeleteket a várakozóknak, tehát nem érdemes úgy számolgatni, hogy pl. 50x 10 perc, mire sorrakerülök, mert tényleg gyorsan tud némelyik tag tölteni, másrészt ez példa szerinti 50 sem szokott teljesülni, hisz' sokan kilépnek a sorból, ill. mások elé kerülhetsz a jobb pontértékeddel, stb. stb.

[keeper2]

Egyenlõre még a linkeken a dokumentációt nem olvastam át, csak azért írok, mert kissé félreértettél néhány mondatot, meg amellett én is erõsebb kifejezéseket használtam, mint amik oda illettek volna. Amúgy, tényleg jó sok kérdés volt, ezt megvallom, bár, írás közben jutottak eszembe az egyre újabb kérdések.
A test ports kérdés nem is olyan túl lényeges, lévén, így is jól mûködik, high id-vel, csak a kiváncsiság hajt, hogy miért van, hogy csak egy ip filter progi van bent, az sem mutat semmi olyan jelet, hogy valamilyen kommunikációját megfogná a proginak, és mégis kapok egy nagy piros X-et. De majd, ha lesz idõm, utánanézek.
Elösször azon kaptam fel a kívántnál jobban a vizet, hogy egyszerûen olyan neveken szerepelnek a fájlok, és a tartalmuk alapján sem megítélhetõek, hogy nem tudtam eldönteni, mely fájl mit tartalmaz (kivéve a pref.ini). Bocsi, hogy a dc-t hozom fel ellenpéldának, de a download.xml eléggé beszédes név, benne xml formátumban a tartalom, így, volt amikor két gépen is használtam dc-t, és egyszerûen egy szövegszerkesztõvel másolgattam a letölteni valókat egyik gép listájából a másikéba.
Egyébként használok még ma is dc-t, de nem csak azt. Két gépem van. Az egyiket napközben használom, ezen emul van, a másik, egy régi "elavult" gép pedig éjszakára, ezen pedig dc. Már nagyjából kitapasztaltam, hogy mit kell emule-ban keresni, és mit dc-ben. Sajnos az a szánalmas, hogy bár mindkettõ letöltési sorába raktam eszméletlenül sok letöltésre váró anyagot, mégis, bár nem régóta megemelt a sávszélességem, és így jöhetne vagy 250Kbájttal az adat, mindkettõnél az átlag olyan 25-30 K, amennyivel összesen tud letölteni jópár óra futás után is... Ahogy nõnek a netsebességek, úgy lesz egyre lassabb a letöltés egy átlagos eltejedésû fájlra, azthiszem. Pl. az emule-ban épp az egyik fájl: források: 498+500+94(2), és bár ott fut kb 10 órája, mégis kb 2-5K-val jön az adat. A dc-re már kimondták egyesek, hogy túltelített, és emiatt olyan lassú és nehézkes a letöltés, de az emule-nak mi a mentsége???
Ops, jut eszembe, nemrég olvastam egy felhívást, ami szerint az optimális magyar fájl megosztót próbálják létrehozni. Úgy képzelték el, hogy az emule-t kellene alapul venni, azt átformálni úgy, hogy a magyar felhasználókat illetve fájlokat elõnyben részesítse, illetve jól megoldják a sok ember közötti csevegést, stb.
A fájllistánál most egyáltalán nem arról írtam, amire te céloztál. Eddigiekben úgy olvastam ki mások szavaiból, hogy az, hogy jobban el vannak a fájlok rejtve azt segítik elõ, hogy anonimabbak maradjanak az emberek, ellenben, mivel ott írja lazán az ip címét az egyénnek, így anonimitás az egy csöpp sincs a dologban. Egyébként, ha már így említed, tényleg megvan az a probléma a dc-ben, hogy kiszedik a megosztásból azt a fájlt, amit elkezdtem tölteni, ellenben az automatikus alternatíva keresés ezt próbálja kompenzálni. Az emule bezzeg sokkal komolyabb problémát rejt e téren, hiszen, ha kiszedik a félig letöltött cuccokat a megosztók, akkor is, a félig töltött fájlok egyre tovább terjednek, és akár a teljes emule közösség átveheti, ellenben, az eredeti forrás hiányában csak a félkész terjed el, és sosem lesz meg senkinek egészben. Legalább a dc-ben nem terjed tovább, ha már befejezni képtelen a rendszer.
A várakozási sornál sokkal részletesebben közölted is, mint azt én kérdeztem, pár már általam is jól ismert dolgot is elmagyaráztál. Itt leginkább csak az érdekelt, hogy ahhoz, hogy sorra jussak, a legkisebb vagy a legnagyobb QR kell-e, illetve, hogy a megtelt sornál hogyan megy a dolog, mivel elméletem szerint, ha a kliensem próbálkozik X idõben, és legközelebb X+10 idõben, és közben X+5 idõben csökken a várakozók sora, akkor az X+7-kor jövõ másik kliens fog bekerülni a várakozók közé, ellenben én X+10-kor újra próbálkozva megint csak teli sort találok. Vagyis, extrém esetben teli sornál lehet, hogy pont olyan szerencsétlenül jön ki, hogy sosem kerülök be a sorba, hogy aztán a sor elejére érve megkezdõdjön a letöltésem, ellenben, nálam késöbb érkezõk jönnek elég. Így a teli sornál nagyban hasonlóan viselkedik az eredeti dc mûködési elvével, vagyis, aki épp a jó pillanatban próbálkozik, az nyer, nem pedig, aki régebb óta vár.
Köszi, hogy foglalkoztál a kérdéseimmel, jó hosszan sikerült is.
Még egy kérdésem lenne: ha sorra jutok valakinél, és mondjuk van neki sok száz szelete olyan fájlokból, amik kellenek nekem, akkor onnéttól elvileg folyamatosan tölthetek tõle, és addig foglalom a slotját a másiknak, amíg mindet le nem töltöm (vagy amíg valamelyikünk ki nem lép). Tehát, így ha jól értelmeztem a dolgokat, akkor csak úgy halad gyorsan a QR, ha a letöltõk csak kevés szeletet igényelnek a feltöltõtõl.

[shoto]

Idézet: Hülyesamu - Dátum: 2005. aug. 19., péntek - 15:31

Semmilyen hálózati eszköz sincsen útközben? Az ADSL-t nem ismerem, de ott szokott lenni valamilyen kis falidoboz, mittudomén. Hogyha az címfordítást végez, pl. te a helyi hálós 192.168.xxx címen éred el õt, akkor ott a gond.
A géped más módon tud szerver lenni, azaz bármilyen más módszerrel "látod" kívûlrõl? Pl. wigwam port-teszt mit mond? Látja a gépedet?

Nem ADSL hanem KábelNet, de a kábelmodemen és a hálókártyán kívûl nincs semmilyen más eszköz. Kipróbáltam a wigwamot azt irta az összes portra, hogy a port láthatatlan, de ha kikapcsoltam a tûzfalat és úgy próbáltam meg, akkor is azt irta ki kivéve egy portot amire azt írta, hogy látható de nem válaszol. Viszont telepítettem a cFos-t csak kiváncsiságból és a traffic shaping beállitásnál kiír egy routert. De hogy ez hol van azt nem tudom. Talán a szolgáltatónál?

[ERROR 404]

Idézet: keeper2 - Dátum: 2005. aug. 20., szombat - 20:08

Még egy kérdésem lenne: ha sorra jutok valakinél, és mondjuk van neki sok száz szelete olyan fájlokból, amik kellenek nekem, akkor onnéttól elvileg folyamatosan tölthetek tõle, és addig foglalom a slotját a másiknak, amíg mindet le nem töltöm (vagy amíg valamelyikünk ki nem lép).

Az eMule/eDonkey-rendszer szabványos méretü 9.2 - 9.3MB-os szeletekre (Chunk-okra) bontja a megosztandó fájlt ugyebár.
Amint a kliensprogramod eléri az "adag" méretét feltöltéskor, a soron következö ügyfélhez fordul (akinek eddig 1 volt a QR-je), hogy öt szolgálja ki, a forgásnak megfelelöen.
Ha alaphelyzetböl nem lenne meg ez a porciózgatásos-kiszolgálás, akkor Te a büdös életbe nem kerülnél sorra azoknál, akiktöl csak kérni tudsz, de adni nem, hiszen szinte mindig jönne valaki, aki eléd kerülne, és ha nem lenne feltöltési kikapcs., akkor azok töltögetnének nap estig, Te meg csak várakoznál (több tiz, vagy száz sorstárssal együtt).
Tehát van ez a forgásos-rendszer, ahol lassan-lassan mindenki sorrakerül, ki elöbb, ki utóbb.
Persze jobb lenne a letöltöknek, ha nem "zárnák el a csapot" a megosztók az elnyert Chunk feltöltése végén, ilyenkor jöhet jól az, hogy a neked feltöltö User a "barátjává jelöl" Téged a kliensében, és ad neked plusz Slot-ot, azaz kb. soronkivüliséget.
Ilyenformán elképzelhetö, hogy "zúdul a manna" egészen addig, mig le nem jön az egész, de ez értelemszerüen nem Töled függ, aki csak fogadja az adatokat, hanem a részedre feltöltö képes erre.

Szerencsés esetben ez persze spontán úgy is elöfordulhat, ha a feltöltönél senki nem áll sorba rajtad kivül.
Ekkor automatikusan jön a cucc, vég nélkül.

Ritkább dolgoknál ez a folyamatos töltögetés tehát a kulcs a minél gyorsabban befejezett letöltéshez, népszerü fájloknál nem gond, ha csak szeletek (vagy még kisebb részek) jönnek, mivel ott a sok résztvevö miatt nagy a forgás, és mindig van kitöl letöltögetni.


Ha valakitöl töltesz, és nem jön le az egész szelet, hanem csak pl. másfél Megabájt, miközben a feltöltö partner újabb klienshez fordul, az azért is lehet, mert a feltöltöpaertnerednél át van állitva a kliensprogija beállitása egész Chunk-ról, igy nem törekszik az Ö kliensse arra, hogy téged, mint épp soron lévöt szolgáljon ki, hanem elönyben részesit menet közben olyan partnert, aki számára kedvezöbb.
Ez ellen nem tudsz mit tenni. Ha majd tudsz adni is, akkor nem nagyon fognak ilyenek zavarni, hisz' néhány partnernél nyilván barát-listán leszel, kölcsönös érdekek révén.

[ERROR 404]

Idézet: shoto - Dátum: 2005. aug. 20., szombat - 20:28

Nem ADSL hanem KábelNet,...

Sok újat én sem tudok kitalálni vagy javasolni:

Feltelepitve az eMule, a beállitásainál az összes lehetséges port engedélyezve.

Próbaképpen a tüzfalat kikapcsolni (az összes ki és bejövö dolgot engedélyezni, majd megpróbálni kapcsolódni egy szerverre (nem Fake-szerverre!).

Ha LowID-t jelez, akkor kapcsolódni egy másikra, ha ott is alacsony, akkor egy harmadikra.
Néha elöfordul, hogy egyik-másik szerverre történö csatlakozásnál LowID-vel problémázik (tehát megfelelö kliens-beállitással is), bár ez nagyon ritka, és egy újabb szerverre történö kapcsolódásnál már nincs ilyen probléma.

Ha még mindig alacsony, akkor a legkézenfekvöbbnek az tünne, ha valakit az adott körzetböl (ahonnét netezel) megkérnél erre, hogy próbálja ki az eMule-t, hogy nála mi a helyzet.

Idézet

"A 4662, 4672-es portokat beállítottam a tuzfalon de igy is csak LowId..."

Ez idáig rendben van, de az eMule kliensed bállitásánál a Kapcsolat-részben is megadtad ezeket az Ügyfélport-nál, ugye?