2)
A folyamat és az aktuális helyzet
3)
A részvétel
4)
A szoftver (azaz kliens)
5)
Technikai részletek és mindeféle egyebek
1.1) Egyáltalán mi ez a Bovine RC5-64 Projekt?Ez a distributed.net egyik projektje, mely 1997 márciusában szerveződött, hogy részt vegyen az RSA által meghirdetett Secret Key Challenge versenyben. A distributed.net-en keresztül a Bovine Project biztosítja a szükséges szoftvert és hálózati infrastruktúrát, amely az RC5-64 kulcsblokkok szétosztásához és a világ minden részén lévő gépek együttműködéséhez elengedhetetlen.
A Secret Key Challenge 13 különálló, de hasonló feladatot tartalmaz. Miután az RC5-32/12/7 (RC5-56) verseny 1997 októberében sikeresen befejeződött, a Bovine Project teljes erőbedobással az RC5-32/12/8 (RC5-64) feladatra koncentrál. Ez (legrosszabb esetben) 2^64 (18.446.744.073.709.551.616) darab kulcs átvizsgálását igényli annak az egynek a megtalálásához, amellyel a feladat üzenetét titkosították. Ez a hatalmas vállalkozás hatalmas számítási kapacitás összefogását igényli a siker érdekében. A Bovine Project résztvevői a világ minden részéről az interneten keresztül rendelkezésre bocsájtják számítógépeik processzorának felesleges kapacitását, s ezzel segítenek megvalósítani a legnagyobb teljesítményű megosztott számítógépet a Földön!
Tartalomjegyzék
1.2) Miért csinálják ezt?Természetesen igen sok magyarázat képzelhető el, akár annyi is, ahány résztvevő van. Itt van néhány a népszerűbbek közül.
Hogy csináljunk valamit ezzel a számítási kapacitással
Az RC5-56 befejezése után természetes lépés volt az RC5-64 versenyben való részvétel, mivel a meglévő kliensek forráskódja nagyon könnyen konvertálható volt az új feladathoz. Ahelyett, hogy őrült sietséggel elkezdtek volna egy új, általános célú kliens-generációt fejleszteni, a szervezők úgy döntöttek, hogy a szükséges apró változtatásokkal hamar el lehet érni, hogy a korábbi kliens részt vehessen a 64 bites versenyben. A módosított kliensek gyors létrehozásával elérték, hogy az addigi nagyszámú résztvevő érdeklődése töretlen maradt az új feladattal kapcsolatban is.
Hogy bebizonyítsuk a 64 bites titkosítás elégtelenségét
Egy gyengén szervezett csoport az interneten (azaz mi!) megfejtette szabadidejében az RC5-56 kódolású üzenetet. Ez talán elég komoly jelzés az Egyesült Államok kormánya számára, hogy átgondolja a jelenlegi álláspontját a titkosítási technológiákkal kapcsolatban. Az RC5-64 kódolás megtörése (amely elméletileg 256-szor nehezebb) méginkább megerősíthetné ezt a tényt.
Kutatni a hálózati multiprocesszoros együttműködés megvalósíthatóságát
Káprázatos látni, hogy mily egyszerű (és egyben bonyolult is) "egyesíteni" ilyen sok számítógépet, ennyiféle operációs rendszerrel a Föld összes időzónájában egy közös számítási feladat érdekében.
Mert vidám dolog
Talán ugyanúgy, ahogy egyes emberek számára vicces egy tic-tac-toe program megírása a sendmail.cf file-ban (???? ez szószerinti fordítás az eredeti FAQ-ból, gőzöm sincs a jelentéséről), másoknak kielégítő időtöltés részt vennie ebben.
Mert pénzt nyerhetsz
10.000 USA dollár az RSA által felajánlott díj. Az RC5-56 megnyerésekor a distributed.net 1.000 dollárt juttatott a kulcsot megtaláló gép tulajdonosának, 1.000 dollárt megtartott magának, és a maradék 8.000 dollárt pedig felajánlotta a Gutenberg Project-nek. Még nem eldöntött tény, hogy mi fog történni az RC5-64 díjával, de valószínűleg vmi hasonló. Mindenki nyugodtan megteheti ezzel kapcsolatos javaslatait !!ANGOLUL!! a distributed.net levelezési listáin, vagy valamelyik EFNet szerver (hazai versenyzőknek legkézenfekvőbben az irc.bme.hu szerver) #distributed IRC csatornáján.
Mert megismerkedhetsz emberekkel
Megdöbbentő, hogy mennyi - a projektben résztvevő - emberrel találkozhatsz az #distributed IRC csatornán (irc.bme.hu, irc.elte.hu) lógva, vagy a levelezési listákra feliratkozva.
Hogy felkeltsd az ellenkező neműek figyelmét
Szóval, öööö... talán igen, talán nem. Sosem tudhatod ;-)
Tartalomjegyzék
1.3) Kiknek a részvételére számítanak a szervezők?A legkülönbözőbb technikai hátterű és képzettségű emberek vesznek részt a feladat megoldásában. A csatlakozáshoz nem kell képzett programozónak, vagy a titkosításban jártas személynek lenned. Mindössze egy számítógépre, alkalmankénti internet kapcsolatra van szükség és persze lelkesedésre, hogy részt vehess a legnagyobb internetes megosztott számítási projektben! A résztvevő csapatok gyors megszemlélése képet ad a csatlakozott szervezetek, cégek és magánemberek széles skálájáról. Talán fontosabb kérdés az, hogy ki az, aki nem vesz részt! Az erőfeszítés sikere attól is függ, hogy annyi embert szervezzünk be, amennyit csak lehetséges. Csatlakozz még ma, és szólj a barátaidnak, ismerőseidnek is!
Tartalomjegyzék
1.4) Foglalkozik más szervezet is ezzel a témával?Az RC5-56 versenyben két másik szervezet is részt vett, a Cyberian és az Infinite Monkeys. Az RC5-64 jóval (egész pontosan 256-szor) nehezebb feladat. Valószínűtlen újabb szervezetek beszállása a küzdelembe. A Cyberian az elején bejelentette, hogy dolgozik az új klienseken, de végül is ebből nem lett semmi, kiszálltak a játékból. Van egy csoport a MIT-en (Massachusets Institute of Technology), amely egy Java alapú klienssel vizsgálja az RC5-64 kulcsokat, de ők közvetlenül nem vesznek részt a Bovine munkájában, lévén az itteni kliensek specifikációja nem publikus, így nem tudtak ezekhez igazodni, Ők függetlenül dolgoznak.
És végül megemlítendő, hogy volt néhány hasonló erőfeszítés, amely részt vett az első Secret Key Challenge akcióban, amely a DES titkosítás megtörésére irányult. Ezek közül a legnagyobbak a SolNET és a DESCHALL voltak, mely utóbbi 1997 júniusában megnyerte azt a versenyt.
Tartalomjegyzék
1.5) Hogyan kezdődött az egész? Merre tart most a dolog?Az eredeti akció, amely az RC5-56 megnyerésére szerveződött, a New Media Laboratories kezdeményezése volt. Számos belső probléma következtében ők végül is felfügesztették részvételüket a törési versenyben. A New Media kulcsszerver rejtélyes eltűnése után kialakult káoszban Jeff Lawson (becenevén Bovine), egy diák a Harvey Mudd kollégiumból megalkotta a Bovine Proxy Keyserver programját, amelynek legnagyobb jelentősége abban állt, hogy lehetővé tette a New Media eddigi eredményeinek folytatását, a befejezett kulcsok tárolását mindaddig, amíg a New Media szerver vissza nem tér a hálózatba. Miután egyértelművé vált, hogy ez nem fog megtörténni, a Key Server-t módosították úgy, hogy ez lett a központi koordinátor, teljes egészében átvéve az egész erőfeszítés irányítását.
Amikor az újraformálódó - most már Bovine néven futó- projekt elkezdte gyűjteni a tagokat és ezzel az egyre nagyobb számítási kapacitást, felmerült, hogy egy nagy és megosztott (distributed) számítógép (mint ez) alkalmas lehet különböző feladatok megoldására, olyanokéra is, amelyeknek semmi közük az RC5-höz, vagy egyáltalán akár a titkosításhoz. 1997 novemberében ennek a távlati célnak a szem előtt tartásával jegyeztették be hivatalosan is a distributed.net-et, mint nonprofit szervezetet (Distributed Computing Technologies, Inc. = DCTI).
Ugyancsak ezen célkitűzésnek megfelelően kezdték el a következő - version 3, vagy csak egyszerűen v3 jelű - általános célú kliens generáció tervezését. A v3 kliensek modulárisak lesznek, és ezzel alkalmasak többféle, feladatspecifikus számítási alkalmazásra. Az elkészülő v3 kliens és proxy hálózat lehetővé teszi majd a distributed.net számára, hogy egyidőben részt vehessen sokféle független projektben. Néhány megfontolásra váró feladat már most is megtekinthető a "Jövőbeni projektek" oldalon.
Tartalomjegyzék
1.6) Miért pont a tehenek/lepkék?Erre esetleg Jeff "Bovine" Lawson, RC5 főkoordinátor tudna válaszolni.
Tartalomjegyzék
2.1) Honnan szerezhetek több információt?A "distributed.net" központi oldala http://www.distributed.net címen található meg, az RC5-64 projekttel kapcsolatban részletes anyagok olvashatóak az RC5 oldalakon és természetesen ebben a FAQ-ban a hátralévő részben :-).
Ezen kívül üzemeltetnek egy többnyire igen életteli IRC csatornát (#distributed) az EFNet IRC hálózatán (itthon az irc.bme.hu, irc.elte.hu is szolgáltatja ezt) !!ANGOL NYELVEN!!. A Distributed.net sok "fontos embere" megtalálható itt, és a beszélgetések akkor is elég színvonalasak (egy általános IRC csatornához képest), ha éppen nem az RC5, vagy a Distributed.net a téma. Igen sok technikailag képzett fickó szokott a csatornán lógni, és általában akad vmi érdekes megjegyezni való infó.
Van aztán néhány nyilvános !!ANGOL NYELVŰ!! levlista is (online archívummal), melyek a következők:
Lista neve Leírása announce hivatalos bejelentések és általános információk, moderált. rc5 beszélgetés az RC5-ről, moderálatlan. rc5-digest az előző lista teljes forgalma "digest" formában, mivel az rc5 forgalma naponta 50...100 levél is lehet. rc5-proxyper a "personal proxy keyserver" szoftverrel kapcsolatos lista Ha jelentkezni szeretnél valamelyikre, akkor küldj egy emailt a majordomo@lists.distributed.net címre a levéltestben (Body) a subscribe listanév szöveggel (Subject maradjon üres!).
És természetesen ne felejtkezzünk el a magyar nyelvű résztvevők számára legfontosabb fórumról, a STB+ csapat saját levelezési listájaról, amely zártkörű (csak a tagok olvashatják és írhatnak rá), kereshető archívummal. Információ itt.
Tartalomjegyzék
2.2) A statisztikai adatok magyarázata.!Figyelem! Az alábbiakban leírtak most átmenetileg nem felelnek meg a valóságnak, mert a régi statisztikai szerver - melynek formátuma alapján a leírás készült - már nem üzemel, az új pedig még csak részfunkciókkal fut. Az igéretek szerint az összes korábbi funkció elérhető lesz, de amíg az egész szolgáltatás be nem indul, nem írom át az alábbiakat.
A "Bovine" hivatalos online statisztikai oldalai a http://rc5stats.distributed.net/ címen tekinthetőek meg összegzett formában, vagy akár csapatonként, egyénenként is részletesen. Az oldalak minden nap (greenwich-i idő szerint, GMT) 0:00 órakor, azaz csak egyszer frissítődnek. Az egyes megjelenített értékek projekt/csapat/egyéni szinten a következők:
Current Ranking (aktuális helyezés)
Ez mutatja, hogy az adott csapat, vagy személy a többi csapathoz, vagy személyhez képest hogyan áll a projektben (ezt talán nem kellett volna magyarázni, de hát a fordítás lendülete, ugye ... :-)
Total blocks to search (az összes átvizsgálandó blokk)
A teljes RC5-64 kulcstér kb. 18 millió millió millió kulcsot tartalmaz, melyeket kulcsblokkokba(=blokk) szerveztek. Minden ilyen blokk 2^28 (268.435.456) kulcsot tartalmaz, és 2^36 (68.719.476.736) blokk adja a teljes mennyiséget. A statisztikák alapja a blokk.
Total blocks checked (az összes már átvizsgált blokk)
Az eddig már átvizsgált és a Bovine kulcsszerveréhez visszaküldött összes blokkok mennyisége
Keyspace exhausted (kiürített kulcstér)
A teljes kulcstér azon százaléka, amelyet a már átvizsgált blokkok alkotnak
Total keys checked (az összes átvizsgált kulcs)
Az eddig már ellenőrzütt kulcsok mennyisége, mely számadat megegyezik az ellenőrzött blokkok számának 2^28-szorosával
Time working (a munkás napok száma)
Azon napok mennyisége, amelyet az egész projekt, egy adott csapat, vagy személy ezzel a feladattal eddig eltöltött.
Overall rate (átlagos sebesség)
Az átlagos sebesség (kilokulcs/másodperc), amelyet a teljes projekt, egy adott csapat, vagy személy elért a részvétel kezdete óta.
Keyblocks and keyrate for yesterday (tegnapi blokkszám és sebesség)
Ez az érték az előző 24 óra (pontosabban 0:00-tól 0:00-ig) során beküldött blokkok mennyiségét és az ennek alapján számolt átlagsebességet mutatja.
Tartalomjegyzék
2.3) Hogyan léphetek kapcsolatba a "Bovine Projekt" szervezőivel?Erre a legjobb módszer a #distributed IRC csatornára való ráugrás az EFNet IRC hálózatán (akár irc.bme.hu, irc.elte.hu), ha azonban jobban szereted a magánbeszélgetéseket, akkor megpróbálkozhatsz az alábbi email címek valamelyikével, de !!KIZÁRÓLAG ANGOL NYELVEN!!
RC5 általános segítség
Kliens és personal proxy kérdések
- help@distributed.net
A projekt statisztikáival kapcsolatban
- nugget@distributed.net
A distributed.net általános koordinátora
- beberg@distributed.net
Tartalomjegyzék
3.1) Mit kell tennem?Röviden mindössze arról van szó, hogy a gépeden futtatnod kell egy speciális, kifejezetten erre a célra kifejlesztett szoftvert (röviden kliens), és alkalmanként az interneten keresztül csatlakoznod kell a "Bovine Projekt" által üzemeltetett valamelyik kulcselosztó szerverhez (proxy keyserver).
Amikor a klienst első alkalommal elindítod, akkor kapcsolatba lép a megadott kulcsszerver-rel az interneten, és letölt bizonyos - a konfigurálás során általad meghatározott - mennyiségű blokkot. Ezután - már a hálózati kapcsolat szükségessége nélkül - elkezdi ellenőrizni a blokkokat alkotó kulcsokat egyesével, keresve azt a bizonyosat, amellyel a megfejtendő mondatot az RSA ravasz fickói kódolták. Amikor az összes blokkot végignézte, az eredményt visszaküldi a kulcsszervernek és letölt egy újabb adag blokkot (ebben a lépésben természetesen ismét internet kapcsolatra lesz szükség.
Modemes felhasználók jogosan kérdezhetik meg, hogy milyen gyakran lesz szükség a hálózati kapcsolat biztosítására?
Az egy blokk átvizsgálásához szükséges idő a processzor típusától függ, és igen tág határok között változhat: nagyon lassú rendszereken akár 12 óra is lehet az egy blokkra jutó idő, amely esetleg egy gyors multiprocesszoros gépen mindössze 3 percet vesz igénybe. Felhasználók által beküldött tájékoztató adatok találhatók a legkülönfélébb konfigurációkra a "Kliens sebességek" oldalon.
A kliens működéséről továbbiakat olvashatsz még a "Konfigurálás" oldalaink 8. pontjában.
FONTOS! A kliens futásának fontossága (prioritása) alapesetben úgy van beállítva, hogy teljesen a háttérben marad, minden más futtatott alkalmazás elsőbbséget élvez vele szemben, a processzor csak akkor foglalkozik a kulcstöréssel, ha éppen semmi más dolga sincs, ha éppen szünetet tartasz a munkádban. Tehát röviden: a kliens futását szinte észre sem fogod venni.
Tartalomjegyzék
3.2) Mire van szükségem?Az eddigiekből már esetleg kiderülhetett, hogy mindössze egy számítógépre van szükség, és alkalmankénti internet kapcsolatra (elegendő akár csak hetente 1x!)
Tartalomjegyzék
3.3) Hogyan juthatok hozzá a kliens szoftverhez?A kliensnek a Te gépeden futó operációs rendszernek megfelelő verzióját megszerezheted a hivatalos kliens oldalakról (USA), illetve a STB+ kliens oldalairól is. A kinti oldalak biztos, hogy mindig a legfrisebb verziókat tartalmazzák, de igyekszünk mi is max. 1-2 nap késéssel követni a változásokat.
Ha esetleg nem találnál a hivatalos oldalakon az általad uralt platformra való klienst, akkor azt nem is fogod meglelni sehol sem. Ebben az esetben egyetlen egy dolgot tehetsz: jelezd ezt az igényedet a "kliens igénylés" oldalon.
Tartalomjegyzék
3.4) Mi történik akkor, amikor megvan a kulcs?Amikor a kliens megtalálja azt a kulcsot, amely helyesen fejti vissza a titkosított üzenet első néhány byte-ját, akkor rögtön küld egy riasztást a Bovine szervezőinek (az üzenetnek a következőképpen kell kezdődnie: "The unknown message is: ...", azaz "Az ismeretlen üzenet a következő: ..."). Egy külön szoftverrel ők megkísérlik a teljes üzenet dekódolását, és siker esetén értesítik az RSA-t. Miután az RSA visszaigazolta a megfejtés helyesség ét, hivatalosan bejelenti az eseményt mind a "Bovine", mind az "RSA", és a felajánlott pénzdíjat postázzák a projekt szervezőinek, akik szétosztják azt a korábban vázoltaknak megfelelően.
Tartalomjegyzék
3.5) Honnan fogom megtudni, ha az én gépemen bukkant fel a kulcs?Kezdetben sehonnan. A programozók úgy írták meg a klienst, hogy semmiféle jelzést ne adjon, ha egy valószínű kulcsra bukkan, s ennek több kézenfekvő oka is van.
Az egész projekt sikeressége érdekében teljes ellenőrzést szeretnének a szervezők a győztes kulcs sorsa felett mindaddíg, amíg az RSA vissza nem igazolja azt. Másodsorban talán sok résztvevő nem igazán örülne, ha a kliens a kulcs megtalálásakor elkezdené játszani mondjuk a "Boci, boci, tarka ..." kezdetű dalt, mivel esetleg futtatja azt az irodában a titkárnők, esetleg a főnöke gépén is, és nem igazán lenne szerencsés a figyelem ilyen jellegű felkeltése. És végül, mivel a kliens csak az üzenet legelső darabkáját fejti vissza elméletileg lehetséges vakriasztás is (bár ez nagyon valószínűtlen!), és nincs szükség feleslegesen felizgatott emberekre a hivatalos visszaigazolás megérkezéséig.
Amennyiben a Te géped lelte meg a győztes kulcsot, az RSA hivatalos jóváhagyása után email értesítést fogsz kapni arra a címre, amelyet a kliens indítása előtt a konfigurálás 05/1 pontjában megadtál.
Tartalomjegyzék
3.6) Szükséges a részvételhez a folyamatos internet kapcsolat?Egyáltalán nem! A kliensek megadható akár 1000 blokk letöltése is, amellyel aztán hosszú napokig elvan, sőt amennyiben ezeket mind átvizsgálta volna a következő internet kapcsolat ideje előtt, akkor véletlen blokkokat fog generálni és ellenőrizni mindaddig, míg újabbakat le nem tud tölteni a kulcsszervertől.
Tartalomjegyzék
3.7) Vajon jó az én modemem, vagy gyorsabbra volna szükségem?Minden modem megfelel a célnak, mivel a kliens csak a blokkok átadás/átvételekor lép hálózati kapcsolatba, és akkor is igen csekély adatmennyiséget kell továbbítania/fogadnia (kb. 125 byte blokkonként), így ez egy lassabb modemmel is nagyon rövid ideig tart.
Tartalomjegyzék
3.8) Tényleg van értelme beszállnom az öreg, lassú gépemmel is?Ahhoz, hogy ésszerű időn belül befejeződjön ez a projekt, a legfontosabb minél több gép beszervezése. A világon lévő öreg 386-os és 486-os gépek serege messze együttesen nagyobb kihasználatlan (idle time) számítási kapacitással rendelkezik, mint a feltételezhetően beszervezhető szuperszámítógépek bármelyike!
Érdemes felidézni, hogy az első DES verseny kulcsának megtalálója egy Pentium 90-es volt, amely FreeBSD operációs rendszert futtatott 16 Mb RAM-mal! És nem vmi hatalmas gyorstüzelő "ruhásszekrény". Mind a 48 bites RC5, mind az 56 bites DES feladat megoldása egy olyan gépen történt, amely nem volt benne a Top20-as statisztikában! Minden gépnek van esélye meglelni a kérdéses egyetlen kulcsot. Minden gép részvétele az erőfeszítésben: nyereség.
DE FIGYELEM! A nagyon régi - a 386-os géposztály előtti - gépek jelenleg nem használhatóak, mert a mostani RC5 algoritmus működése igen erőteljesen a 32 bites adatműveletekre épül, amelyek nem futtathatóak azokon a gépeken.
Tartalomjegyzék
3.9) Nem kerülhetek bajba amiatt, hogy részt veszek a titkosítási kulcs feltörésében?NEM! Ebben az egészben nincs semmi illegális, erkölcstelen, vagy becstelen. Ez egy törvényes, hivatalos verseny, amelyet egy törvényesen bejegyzett és igen jónevű cég (RSA Data Security, Inc.) hirdetett meg és finanszíroz. Az akció során a résztvevők megpróbálnak megfejteni egy titkosított mondatot és ezzel elsősorban tesztelni és értékelni az alkalmazott titkosítási metódus erejét.
Tartalomjegyzék
3.10) Részletesebb ismertetés a csapat(=team) témakörről.Hogy még érdekesebbé tegyék a dolgokat, néhány ember alhatározta, hogy csapatként dolgoznak tovább, egyesítve erőiket, és ezzel megnövelve közös esélyeiket. FONTOS itt megjegyezni, hogy a projekt szervezőinek szándékai szerint ez az egész dolog nem csapatok egymás elleni küzdelméről szól, vagy arról, hogy ki találja meg a kulcsot! Ennek az erőfeszítésnek a lényege az, hogy amatőr internet-huszárok csapata képes megtörni a 64 bites titkosítási kulcsot pusztán a saját meglévő számítási forrásaikat használva.
A csapatba szerveződés csak egy lehetőség, enélkül is részt vehet bárki a versenyben. Érdekes figyelni a csapatok versengését, és a rivalizálás során a folyamatos tagtoborzással az egész projekt folyamatos erősödését segítik. Nincsenek hivatalos csapatok, bár egyesek esetleg azt hangoztatják, hogy az övék az valamely operációs rendszer, vagy géptípus tekintetében. Nem kell csatlakoznod egyikhez sem, futtathatod a klienst egyedül is, vagy csatlakozhatsz bármelyik szimpatikus csapathoz.
Azok számára, akik részt vettek a "Bovine RC5-56" projektben, fontos felhívni a figyelmet, hogy most teljesen másképpen történik a csapathoz való csatlakozás (az STB+ az RC5-56 során a "Cyberian Projekt"-hez csatlakozott, így az itt következők csak történeti érdekességek). Korábban a csapat azonosítása a csapat koordinátorának email címe alapján történt, a csatlakozás az erre a címre beküldött blokkokkal történt. Jelenleg viszont minden résztvevő a saját email címével küldi be a blokkokat, és ezek után kiválaszthatja, hogy melyik csapathoz kíván tartozni. Az egyéni statisztikákban a csapathoz való csatlakozás után is látszani fog ugyanúgy, ott mindig az egyéni teljesítménye lesz megfigyelhető, de a beküldött blokkjai elszámolódnak a csapat számára is.
(Az STB+ tagok most ne figyeljenek ide! :-)
Ha új csapatot akarsz létrehozni, akkor a statisztikai oldalakon a bal oldali kék mezőben kattints a "Register New Team" opcióra, majd olvasd el figyelmesen a megjelenő instrukciókat és cselekedj annak megfelelően.
(még nem STB+ tagok most nagyon figyeljenek!)
Ha egy meglévő csapathoz (hozzánk!) szeretnél csatlakozni, akkor az ehhez szükséges lépéseket szép sorrendben megtekintheted itt, de erre csak akkor van lehetőség, ha már szerepelsz az egyéni statisztikákban, azaz már küldtél be blokkot és azóta már volt egyszer éjfél (ennek semmi köze a fekete mágiához, csupán ahhoz a korábban már említett tényhez, hogy a statisztikákat, naponta csak egyszer, mindig 0:00-kor frissítik, tehát előfordulhat az, hogy a kliensed már kommunikált a kulcsszerverrel, de mégsem látszol a stat-ban).
Még egy tudnivaló a csapathoz való csatlakozással kapcsolatban! Ha először csatlakozol egy csapathoz, akkor az addig tört blokkjaid mind hozzáadódnak a csapat összesítéséhez, míg amennyiben átigazolsz egy másik csapathoz, csak az új blokkjaiddal gazdagítod az új csapatot, a régebbiek az előző "otthonodban" maradnak, a blokkok átírására nincsen lehetőség. Az egyéni statisztikád mindig a kezdetek óta elért eredményedet mutatják, teljesen függetlenül attól, hogy közben milyen csapatokhoz csatlakoztál és hányszor.
Tartalomjegyzék
3.11) Mit NEM szabad tenned!?NEM futtathatod a klienst olyan gépen, amelyik nem a Te tulajdonod, vagy nem Te adminisztrálod. Ha mondjuk egy számítástechnikai boltban dolgozol, akkor - tűnjön bármennyire is cool ötletnek - ne tedd fel minden eladott gépre. A részvétel alapvető szempontja az önkéntesség legyen.
Tartalomjegyzék
4.1) Melyek a támogatott platformok?Ez folyamatosan bővül, nézd meg a kliens oldalak itthoni tükrözését.
Tartalomjegyzék
4.2) Hogyan kell használni a klienst?Erről külön olvashatsz nagyon részletesen a "Konfigurálás" oldalainkon.
Tartalomjegyzék
4.3) Mi a helyzet a rejtett(=hidden) kliens verziókkal?Bizonyos esetekben felmerülhet az az igény, hogy a kliens működését az adott gépet használó többi személy(ek) előtt titokban tartsuk, pl.: nagy géplaborok rendszergazdái esetében, hiszen a sok lamma juzer úgy is több, mint elég hüjeséget szokott kérdezni :-). Különböző rendszerek esetében a következő a helyzet:
MacOS
még nem megoldott(?)
Microsoft Win3.x/95/98
Használd GUI klienst és aktivizáld a Startup menüben a Automatically launch client as a startup service és Run hidden and without a system tray icon opciókat, amelyek hatására a kliens egyrészt automatikusan indul a rendszer felállása után (még a felhasználók belépése [login] előtt) és futása során rejtve marad, nem jelenik meg ott jobbra alul a kis ikon. Ezen opciók beállítása csak a rendszer újraindítása után aktivizálódik! A rejtve futtatott kliens felügyeletére szolgál a letöltött csomagban lévő guictrl.exe segédeszköz.
Microsoft WinNT
egyrészt futtathatod a fennt említett 32 bites GUI klienst, másrészt adminisztrátori jogkör esetén telepítheted a Win32 CLI verziót, mint NT szervízt (Service).
OS/2
mivel alapesetben a rendszer elrejti az alkalmazásokat, egyszerűen csak csukd össze (minimize) a klienst. Az alkalmazás listában (task list) természetesen látszani fog, ennek kiküszöbölésésre add ki a következő parancsot: detach rc5des (ahol az rc5des a futtatott kliens neve, azaz nem feltétlenül pont ez!)
UNIX
általában bármiféle unixos program egy szimpla paranccsal utasítható a háttérben történő futásra: nohup ./rc5v2 > /dev/null &. Ennek hatására a kliens kimenetét (stdout, amely alapesetben a képernyőre érkezne) a "semmibe" irányítja. A & jel (ampersand operator) utasítja az indító shell-t a háttérben való futtatásra, azaz a shell bezárása esetén sem áll le a kliens, a nohup(=no hangup = ne függeszd fel) használatával pedig azt érheted el, hogy kilépésedkor (logout) sem áll le a kliens.
Részletesebb magyarázatokat az adott kliensekhez mellékelt dokumentációkban kereshetsz.
Tartalomjegyzék
4.4) Miért kapok hálózati hiba(=network error) üzeneteket?Ennek a leggyakoribb oka az, hogy tűzfal mögött vagy és a kliensed nem tud közvetlenül kijutni az internetre (lásd a következő kérdést!). Váltakozó hálózati hibákat okozhat a belső hálózatod (LAN) gyengesége, rossz minősége, ócska telefonvonalak (hoppá!!), vagy az internet esetenkénti forgalmi dugói. Némely régebbi kliensek túl érzékenyen reagáltak a hálózati válaszidőkre, s ilyen üzenetet küldtek, ezeket a problémákat mostanra jobbára megoldották.
Tartalomjegyzék
4.5) Mi a helyzet akkor, ha tűzfal(=firewall) mögött vagyok?A kliensek legtöbbje úgy készült, hogy tudjon kommunikálni a hagyományos(?) "SOCKS proxy tűzfal"-on keresztül. Ha még ráadásul "port filter" is van, akkor azt kell tudni, hogy a legtöbb (ha nem mindegyik) kulcsproxy a 23-as (telnet) porton keresztül fog kapcsolatot teremteni. Sok tűzfal mögötti gép esetén célszerű(=legegyszerűbb) felállítani egy "personal proxy"-t, és akkor csak egy gép fog a tűzfalon keresztül kommunkálni, az összes többi ezzel a belső géppel van kapcsolatban mindenféle akadály nélkül. A "personal proxy" szoftver különböző platformokra szintén letölthető a "Bovine Project" megfelelő oldalairól.
Ha a gépednél azt látod, hogy a tűzfal blokkolja a szabad kommunikációt, akkor hasznos lehet megnézni a web-browser (Netscape, Internet Explorer) beállításait, és amennyiben sikerül kifigurázni, hogyan van ott beállítva a dolog, akkor próbáld meg a browser beállításait alkalmazni a kliens esetében is. Például a Netscape4.x esetében az View/Preferences/Advanced/Proxy menüben láthatod, hogy mi az ábra, s általában az ottani beállításokat használva a kliens is jól fog működni.
Tartalomjegyzék
4.6) Többprocesszoros gépem van. Hogyan használhatom ki a klienssel mindegyik processzort?A legtöbb (de nem mindegyik) kliens ki tudja használni a több processzorból adódó előnyöket. Alapértelmezésben (default) csak 1 CPU használódik, ezt az értéket is a konfigurálás 05/43 pontjában leírtaknak megfelelően kell megváltoztatni a helyi viszonyoknak megfelelően.
Tartalomjegyzék
4.7) Hol vannak a kulcsszerverek(=keyserver)?A kliensek legtöbb esetben tökéletesen megelégszenek a alapértelmezett (default) keyproxy használatával, amely az rc5proxy.distributed.net. Ez a cím nem egyetlen gépet jelent, hanem egy proxy-gyűrűt, amelyek közül mindig a forgalom szempontjából legkedvezőbb választódik ki a kliens csatlakozásakor. Földrészenként egy-egy ilyen proxy-gyűrű (round robin) cím van megadva, ezek a következők:
- Európa: rc5europroxy.distributed.net
- Ázsia: rc5asiaproxy.distributed.net
- Ausztrália: rc5aussiepoxy.distributed.net
Ezek használatára azonban csak akkor lehet szükség, ha probléma merülne fel az észak-amerikai szerver elérésével, tehát a magyarországi résztvevők is meghagyhatják az alapbeállítást, és csak gyakori "Network Error" hibaüzenet esetén érdemes megpróbálkozni az európai címmel.
Amennyiben az európai cím megadásával sem oldódanának meg a problémák, akkor meg lehet próbálni megadni egyetlen konkrét proxy címét. Ezeknek a listája megtekinthető a "Proxy Network Status" oldalakon a kinti központban.
Ha konkrét gép nevének megadása esetén is gond mutatkozik a hálózati kapcsolattal, akkor az adott proxy neve helyett adjuk meg a gép IP címét, ez már többeknél sikerrel oldotta meg a kommunikációs problémákat.
Tartalomjegyzék
4.8) Használhatok megosztott buffer file-okat egy hálózaton belül?IGEN! A kliensek direkt ennek figyelembevételével tervezték, és a hálózati file rendszerek által alkalmazott file-rögzítés (file locking) megakadályozza, hogy bármiféle probléma adódhasson a több kliens által egyidejűleg végzett buffer műveletek során.
Tartalomjegyzék
4.9) Több gépen szeretném futtani ugyanazt a klienst egy közös hálózati egységről(=shared network drive). Hogyan konfigurálhatom külön-külön az egyes gépeket?Több lehetőséged is van. Alapesetben a kliens keresi az ".ini" file-t (ahol a konfiguráció értékei tárolódnak), amelynek a klienssel azonos a neve (windows esetében a név előtagja, a ".exe" előtti rész). Azaz amennyiben mondjuk a kliensnek (a futtatható file-nak) a neve rc5des, akkor ez keresni fogja az rc5des.ini nevű konfigurációs file-t.
Ezek alapján az egyik megoldás lehet a közös egységen a kliens több másolatának létrehozása különböző nevekkel és az ezekhez tartozó különböző konfigurációs ".ini" file-okkal.
Másik lehetőség minden gépen az RC5INI környezeti változó definiálása, ugyanis a kliens elsősorban az ezáltal meghatározott helyen keresi az ".ini" file-t (s csak ennek hiányában a futtatási könyvtárban). Ezesetben elegendő a kliens szoftverből egyetlen példány a közös hálózati egységen, és minden gépen az elindított példányhoz tartoznia kell egy ".ini" konfigurációs file-nak, amelynek elérési útvonalát tartalmazza az adott gépen definiált RC5INI változó.
Tartalomjegyzék
4.10) Üzemeltethetek-e saját kulcsszervert?Jelenleg nincs szükség erre, de a "Bovine Project" szervezői köszönik a segítő szándékot! Ha tényleg KOMOLYAN szeretnéd ezt tenni, akkor toborozz olyan baromi sok új embert, hogy az eddigi kulcs letöltési kapacitás már ne lehessen elegendő a kiszolgálásra, és muszáj legyen felállítani másik kulcsszervert! :-)
Tartalomjegyzék
4.11) Mi az az ITAR?International Traffic in Arms Regulation, az amerikai kormány által a nemzetközi kereskedelmet szabályozó rendelkezések összessége, amely többek között limitálja a USA-n kívülre eladott szoftverekbe beépíthető titkosítási algoritmusok erősségét. A Bovine szerint (és nem csak szerintük) ez egyszerűen felháborító, és ennek az egész projektnek a létezése részben annak köszönhető, hogy ezzel is szeretnék felhívni a közvélemény figyelmét erre a problémára. A kulcs gyors feltörésével pedig a felhívni az USA kormányának figyelmét a szabványosnak tekintett 56bites DES (DES = Digital Encryption Standard) elégtelenségére.
Az RC5-64 kliensek nem esnek ezen - jelenleg még érvényben lévő - export korlátozások hatálya alá, mivel ebben a szoftverben nincs használva semmiféle kódoló, vagy dekódoló algoritmus (!). Ezek mindössze a kódolt üzenet ismert első részének ("The unknown message is:") első néhány byte-os darabját vetik össze a kulcsok kipróbálása során megjelenő eredménnyel.
Nem úgy, mint például az igen népszerű, világszerte használt PGP (Pretty Good Privacy) titkosítási program, amelynek pontosan az említett korlátozások miatt létezik külön USA és USA-n kívüli verziója.
Az ITAR-ral lapcsolatban itt tudhatsz meg többet, ha érdekel.
Tartalomjegyzék
4.12) Futtatom a gépemen a klienst. Hogyan tovább?Ezzel kapcsolatban részletesen olvashatsz a Lépésről-lépésre oldalunkon, itt most röviden csak annyit, hogy nézd meg időnként a kliens oldalakat, hogy nincs-e újabb verzió az általad használtnál. Ha van, akkor cseréld le, mert feltehetően nem rosszabb, mint a korábbi verzió :-), talán még gyorsabb is, és esetleg kijavítottak benne bizonyos hibákat. Mondja a hivatalos FAQ, de az igazság és mindannyiunk kedvvéért óvatosságra intünk! Az új kliensek többször jelentettek egyértelmű visszalépést, alkalmanként elképesztő, az alapvető működést megnehezítő hibákkal. Ne frissíts ész nélkül! A STB+ levelezési listájára mindig azonnal megérkezik a kinnti kliens oldalak változásának híre, és ezt 1-2 napon belül követi az itthoni oldalak frissítése is, és itt olvashatsz a bátran frissítők tapasztalatairól is.
Tartalomjegyzék
5.1) Egész pontosan hogyan is működik ez a dolog?A "Bovine RC5-64 Project" piramis architektúrába szervezett kulcsszerverekből és kliensekből áll, a csúcson elhelyezkedő egyetlen központi vezér-kulcsszerverrel (master keyserver), amely nyomonköveti a kiküldött, átvizsgálva visszaküldött és a még ellenőrzésre váró blokkokat. A központi gép alatti szinten állnak a segéd kulcsszerverek (proxy keyserver-ek), amelyek a kliensekkel tartják a kapcsolatot. Ezek a központi géptől nagy blokk-csomagokat szednek le (superblocks), és ezekből hozzák létre a kliensek felé továbbítandó blokkokat (2^28 db kulcs = blokk).
Visszafelé ugyanez történik fordítva, azaz a kliensek a proxy keyserver-eken keresztül juttatják vissza az ellenőrzött blokkokat a master keyserver-nek.
A proxy keyserver-ek ráadásul egyfajta gyűrűs hierarchiába vannak szervezve (round-robin), amely azzal az előnnyel jár, hogy valamelyikük kiesése esetén a kliensek automatikusan egy másikhoz fordulnak a kommunkációval. Ez természetesen csak akkor működik, ha kliens konfigurálása során nem adtál meg egy konkrét proxy-t, hanem meghagytad az alapértelmezett rc5proxy.distributed.net címet, vagy mondjuk az európai nevet adtad meg, az rc5europroxy.distributed.net címet, melyek mind a korábban elmondottaknak megfelelően nem egy gépet, hanem sok proxy láncolatát takarják, melyek közül a kliens a csatlakozáskor mindig a legkönnyebben elérhetőbbet választja ki.
Létezhet még egy másik szint is (bárki számára alkalmazható opció!), a személyes proxy (personal proxy) használata, amely a kliens és a segéd kulcsszerverek (proxy keyserver) között helyezkedik el. Ennek használata elsősorban tűzfal mögötti gépek sokasága esetén indokolt, ekkor a bennti gépek a personal proxy-val tartják a kapcsolatot mindenféle korlátozás nélkül, és csak az az egyetlen gép kommunikál a kinnti világgal. A personal proxy-k a proxy keyserver-től már normál méretű blokkokat kapnak. Néhány csapat szintén használ personal proxy-t oly módon, hogy minden csapattag azon keresztül működve, annak log file-ját használva egyrészt a Bovine-tól független csapat-statisztikát generálhatnak, másrészt megkönnyítik a központi Bovine statisztikai szerver munkáját, harmadrészt pedig némi szabadságot biztosít az adott csapatnak abban, hogy milyen információkat engednek ki magukról és azt hogyan kívánják megjeleníteni a publikus oldalakon.
Tartalomjegyzék
5.2) Mi van akkor, ha a gépem elkezdett átvizsgálni egy blokkot, és közben le kell állítanom a rendszert? Nem fog elveszni az a blokk?NEM! A lassabb gépekhez való alkalmazkodás és a duplamunka minmalizálásának érdekében elég hosszú a kulcsok lejárati ideje, szavatossága: minimum 90 nap, amely után esetleg újra kiosztanák valamelyiket. Ha a projekt a kulcstér végére ér anélkül, hogy megleltük volna a győztes kulcsot, akkor kezdődik előről az egész a korábban már kiküldött, de vissza nem érkezett kulcsokkal.
A pontos válasz egyébként az volna, hogy: de igen, akkor és ott az a blokk tulajdonképpen elvész, de majd a végén mindenképpen sorra kerül, mert újra ki lesz osztva.
Mégpontosabb válasz az, hogy a leállás során elvesző blokkok mennyisége csökkenthető a checkpoint file használatával, erről bővebben a konfigurálás 5/23 pontjában olvashattok. Ennek alkalmazása azonban csak arra az esetre nyújt védelmet, ha a rendszert (a gépet) szabályosan állítod le. Ha egyszerűen csak kikapcsolod menetközben, vagy lefagy valamilyen okból, akkor a kliensek nincs ideje beleírnia az említett "checkpoint file"-ba, hogy éppen hol tartott, a számítás alatt állt blokk elvész.
Tartalomjegyzék
5.3) Mit jelentenek azok a többnyire változatos hüjeségek, amelyek a blokkok küldésekor érkeznek a kulcsszervertől (The proxy says: ...)?Ez annak a lehetőségnek a folyománya, hogy a kulcsszerveren az operátor beállíthat egy tetszőleges üzenetet, amelyet minden kliens, és ezzel minden résztvevő megkap. Elméletileg az arra jó, hogy vészhelyzetben, vagy valamiféle fontos közérdekű esemény alkalmával mindenkit viszonylag gyorsan lehet értesíteni, pl. ezen a módon is értesítették az embereket annak idején a DES-II-1 kulcs megtalálásáról. "Békeidőben" kizárólag az operátor agyvelején múlik, hogy mi lesz a szöveg, ne törd rajta a fejed túl sokat.
Tartalomjegyzék
5.4) Miért mutat a kliens hibás időpontokat? Ellenőriztem a gépemben az óra beállítását és mindent rendben találtam.A kliens által kijelzett idő a géped belső óráján alapul, de ez át van konvertálva UTC-re (UTC = Universal Time Code) egységesen mindenkinél a statisztikák összehasonlíthatósága és egyszerűbb frissíthetősége érdekében.
Tartalomjegyzék
5.5) Szeretném, ha az én speciális platformomra is lenne kliens. Megkaphatom emiatt a forráskódot?A jelenlegi kliens széria forrása és a protokollja csak korlátozottan hozzáférhető. A projekt szervezői feltétlenül támogatnak minden kereszt-platformos fejlesztést (cross-platform development) és a kliens adott platformra való megvalósítását (porting), de a forráskód átadását minden esetben mérlegelni kell az esetleges szabotázs elleni védekezésképp. A szervezők kérik a személyes jelentkezést ezügyben, hogy meg lehessen beszélni részletesen a lehetőségeket és feltételeket.
A jelenleg fejlesztés alatt álló kliens generáció (röviden v3, mint version3.x, azaz 3-as verzió) olyan nyílt specifikációjú titkosítási, és a szerzői hitelességet igazoló aláírási rendszerek kombinációján fog alapulni, amelyek majd segítenek csökkenteni a forráskód - a projekt célkitűzései elleni - rosszindulatú felhasználásának lehetőségeit. Az új kliensek teljes specifikációja és forráskódja mindenki számára hozzáférhető lesz. (Az angol nyelvű FAQ szövege szerint valamikor 98 elején, de hát ez eddig nem történt meg, mint tudjuk. - a ford.)
Tartalomjegyzék
5.6) Hogy lehet az, hogy a DESCHALL kliensek sokkal gyorsabbak voltak? A Bovine kliensek nincsenek optimalizálva talán?Ez azért van, mert a DES titkosítási algoritmus egyszerűbb matematikán alapszik, így gyorsabb a visszafejtése, mint a jóval komplikáltabb RC5 megfelelője. Szóval - természetesen - a Bovine kliensek optimalizáltak, ahogyan a Deschall kliensek is azok voltak, a sebesség különbsége a matematikának és nem a szoftvernek tudható be.
Tartalomjegyzék
5.7) Miért sokkal gyorsabbak az Intel és PowerPC gépek más platformoknál?Az RC5 algoritmus matematikájának szerves részét képezik a 32 bites forgatási műveletek (32-bit rotate operations). Valaminő okból az x86 és PowerPc architektúrák tervezői annak idején úgy döntöttek, hogy ezt a forgatási funkciót hardver szinten valósítják meg, míg sok más processzornak nincs ez meg beépített műveletként, így több lépésben kell megvalósítaniuk (legalább két eltolással és egy logikai VAGY-gyal [two shifts and a logical OR]). Ez a hátrány az oka annak, hogy a nem-Intel és nem-PowerPc gépek lassabban futtatják az RC5 processzt, mint az elvárható lenne egyébként, és ez a legfőbb oka annak is, hogy az RC5 kliens miért nem alkalmas egy processzor tényleges sebességének és teljesítményének jellemzésére (benchmark).
Tartalomjegyzék
5.8) Miért gyorsabbak a Cyrix és AMD processzorok, mint az Intel Pentiumok?A Cyrix és AMD-Nextgen tervezői igen sok energiát feccöltek abba, hogy a processzoraik egész számos matematikai komponenseinek hatékonyságát megnöveljék, mivel az egész számokkal való matematikai műveletvégzés a valós világ igen sok számítási feladatának az alapja. És mivel az RC5 algoritmus kizárólag ilyen műveleteket használ, hát nagyon örül a kis lelke neki, amikor ezeken a processzorokon futva találkozik a plussz erővel :-)
Tartalomjegyzék
5.9) Miért nem gyorsabb egy FPU-val ellátott gép, mint anélkül?Mint említettük volt, az RC5 algoritmus nem igényel lebegőpontos műveletvégzést (FPU = Floating Point Unit = lebegőpontos műveleti egység), így általánosságban kimondható, nem élvezi semmi előnyét egy ilyen lehetőségnek. Korábban már nagyon sok vita folyt a szervezők és hozzáértő felhasználók között a különféle fórumokon arról, hogy lehetséges-e egyáltalán növelni a sebességet (legalább az x86-os processzor architektúrán, azaz az Intel/Cyrix/Amd vasakon) előnyt kovácsolva abból a tényből, hogy az egész számos és a lebegőpontos utasítások számára külön csatornák vannak biztosítva (separate pipelines).
Jelenleg a Bovine kliensek egyike sem képes használni az FPU-t és a szervezők hiszik, hogy az FPU bármiféle használatának az eredménye nem csak, hogy nem gyorsabb, de egyértelműen lassabb kliens lehet. Ennek ellenére természetesen örömmel hallanának bárkiről, akinek sikerül kifejlesztenie egy olyan RC5-64 programmagot, amely kihasználja az x86 FPU előnyeit! Ha valakit érdekel a dolog, akkor az x86 mag kódja megtekinthető és letölthető a következő címen/címről: http://altern.com/rguyom/.
Tartalomjegyzék
5.10) Miért nem gyorsabb egy MMX processzor?Erre a kérdésre nagyon hasonló a válasz, mint az előbbi FPU dologra. Röviden arről van szó, hogy jelenleg nincs mód arra, hogy az RC5 kliens kihasználja az MMX műveletek bármelyikét, azaz ezek előnyeit. A szervezők ennek kapcsán is meggyőződésüket fejezik ki, hogy az MMX műveletek bármiféle használatának az eredménye nem csak, hogy nem gyorsabb, de egyértelműen lassabb kliens lehet. Ennek ellenére természetesen örömmel hallanának bárkiről, akinek sikerül kifejlesztenie egy olyan RC5-64 programmagot, amely kihasználja az MMX előnyeit!
Tartalomjegyzék
5.11) Mi a helyzet egy PVM vagy Beowulf géppel. Nem lennének azok gyorsabbak?Lényegében nem. Minden bizonnyal egy Beowulf (vagy Hyglac, vagy Loki) osztályú osztott gép gyorsabban futtatná az RC5-öt, mint egy egyprocesszoros rendszer, de észre kell venni [ha még eddig nem sikerült volna :-) - a ford.], hogy a Bovine már eleve egy osztott (hálózaton keresztül megosztott) számítógép. Természetesen (még) nem olyan sokoldalú, mint egy Beowulf rendszer, de a jelen feladatnál legalább olyan gyors.
A Beowulf felvonultat egy jópár olyan alapelemet, amely a Bovine rendszerből hiányzik, ezek egyike a csomópontok közötti nagyon gyors kommunikáció, amely igen könnyen beláthatóan teljesen felesleges lenne ebben a feladatban, mivel itt az egyes csomópontok (amelyek a kliensek!) egymástól teljesen független futnak és az igen ritkán (akár csak több naponta) megtörténő kommunikáció során is csak nagyon kicsi adatcsomagok továbbítására van szükségük.
A Beowulf rendszerek olyan általános célú üzenettovábbítási és ellenőrző architektúrát alkalmaznak, amelyek tetszőlegesen választott problémához történő gyors átprogramozhatóságának köszönhetően ezek a rendszerek igen rugalmasan sokoldalúak. A Bovine szisztémája speciálisan az RC5 problémához lett igazítva, mivel itt most csak ez volt a feladat, és bár a fent említett általános célú üzenettovábbítási séma előnyére válna a distributed.net-nak a jövőben, nem volna semmiféle tényleges értéke az RC5 projekt számára.
Ez természetesen nem jelenti azt, hogy egy ilyen gép nem volna hasznos az RC5-64 tejesítése érdekében! Ha hozzáférsz egy ilyenhez, tedd fel rá a klienst, nem árthat. :-)
PVM = Paralell Virtual Machine, azaz párhuzamos virtuális gép, mely témáról magyarul is olvashatsz, mégpedig Szamcsi barátunk jóvoltából itt!
Tartalomjegyzék
5.12) Már részt veszek a versenyben és most van egy újabb gépem, amelynek viszont nincs hálózati kapcsolata. Hogyan futtathatom azon a klienst?A magyarázatban Microsoft oprendszert feltételezünk és gép1 lesz a hálózati kapcsolattal rendelkező, míg GÉP2 hálózat nélküli masina neve.
Először is installáld a klienst a GÉP2-re. Definiálj egy checkpoint file-t a GÉP2-n, legyen mondjuk ckpoint.cp
Állítsd le a klienst a gép1-en Töltsd fel az input buffert a fetch paranccsal a gép1-en, mondjuk a lehető legnagyobb értékre (1000), melyhez persze ideiglenesen át kell írnod az INI file megfelelő sorát (treshold=1000:1000). Tedd ki (MOVE, és nem COPY!) a buff-in.rc5 file-t egy floppyra. Állítsd vissza a gép1 INI-jét a 'normál' értékekre, majd indítsd el Tedd át a floppyról a buff-in.rc5 file-t a GÉP2-re, mint ckpoint.cp, azaz írd felül ezzel Indítsd a klienst a GÉP2-n, ekkor ez importálni fogja a ckpoint.cp file-ját, mint buff-in.rc5 (...) Ha már végzett a teljes adaggal, akkor állítsd le a GÉP2 kliensét Tedd ki (MOVE, és nem COPY!) a GÉP2 buff-out.rc5 file-ját egy floppyra. Állítsd le a klienst a gép1-en Ürítsd ki a gép1 output bufferét a flush paranccsal Tedd át a buff-out.rc5 file-t a floppyról a gép1-re, azaz írd felül ezzel az imént kiürített bufferét Indítsd újra a gép1-en a klienst, az első dolga az lesz, hogy kiüríti az ismét teli output bufferét, azaz elküldi a GÉP2-ről áthozott blokkokat És kezdheted is előről.
Tartalomjegyzék
5.13) Mi fog történni az RC5 után?Ezzel kapcsolatban tekintsd meg distributed.net azon oldalát, ahol a megfontolásra érdemesnek tekintett jövőbeni projekteket tekintheted át röviden: http://www.distributed.net/projects.html.
Tartalomjegyzék