Usenetről röviden

FAQ

2011. január 08. - StanLee

Gyakran Ismételt Kérdések

 

Itt a leggyakrabban felmerülő kérdésekre próbálok meg választ adni. A lista folyamatosan bővül.

Mi az az NZB (*.nzb) file és mire jó?

Az nzb file egy XML alapú fájltípus, ami lehetővé teszi az usenet szervereken tárolt posztok "csokorban" történő letöltését. Az nzb-t a NewzBin.com oldal fejlesztői találták ki. Az nzb filok használatának előnye, hogy az egyes posztokat az usenet szolgáltatótól anélkül le lehet tölteni, hogy a poszt címét (Header) le kelljen tölteni, felesleges adatforgalmat generálva. Minden egyes posztnak van egy egyedi azonosítója (Message-ID) amit az nzb file tartalmaz. Az usenet hírolvasó programok az nzb file-ban található Message-ID-k alapján képesek egyszerre több posztot is letölteni. Így lehetséges pl. hogy az online kereső programok eredményeit nem kell egyenként letölteni, hanem akár több posztot is összegyűjthetünk egy letöltésbe. A több részletben feltöltött összetartozó posztokat többnyire egy *.nzb file-ban teszik közzé, megkönítve a letöltés menetét.

 

Mi az a yEnc?

A yEnc egy kódolási forma, amit az ezredfordulón vezettek be a useneten. A kódolási módszert Jürgen Helbing dolgozta ki, és vezette be 2001-ben. A cél az volt, hogy a bináris adatállományok (képek, videók, hangok, stb.) kisebb helyet foglaljanak el az usenetet kiszolgáló szervereken. Korábban az usenetre feltöltött üzeneteket többnyire US-ASCII kódolásban tárolták, ami a yEnc-hez képest kb. 30-40%-kal több helyet foglalt el, tehát a letöltéshez/feltöltéshez szükséges idő is ennyivel növekedett. A yEnc kódolási formának is vannak természetesen hátrányai, de mivel meggyorsította az adatokhoz való hozzáférést, az usenet berkein belül rövid időn belül elterjedt. A yEnc nem standardizált, ezért pl. a Microsoft Outlook Express vagy a Mozilla Thunderbird leveező és usenet hírolvasó programok alapértelmezetten nem támogatják. Pluginok természetesen letölthetőek mindkét programhoz. Részletesebben a yEnc kódolásról a yEnc.org oldalon lehet olvasni.

 

Miért vannak tömörítve és feldarabolva a feltöltött anyagok?

A tömörítésnek és feldarabolásnak az egyik oka, hogy az usenet kialakulásakor még nem rendelkeztek az emberek olyan internet hozzáféréssel, mint manapság. Csak nagyon lassan lehetett csatlakozni a nethez, és minden ok nélkül megszakadhatott a telefonvonal. Akkoriban használatos volt a BBS rendszer is, és innen is kerültek át tartalmak az usenetre. Mindkét helyen a fő szempont az volt, hogy megszakadt letöltések ne vesszenek kárba, és ne kelljen egy postot az elejétől kezdve letölteni, hanem csak azokat a részeket, amik sérültek, vagy nem jöttek le. A letöltött anyagokat a felhasználók a saját gépükön rakták össze egybe.

Ez a feldarabolás ebből a régi korszakból maradt meg. Egyszerűbb feltölteni is a tartalmakat kisebb fileméretben, mivel ha megszakad a kapcsolat, nem kell teljesen előlről kezdeni a posztolónak a feltöltést.

További előny a feldarabolás esetén, hogy ha sérül egy állomány, akkor nem kell ismételten az egészet újra feltlteni, hanem kérhetik a csak hibás rész ismételt posztolását a felhasználók. Természetesen ez feltételezi, hogy az eredeti posztolónak még megvannak az eredeti állományai is.

A kisebb hibákat a par fileok hasznlatával is ki lehet javítani, de vannak olyan esetek, amikor már ez a hibajavítási mód sem működik.

 

Miért nincsenek magyar nyelvű anyagok az useneten?

Erre az az egyszerű válasz, hogy az usenet, mint szolgáltatás itthon nem ismert, csak nagyon kevesen használják. Előnyei ellenére nem töltenek fel tartalmakat magyar nyelven, a felhasználók pedig nem is keresik azokat. A blog egyik célja, hogy ezen változtassak és többen megismerkedjenek az usenettel.

 

Mi az a .par, .par2 és szükségem van-e rá?

A .par és .par2 kiterjesztésű filok a parchive filok. Az usenet bináris adatállomány továbbításra történő használatának széles körű elterjedésekor kiderült, hogy érdemes bizonyos javító algoritmusokat beépíteni a posztokba. Mindez annak érdekében, ha a feltöltéskor megsérül valamelyik állomány, lehetőség legyen a hibás tömörített file-nak a kijavítására. A poszt adatmennyiségétől függ a par és par2 fileok száma és nagysága. Mindenesetre érdemes letölteni ezeket a hibajavító fileokat, vagy posztoláskor létrehozni azokat. Így bárminemű hiba esetén a teljes helyreállítás lehetséges. Ez nem igaz arra az esetre, ha a posztoló 10 rar filebol csak 9-et tölt fel + a hozzá tartozó parchive adatokat. A legtöbb esetben a parchive filokat a letöltő kliensek (pl. GrabIt) automatikusan letöltik, ellenőrzik a letöltött adatokat, és végrehajtják a szükséges javításokat is a háttérben.

 

Mekkora az Usenetre felkerülő napi posztok adatmennyisége?

Az Usenetre naponta feltöltött adatmennyiség (feed) nagysága 2011-ben kb. 10 TByte volt. Összehasnlításképpen: 2000-ben ez mindössze 0.285 TByte volt.

Érdekesség, hogy az egyik első magyar torrent oldalon a fentlévő torrentek száma kb. 47000, átlagosan 5 GByte-os torrent mérettel számolva 235 TByte adatmennyiséget kapunk (nem foglalkozva azzal, hogy a ténylegesen magyar nyelvű anyagok ennek csak a töredékét teszik ki). Ezt az adatmennyiséget az Usenetre kevesebb, mint egy hónap alatt feltöltik. Így a magyar nyelvű posztolás a napi feed mennyiséget szinte nem is érezhető nagyságban változtatná meg.

 

Mi az a retention time (tartózkodási idő)?

Az usenet szerverek üzemeltetői részéről egy fontos mutatószám, hogy posztolást követően az üzenetek mennyi ideig lesznek fellelhetőek az adott szolgáltatónál. Ez ma 1380+ nap bináris posztok esetében, míg a szöveges posztok 3000+ napig elérhetőek.

Mindez azt jelenti, hogy a majd 3,5 évvel ezelőtt posztolt bináris tartalmak még mindig elérhetőek. A legfontosabb, hogy a bináris tartalmak a posztolási időponttól függetlenül szinte azonos sebességgel tölthetőek le a szolgáltatóktól.

 

Miért kell fizetni érte?

Az egyre növekvő retention time és feed nagysága miatt a szolgáltatóknak az infrastruktúra fenntartása sokba kerül. A szolgáltatók szerver farmokat tartanak fenn Észak-Amerikában, Európában és Ázsiában, hogy az előfizetőik a nekik legközelebb lévő adatközpontokhoz csatlakozva tudják elérni a szolgáltatást. A felhasználók elvárják, hogy régebbi posztokat is hosszú ideig megtalálhassák, valamint a szélessávú internetes kapcsolatoknak köszönhetően a tartalmakat a lehető leggyorsabban kívánják megkapni az előfizetők.

Vannak ingyenes news-szerverek is, de ezeken többnyire csak a szöveges posztok találhatóak meg, így az azt használók nem érik el a teljes Usenet tartalmat.

 

Mi a helyzet a pornóval?

Mint az interneten mindenhol, az Usenet szervereken is megtalálhatóak a felnőtt tartalmak. Egy indexelő szolgáltatást használva kiszámoltam, hogy naponta átlagosan legalább 250-300 felnőtteknek szóló tartalmat posztolnak. Ezek a posztok egyértelműen beazonosíthatóak voltak. Ugyanezen a napon az egyik legnagyobb hazai torrent oldalon csak 15 XXX tartalmú feltöltés volt.

 

Meg lehet-e szüntetni az Usenetet?

Az Usenet az ARPANET fejlesztéséből alakult ki. 1979-ben hozták létre két amerikai egyetem között a jobb információáramlás reményében. 1986-ban tették le a mostani Usenet alapjaiul szolgáló NNTP-t (Network News Transfer Protocol).

Az Usenet egy decentralizált rendszer. Az egyes szolgáltatók a hozzájuk beküldött posztokat elhelyezik a megadott hírcsoportba. A többi szolgáltató innen frissíti a saját szerverein a posztokat. Így ha az egyik szolgáltató ki is esik, akkor a fennmaradók képesek a hiányát pótolni, majd ha a szerverek ismét működnek, az időközben posztolt tartalmakat a kiesett szolgáltató képes lesz tükrözni. A kiesett szolgáltató előfizetői azonban az Usenetet a szolgáltatásban beállt leállás ideje alatt nem tudják elérni.

A Zdnet egy 2006-os cikke szerint a teljes európai internet forgalomnak 19%-a volt az Usenetre visszavezethető. míg a P2P csak 13% volt. Egy 2009-es tanulmány szerint mindez már csak 5%. Tehát elmondható, hogy az egyes P2P alkalmazások és streaming szolgáltatások miatt az Usenet veszített az adatforgalomban betöltött szerepében.

Mi az a feed server?

Kétféle feed-ről beszélhetünk. Az egyik a felhasználók által használt feed szerver, a másik az usenet szolgáltatók által használt feed szolgáltatás.

A felhasználók által használt feed szerver arra való, hogy ha a mindennapokban használt usenet szolgáltató rendszerében esetleg nincs meg egy poszt, akkor azt egy másik szolgáltató szerveréről (feed szerver) letölthessük. Mivel az interneten számos usenet szolgáltatást értékesítő oldal ugyanazon nagy háttérszolgáltató rendszerét használja, érdemes egy teljesen független szolgáltatónál egy blokk előfizetést tartani. Az interneten számos angol nyelvű oldal összegzi, hogy melyik értékesítő melyik szolgáltató rendszerét használja. Mivel minden szolgáltató csak 99,9%-os teljességet garantál, érdemes egy feed szerverre előfizetni.

Az usenet szolgáltatók egymás közt folyamatosan kicserélik a posztokat, erre való a feed szolgáltatás. 2012-ben egy teljes feed kb. 200 Mbit/s.

Elviheti a NAV az usenetet?

A kérdés talán kissé furcsának hangzik, de az utóbbi időkben egyre többször hallani, hogy a NAV a rendőrséggel karöltve ilyen vagy olyan illegális tartalmakat megosztó szolgáltatások technikai hátterét adó hardware-t foglalt le. El kell kismerni, hogy az usenet is tartalmaz illegális tartalmakat. A technikai hátteret adó hardware-t viszont nem lehet egyértelműen lekapcsolni. Így a NAV sem képes elvinni az usenetet.

Fontos megemlíteni, hogy Magyarországi szervertermekben elhelyezett hardware-ről egyetlen szolgáltató sem nyújt usenet hozzáférést. De ha tenné is, érdemes figyelembe venni, hogy az usenet napi feed-je kb. 12 Tbyte/nap 2012-ben, vagyis egy év alatt több, mint 4380 Tbyte adat kerül fel a szolgáltatókhoz.

A bejegyzés trackback címe:

https://usenetuser.blog.hu/api/trackback/id/tr752570634

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.