View metadata, citation and similar papers at core.ac.uk brought to you by CORE
provided by Digital library of Brno University of Technology
VYSOKÉ U ČENÍ TECHNICKÉ V BRN Ě BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMA ČNÍCH TECHNOLOGIÍ ÚSTAV INFORMA ČNÍCH SYSTÉM Ů FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
NNTP SERVER JAKO SLUŽBA PRO SYSTÉMY ZALOŽENÉ NA TECHNOLOGII WINDOWS-NT
DIPLOMOVÁ PRÁCE MASTER‘S THESIS
AUTOR PRÁCE BC. JOSEF LOUPANEC AUTHOR
BRNO 2007 VYSOKÉ U ČENÍ TECHNICKÉ V BRN Ě BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMA ČNÍCH TECHNOLOGIÍ ÚSTAV INFORMA ČNÍCH SYSTÉM Ů FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
NNTP SERVER JAKO SLUŽBA PRO SYSTÉMY ZALOŽENÉ NA TECHNOLOGII WINDOWS-NT NNTP SERVER AS A WINDOWS NETWORK SERVICE
DIPLOMOVÁ PRÁCE MASTER‘S THESIS
AUTOR PRÁCE BC. JOSEF LOUPANEC AUTHOR
VEDOUCÍ PRÁCE ING. PAVEL O ČENÁŠEK SUPERVISOR
BRNO 2007
NNTP server jako služba pro systémy založené na technologii Windows NT
Vedoucí: Očenášek Pavel, Ing., UIFS FIT VUT Přihlášen: Loupanec Josef, Bc. Zadání:
1. Seznamte se s protokoly NNTP, HTTP, případně s jejich zabezpečenými variantami, podle příslušných RFC. 2. Seznamte se s možnostmi tvorby aplikací v prostředí Windows NT (resp. Win XP). Především se zaměřte na implementaci služeb (services). 3. Navrhněte vlastní diskuzní server umožňující práci s uvedenými protokoly. Server bude umět pracovat s lokálními diskuzními složkami (víceuživatelský přístup) a případně předávat požadavky na vzdálené diskuzní servery. 4. Do návrhu zahrňte vzdálené stahování diskuzních příspěvků z jiných serverů. 5. Navržený server implemetujte jako službu pro prostředí Win NT. 6. Zhodnoťte dosažené výsledky a diskutujte další možnosti rozšíření.
Část požadovaná pro obhajobu SP: Body 1 4. Kategorie: Počítačové sítě Operační systém: Windows NT (Win2000, WinXP, ...) Literatura:
• Příslušná RFC k jednotlivým protokolů s formátům zpráv. • Dále dle doporučení vedoucího práce.
Komentář: Server musí podporovat autentizaci uživatele.
Abstrakt:
Tato práce se zabývá analýzou požadavk ů, návrhem a implementací internetového diskusního serveru. Přesn ěji řečeno, jedná se o server spravující diskusní skupiny s p řísp ěvky a zajiš ťující jejich dostupnost prost řednictvím protokolu NNTP a HTTP. Server podporuje autentizaci uživatele a disponuje volitelným proxy módem, kdy jsou všechny NNTP požadavky p řeposílány na vzdálený NNTP diskusní server. Sou částí programu je též mechanismus zajiš ťující stahování p řísp ěvk ů ze vzdálených NNTP server ů a tím pádem plnící distribu ční funkci. Aplikace je ur čena pro opera ční systémy MS Windows po čínaje verzí NT a vyšší. Program pob ěží jako služba NT a je konfigurovatelný prost řednictvím grafického uživatelského rozhranní. V dokumentu jsou také obsaženy teoretické informace nutné pro praktické zvládnutí výše uvedených krok ů.
Klí čová slova:
Rela ční databáze, HTTP protokol, NNTP protokol, proxy server, regulární výraz, formát diskusního přísp ěvku, služba Windows, SQL, MySQL, server, diskusní skupina, distribuce, HTML, port, URL, vlákno, service control manager, relace, primární klí č,
Abstract:
This work includes specification and analysis of requirements, design and implementation of the internet news server. The server controls newsgroups and associated news. It provides availability of the articles by NNTP protocol and HTTP protocol (by web interface). The server supports a user authentication and an optional proxy mode, when all NNTP requests are resent to another remote NNTP server. A mechanism that provides news-downloading from remote NNTP servers and performs distribution function is included too. The application is designed to run on MS Windows NT (and higher version) as a NT service. The server is configurable by a graphic user interface. The work also includes theoretical information needed for successful accomplishment of the above-mentioned requirements.
Key Words:
Relation Database, HTTP, NNTP, proxy server, regular expression, news format, Windows service, SQL, MySQL server, newsgroup, distribution, HTML, port, URI, thread, service control manager, relation, primary key
Josef Loupanec: NNTP server jako služba pro systémy založené na technologii Windows NT, diplomová práce, Brno, FIT VUT v Brn ě, 2007
Prohlášení
Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatn ě pod vedením Ing. Pavla O čenáška. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal .
Obsah
Úvod ...... 3 Up řesn ění požadavk ů...... 3 Teoretické informace ...... 4 NNTP protokol...... 4 Úvod ...... 4 NNTP P řehled...... 5 WILDMAT formát...... 5 Příkazy administrace sezení...... 6 Příkazy pro zasílání a stahování článk ů...... 7 Příkazy pro autentizaci ...... 15 Odpov ědi NNTP Serveru...... 15 Formát diskusních p řísp ěvk ů ...... 17 Popis HTTP protokolu...... 18 Úvod ...... 18 Požadavky...... 18 Odpov ědi...... 19 URL...... 20 Pole v hlavi čkách ...... 20 Spojení:...... 22 Služby systému Windows NT ...... 22 Rela ční databáze...... 23 Úvod ...... 23 SQL...... 24 Regulární výrazy ...... 24 Návrh systému...... 25 Návrh struktury aplikace...... 25 Návrh NNTP rozhraní...... 27 Návrh HTTP rozhraní...... 28 Návrh konfigura čního rozhraní ...... 29 Návrh automatizovaného NNTP klienta...... 29 Návrh databáze...... 30 Implementace systému...... 30 Implementace NNTP rozhraní...... 31
1 Popis t řídy NNTPServer...... 31 Popis t řídy SocketHandler ...... 32 Popis t řídy NNTPProxy...... 33 Popis t řídy Head...... 33 Popis t řídy Update...... 34 Popis t řídy NNTPProcesor.java ...... 35 Implementace HTTP rozhranní...... 42 Popis t řídy HTTPServer ...... 42 Popis t řídy SocketHandler ...... 42 Popis t řídy NNTPClient.java ...... 45 Popis t řídy ArticleBuild...... 46 Popis t řídy Article ...... 46 Popis t řídy Mime...... 47 Popis t řídy RequestProcessor...... 47 Implementace konfigura čního rozhraní ...... 47 Popis tabulek databáze MySQL ...... 48 Java aplikace jako služba Windows NT ...... 50 Záv ěr...... 52 Literatura...... 53 Seznam p říloh...... 54 Přílohy...... 55 A. Manuál k vytvo řenému programu...... 55 A.1. Instalace programu...... 55 A.2. Nastavení programu...... 57
2 Úvod
Cílem tohoto projektu je analýza požadavk ů, návrh a dále implementace diskusního NNTP serveru ur čeného pro platformu Microsoft Windows (po čínaje verzí NT). Podstatnou částí tohoto projektu je též zahrnutí teoretických znalostí nutných pro úsp ěšné zvládnutí výše uvedených krok ů. První část dokumentu obsahuje up řesn ění specifikace požadavk ů na systém a dále je zam ěř ena především na teoreti čtější informace nutné pro vytvo ření projektu. Nejprve se jedná o popisy protokolu HTTP a NNTP pot řebných pro implementaci internetových rozhraní serveru. Dále je zde popsán princip práce s rela ční databází a její použití pro uložení diskusních přísp ěvk ů. Sou částí bude také vysv ětlení principu fungování a ovládání služeb systém ů Windows. Zmín ěny jsou regulární výrazy a jejich využití p ři lexikální analýze. Druhá část dokumentu se zabývá návrhem jednotlivých částí diskusního serveru. Jmenovit ě se jedná o NNTP a HHTP rozhraní, databázové schéma, klienta zabezpe čujícího distribuci zpráv a uživatelské rozhraní. T řetí část práce se v ěnuje popisu implementace navržených komponent a zp ůsobu spln ění kritérií kladených na služby systému Windows. Manuál k vytvo řené aplikaci je obsažen v přílohách této práce. Tato diplomová práce navazuje na p ředešlý semestrální projekt [8], ze kterého jsou p řevzaty některé teoretické informace v úvodu práce. Teorie týkající se NNTP protokolu je však vytvo řená nov ě, nebo ť v dob ě práce na projektu bylo vydáno RFC 3977 definující novou verzi protokol NNTP, kterou se tento projekt řídí. Z tohoto d ůvodu jsou též p řepracovány kapitoly týkající se návrhu projektu, jejichž nosná část je však inspirována také semestrálním projektem.
Up řesn ění požadavk ů
Na tomto míst ě jsou up řesn ěny ty požadavky, které nebyly p řesn ě specifikované v rámci zadání a jejichž volba byla ponechána na autorovi projektu. Pro implementaci bude použit programovací jazyk Java s podporou rozhranní JDBC pro prácí s databází. Pro daný projekt byl zvolen databázový systém MySQL, p ředevším díky tomu, že je pro nekomer ční aplikace k dispozici zdarma. Vzhledem k tomu, že implementace grafického uživatelského rozhraní pro služby systému Windows je problematická, bude toto rozhranní implementováno jako samostatná aplikace, která pouze edituje konfigura ční soubor, který si na čítá služba p ři svém spušt ění, resp. restartu. Pomocí této konfigura ční aplikace bude též možné provád ět operace s databází (vytvá ření/rušení diskusních skupin, uživatel ů, ...)
3 Teoretické informace
NNTP protokol
Úvod
Původní Network News Transfer Protocol (NNTP) je popsán v RFC 977. Jeho vznik je datován do únoru roku 1986. V říjnu roku 2006 vychází nové RFC 3977 definující tento protokol, které p řináší mnoho zm ěn a rozší ření oproti p ůvodnímu RFC 977. NNTP specifikuje protokol pro distribuci, nalezení, p řenos a zasílání diskusních p řísp ěvk ů pomocí protokolu TCP/IP v rámci sít ě Internet. Je navržen tak, že články jsou uloženy v centrální databázi a uživatel si m ůže vybrat a stáhnout pouze ty články, které chce číst. Tento protokol též poskytuje indexování, k řížové odkazy a exspiraci neaktuálních zpráv. Hlavním d ůvodem pro zavedení protokolu NNTP je obrovské rozšíření používání diskusních zpráv mezi uživateli Internetu. V dnešní dob ě tento protokol již tém ěř úpln ě vytla čil diskusní skupiny založené na seznamech emailových adres, nebo ť jejich používání se ukázalo jako neefektivní hlavně z hlediska plýtvání p řenosový pásmem a nutností p řijímat i nevyžádané zprávy. Tyto nedostatky jsou u NNTP eliminovány práv ě existencí centrálního diskusního serveru vybaveného centrální databází s diskusními p řísp ěvky, ze kterých si m ůže uživatel stáhnout a p řečíst pouze ty p řísp ěvky, které jsou předm ětem jeho zájmu. Důležitou vlastností protokolu NNTP je podpora distribuce diskusních zpráv. Sou částí jsou totiž příkazy, které poskytují p římou metodu vým ěny článk ů mezi spolupracujícími po číta čovými systémy. Distribuce u NNTP nahrazuje zastaralý zp ůsob distribuce zpráv pomocí zaplavování, kdy každý systém zasílá všechny zprávy svým soused ům v distribu ční skupin ě. Tento zp ůsob distribuce však vede k neúm ěrnému plýtvání zdroji jak v časové tak datové oblasti. Navíc p řináší problém redundance a následné nutnosti detekce duplikát ů a jejich mazání. Vým ěna článk ů p ři použití protokolu NNTP probíhá následujícím zp ůsobem. Systémy provád ějící vým ěnu diskusních zpráv mají interaktivní mechanismus pro rozhodování, které články se mají p řenášet. Systém, který vyžaduje nové zprávy, nebo který má zprávy ur čené pro zaslání, typicky kontaktuje jednoho nebo více svých soused ů pomocí protokolu NNTP. Nejprve pomocí p říkazu NEWGROUPS zjistí, jestli byly na kontaktovaném systému vytvo řeny n ějaké nové diskusní skupiny. Pokud se tak stalo (a na základ ě lokálních pravidel je dovolena distribuce t ěchto nových skupin) jsou tyto skupiny založeny i na lokálním systému. Klient potom zjistí, zda do skupin, které jsou p ředm ětem jeho zájmu byly doru čeny n ějaké nové články. Prost ředkem k tomuto zjišt ění je p říkaz NEWNEWS. Tento p říkaz doru čí seznam nových článk ů na serveru a na základ ě tohoto seznamu m ůže za čít sekvence p řenos ů článk ů ze serveru na klienta. Nakonec m ůže klient nabídnout serveru ty nové články, které klient často dostává. Server se
4 potom rozhodne, které z těchto článk ů již obdržel, a které by m ěli být zaslány a p řidány do jeho sbírky.
NNTP P řehled
NNTP server specifikovaný v RFC 3977 používá textové p říkazy a odpov ědi podobn ě jako nap ř. protokol SMTP. Je navržen tak, aby akceptoval p říchozí p řipojení od klient ů a poskytoval jednoduché rozhraní k databázi s diskusními p řísp ěvky. Jako transportní vrstva sí ťového protokolu je použit protokol TCP a pro tuto službu je jako výchozí vyhrazen port 119. Příkazy a odpov ědi jsou složené ze znak ů v kódování UTF-8. P říkazy se skládají z příkazových slov, které jsou v některých p řípadech následovány jedním nebo více parametry. Parametry musí být od sebe a od p říkazového slova odd ěleny jednou nebo více mezerami a nebo tabelátorem. P říkazová řádka musí obsahovat všechny povinné parametry daného p říkazu a nem ůže obsahovat více než jeden příkaz. P říkazy ani parametry nejsou citlivé na velikosti písmen. P říkaz musí být ukon čen dvojicí znak ů CR-LF (Carriage Return – Line Feed). Délka p říkazové řádky nesmí být v ětší jak 512 znak ů (zapo čítávají se všechny mezery, tabelátory i koncová dvojice CR-LF). Tj. pro p říkaz a jeho parametry je použitelných 510 znak ů. Neexistuje žádná možnost jak pokra čovat p říkazový řádek. Server m ůže tolerovat p řekro čení tohoto limitu pro p říkazy definované v rozší řeních tohoto protokolu. Z jistých d ůvod ů nejsou všechny p říkazy ve specifikaci RFC 3977 povinné. A čkoliv n ěkteré příkazy povinné jsou a musí je implementovat každý NNTP server. Ostatní p říkazy jsou rozd ěleny do balík ů, které jsou pojmenované a to zda jsou na serveru implementovány ur čuje, zda je jméno balíku do kterého náležejí uvedené v seznamu schopností serveru. NNTP Server je tradi čně využíván dv ěma r ůznými zp ůsoby. Prvním zp ůsobem použití je doru čování, kdy klient stahuje články z velkého úložišt ě obhospoda řovaného NNTP serverem. Druhým použitím je ukládání a distribuce článk ů jiným server ů. V praxi jsou tyto dva zp ůsoby použití NNTP protokolu natolik odlišné, že se vytvá řejí implementace server ů specializované bu ď na první, nebo druhé použití, což je doporu čováno i tímto RFC. Existuje však kombinace obou dvou t ěchto módů v jedné implementaci, takový server se nazývá mode-switching server.
WILDMAT formát
WILDMAT formát byl vyvinut, aby poskytoval jednotný mechanismus pro nalezení řet ězce, který vyhovuje ur čitému vzoru, s podobnou funk čností jakou disponuje nap ř. Unixový shell p ři výb ěru soubor ů. Popsán je následující ABNF syntaxí: wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) wildmat-pattern = 1*wildmat-item wildmat-item = wildmat-exact / wildmat-wild
5 wildmat-exact = %x22-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E / UTF8-non-ascii ; exclude ! * , ? [ \ ] wildmat-wild = "*" / "?"
WILDMAT je testován oproti řet ězci, kterému bu ď vyhovuje, nebo nevyhovuje. K provedení takového porovnání, je každý wildmat-pattern , ze kterého se WILDMAT skládá, porovnán s řet ězcem a wildmat-pattern nacházející se nejvíc napravo, který se shoduje s předloženým řet ězcem, je identifikován. Pokud není wildmat-pattern p ředcházen znakem „!“, shoduje se celý WILDMAT. Pokud je p ředcházen znakem „!“, nebo pokud se neshoduje žádný wildmat-pattern , celý WILDMAT se neshoduje. Wildmat-exact se shoduje se stejným znakem, jaký jej tvo ří. Znak „?“ odpovídá práv ě jednomu znaku. Znak „*“ se shoduje se sekvencí znaků délky nula a více.
Příkazy administrace sezení
Založení spojení . Tento p říkaz nezasílá klient serveru, ale server musí prezentovat vhodnou odpov ěď jako p řivítání pro klienta, který se k serveru p řipojil. Odpov ěď informuje klienta, zda je služba dostupná a zda je klientovi umožn ěno zasílat články na diskusní server. Zde jsou možné odpov ědi:
200 Service available, posting allowed 201 Service available, posting prohibited 400 Service temporarily unavailable 502 Service permanently unavailable
Capabilities Tento p říkaz je povinný a musí být implementován každým NNTP serverem. Syntaxe: CAPABILITIES [keyword] Odpov ěď : 101 Capability list follows (multi-line)
Tento p říkaz umož ňuje klientovi zjistit schopnosti serveru. Schopnosti serveru navracené b ěhem sezení mohou být zm ěněny prost řednictvím n ějakého jiného p říkazu (nap ř. MODE READER, pro přepnutí módu u mode-switching serveru). První řádek odpov ědi na tento p říkaz za číná řet ězcem VERSION a pokra čuje číselným ur čením verze protokolu NNTP, který tento server implementuje.
Mode Reader Syntaxe: MODE READER
Odpov ědi:
6 200 Posting allowed 201 Posting prohibited 502 Reading service permanently unavailable [1]
Možnost použití tohoto p říkazu je indikována schopností serveru MODE-READER. A slouží k přepnutí u mode-switching serveru z módu ur čeného pro distribuci p řísp ěvk ů na mód doru čování přísp ěvk ů z lokální databáze klient ům.
Quit Syntaxe: QUIT
Odpov ědi: 205 Connection closing
Tento p říkaz používá klient k ukon čení spojení.
Příkazy pro zasílání a stahování článk ů
Group
Syntaxe: GROUP group
Odpov ědi: 211 number low high group Group successfully selected 411 No such newsgroup
Příkaz je indikován schopností READER. Povinný parametr group je jméno diskusní skupiny, která má být vybrána. Odpov ěď na úsp ěšný p říkaz GROUP obsahuje číslo prvního a posledního článku ve skupin ě a o čekávaný po čet článk ů ve skupin ě. Tento po čet nemusí být p řesný. Musí být pouze roven nebo v ětší než po čet článk ů, které se ve skupin ě doopravdy vyskytují. Pokud je skupina úsp ěšn ě vybrána, vnit řně udržovaný ukazatel akt. článku je nastaven na první článek ve skupin ě. Pokud je vybrána chybná skupina, p ředtím vybraná skupina ani ukazatel na aktuální článek se nem ění. V případ ě, že je vybrána prázdná skupina, je ukazatel na aktuální článek nenastaven a nem ěl by být používán, nebo ť jeho použití zp ůsobí chybu.
Listgroup Syntaxe: LISTGROUP [group [range]]
Odpov ědi:
7 211 number low high group Article numbers follow (multi-line) 411 No such newsgroup 412 No newsgroup selected [1]
Přítomnost p říkazu je indikována schopností READER. P říkaz m ůže být následován nepovinným parametrem group (název diskusní skupiny) a tento nepovinný parametr m ůže být následován dalším parametrem range . P říkaz se vnit řně chová naprosto stejn ě jako p říkaz GROUP uvedený výše, tj. vnit řní ukazatel na aktuální skupinu je nastavován stejným zp ůsobem. Rozdíl je však v odpov ědi, kdy po řádku se stavovým kódem 211 (jeho formát je také shodný s tím u p říkazu GROUP) následují řádky s čísly jednotlivých článk ů v dané diskusní skupin ě. Rozsah čísel, který se má zobrazit m ůže být omezen práv ě parametrem range. Ten m ůže nabývat následujících t ří tvar ů: - číslo článku - číslo článku následované znakem „-“, což ur čuje všechny následující čísla od zadaného čísla - číslo1 článku, znak „-“, číslo2 článku, což ur čuje výpis všech čísel článk ů mezi číslem1 a číslem2.
Last Syntaxe: LAST
Odpov ědi: 223 n message-id Article found 412 No newsgroup selected 420 Current article number is invalid 422 No previous article in this group
Přítomnost tohoto p říkazu je indikována schopností READER. Ukazatel na aktuální článek je tímto příkazem nastaven na p ředchozí článek v aktuální skupin ě. Pokud je p řed tímto p říkazem nastaven na první článek ve skupin ě, je navrácena chyba a nastavení ukazatele akt. článku se nezm ění. Odpov ěď na úsp ěšné provedení tohoto p říkazu obsahuje číslo aktuálního článku v dané diskusní skupin ě a dále Message-ID článku.
Next Syntaxe: NEXT
Odpov ědi: 223 n message-id Article found 412 No newsgroup selected 420 Current article number is invalid 421 No next article in this group
8 Tento p říkaz nastaví ukazatel aktuálního článku na další článek v aktuální diskusní skupin ě. Pokud již ve skupin ě nejsou žádné další články je navrácena chybová zpráva a ukazatel aktuálního článku zůstává nezm ěněn. P ři úsp ěšném provedení p říkazu je v odpov ědi navráceno číslo aktuálního článku a jeho identifikátor.
ARTICLE, BODY, HEAD, and STAT
Syntaxe: ARTICLE message-id ARTICLE number ARTICLE
Odpov ědi:
První tvar (pomocí message-id): 220 0|n message-id Article follows (multi-line) 430 No article with that message-id
Druhý tvar (pomocí čísla článku) 220 n message-id Article follows (multi-line) 412 No newsgroup selected 423 No article with that number
Třetí tvar (aktuální článek) 220 n message-id Article follows (multi-line) 412 No newsgroup selected 420 Current article number is invalid
ARTICLE - Celý text článku je navrácen jako textová odpov ěď . HEAD – vrací pouze řádky hlavi čky BODY – vrací pouze t ělo zprávy. STAT – nevrací žádný text. P ři selekci pomocí čísla zprávy nastavuje vnit řně udržovaný ukazatel na aktuální článek.
Přítomnost t ěchto p říkaz ů je indikována schopností READER. Existují dv ě formy t ěchto p říkaz ů. Každá používá jinou metodu k ur čení, který článek má být doru čen. Pokud jsou tyto p říkazy následovány identifikátorem zprávy v lomených závorkách. Je nap ř. p ři použití p říkazu ARTICLE zobrazena hlavi čka, prázdná řádka a potom t ělo specifikovaného článku. Nedochází však k přenastavení ukazatele na aktuální článek. Pokud je za p říkazem uveden nepovinný parametr číslo článku v dané diskusní skupin ě, je zobrazen článek s daným po řadovým číslem. Tento postup vede k nastavení ukazatele na aktuální článek. Pokud je ur čeno chybné číslo (nap ř. mimo rozsah článk ů ve skupin ě) k přednastavení ukazatele aktuálního článku nedojde. V případ ě, že je číselný parametr vynechán je zobrazen článek, na který ukazuje ukazatel akt. článku. Není-li ukazatel akt. článku
9 nastaven, je signalizována chyba. Kladná odpov ěď vždy obsahuje číslo článku, kterého se týká, v případ ě, že šlo o formu p říkazu s Message-ID je číslo článku nahrazeno nulou.
Post Syntaxe: POST
Odpov ědi:
Úvodní odpov ědi: 340 Send article to be posted 440 Posting not permitted
Následující odpov ědi: 240 Article received OK 441 Posting failed
Přítomnost tohoto p říkazu je indikována schopností POST. Pokud je zasílání do skupiny povoleno, je navrácen kód 340, který indikuje, že zaslání článku do skupiny m ůže být provedeno. Kód 440 říká, že zasílání do skupiny je z nějakých d ůvod ů zakázáno. Pokud je zasíláni dovoleno, článek by m ěl být prezentován ve form ě specifikované v RFC 3977 [1] a měl by obsahovat všechny povinné řádky hlavi čky. Potom co jsou hlavi čka i t ělo zaslány serveru, server odpovídá kódem, kterým signalizuje úsp ěch nebo neúsp ěch datového p řenosu.
Ihave Syntaxe: IHAVE message-id
Odpov ědi:
Úvodní odpov ědi: 335 Send article to be transferred 435 Article not wanted 436 Transfer not possible; try again later
Následující odpov ědi: 235 Article transferred OK 436 Transfer failed; try again later 437 Transfer rejected; do not retry
Přítomnost tohoto p říkazu je indikována schopností READER. Tento p říkaz informuje server o skute čnosti, že klient má článek, jehož identifikátor je Message-ID. Pokud server požaduje kopii
10 tohoto článku, vrací odpov ěď , kterou klientovi sd ěluje, že má zaslat celý článek. Pokud server článek nechce, bude navrácena odpov ěď , že článek není serverem vyžadován. Pokud je požadováno zaslání článku, m ěl by klient zaslat celý článek (zahrnující jak t ělo tak hlavi čku) na server. Server potom vrací odpov ěď s kódem indikující úsp ěch nebo neúsp ěch p řenosu. Tento příkaz je ur čen pro podporu distribuce článk ů mezi servery.
Date Syntaxe: DATE
Odpov ědi: 111 yyyymmddhhmmss Server date and time
Přítomnost tohoto p říkazu je indikována schopností READER. P říkaz slouží ke zjišt ění aktuálního UTC času na serveru.
Help Syntaxe: HELP
Odpov ědi: 100 Help text follows (multi-line)
Tento p říkaz je povinný. Poskytuje krátký soupis p říkaz ů, které jsou daným serverem implementovány. Text nápov ědy je presentován jako více řádková textová odpov ěď .
Newgroups Syntaxe: NEWGROUPS date time [GMT]
Odpov ědi: 231 List of new newsgroups follows (multi-line)
Přítomnost tohoto p říkazu je indikována schopností READER. Po tomto p říkazu bude zobrazen seznam skupin, vytvo řený od data daného parametry
11 Čas musí být také zadán. Musí být tvo řen 6 číslicemi ve formátu HHMMSS ( HH hodiny 0-23, MM minuty 00-59 a SS sekundy 00-59). P ředpokládá se, že čas je uveden v časové zón ě serveru. Pokud je uveden parametr GMT , jsou čas a datum vyhodnoceny vzhledem k greenwichskému času.
Newnews Syntaxe: NEWNEWS wildmat date time [GMT]
Odpov ědi: 230 List of new articles follows (multi-line)
Přítomnost tohoto p říkazu je indikována schopností NEWNEWS. Seznam identifikátor ů zpráv zaslaných nebo doru čených do diskusních skupin, jejichž název vyhovuje použitému wildmat řet ězci, od doby dané parametrem date bude vypsán tak, že na každém řádku bude uveden práv ě jeden identifikátor zprávy. Poslední řádek bude obsahovat samostatnou te čku. Datum a čas jsou ve stejném formátu jako u p říkazu NEWGROUPS.
List Syntaxe: LIST [keyword [wildmat|argument]]
Odpov ědi: 215 Information follows (multi-line)
Přítomnost p říkazu je indikována schopností LIST. Obecn ě tento p říkaz slouží ke zjišt ění informací o diskusních skupinách. To o jaké informace se jedná je specifikováno parametrem keyword a to, kterých skupin se má tento p říkaz týkat je omezeno parametrem wildmat .
Klí čová slova:
ACTIVE (m ůže být následováno parametrem wildmat) Navrací seznam obsažených diskusních skupin a k nim asociovaných informací. Každá diskusní skupina je zaslána jako řádek textu v následujícím formátu: Group last first p Kde group je jméno diskusní skupiny, last je číslo posledního aktuáln ě známého článku v diskusní skupin ě. First je číslo prvního článku, který je aktuáln ě ve skupin ě. A p je bu ď znak y nebo n a indikuje jestli je zasílání do dané diskusní skupiny povoleno (y) nebo zakázáno (n). Hodnoty first a last jsou vždycky číselné, mohou být uvedeny nulami. Pokud je hodnota last menší než hodnota first , nejsou v dané diskusní skupin ě aktuáln ě žádné p řísp ěvky.
12 Prázdný seznam zakon čený te čkou na samostatném řádku je také možná odpov ěď , která signalizuje, že na serveru nejsou žádné diskusní skupiny.
ACTIVE.TIMES (m ůže být následováno parametrem wildmat ) Navrací řádky skládající se z názvu diskusní skupiny, času vytvo ření skupiny (udaném jako po čet sekund od 1. ledna 1970), a emailové adresy uživatele zodpov ědného za skupinu. Jednotlivá polí čka jsou odd ělena mezerou
DISTRIB.PATS (bez wildmat parametru) Tento p říkaz využívají klienti, aby zjistili jakou hodnotu vložit do hlavi čkového řádku Distribution: u nov ě vytvá řených článk ů. Odpov ěď na tento p říkaz se skládá ze t ří polí ček odd ělených dvojte čkou. První polí čko obsahuje váhu daného řádku, druhé polí čko wildmat (pro rozlišení zda se má zkoumané skupiny týkat) a t řetí polí čko hodnotu, která se má použít pro pole DISTRIBUTION.
NEWSGROUPS (m ůže být následováno parametrem wildmat ) Tento p říkaz zobrazí pro zvolené skupiny řádky, na kterých je jméno diskusní skupiny a mezerou nebo tabelátorem odd ělený krátký textový popis této skupiny.
OVERVIEW.FMT (bez wildmat parametru) Vypíše po řadí a názvy jednotlivých položek v overview databázi (tj. n ěkteré hlavi čkové hodnoty a metadata). Prvních p ět řádků je povinných: Subject: From: Date: Message-ID: References: :bytes :lines
Over Syntaxe: OVER message-id OVER range OVER
Odpov ědi:
První tvar (podle Message-ID) 224 Overview information follows (multi-line) 430 No article with that message-id
Druhý tvar (podle rozsahu) 224 Overview information follows (multi-line) 412 No newsgroup selected
13 423 No articles in that range
Třetí tvar (podle aktuálního článku) 224 Overview information follows (multi-line) 412 No newsgroup selected 420 Current article number is invalid
Přítomnost tohoto p říkazu je indikována schopností OVER. P říkaz vypíše hodnoty z overview databáze pro zadaný článek. Pro každý požadovaný článek vypíše řádek, kde je číslo článku , následované jednotlivými hodnotami, vše je odd ělené tabelátory. Po řadí a typ hodnot, které jsou vypisované je možné zjistit p říkazem LIST OVERVIEW.FMT. P říkaz over se bu ď m ůže týkat práv ě jednoho článku specifikovaného zadáním Message-ID, nebo více článk ů ur čených parametrem range , který má stejný význam a syntaxi jako u p říkazu LISTGROUP.
HDR Syntaxe: HDR field message-id HDR field range HDR field
Odpov ědi:
První tvar (podle message-id) 225 Headers follow (multi-line) 430 No article with that message-id
Druhý tvar (podle rozsahu) 225 Headers follow (multi-line) 412 No newsgroup selected 423 No articles in that range
Třetí tvar (podle aktuálního článku) 225 Headers follow (multi-line) 412 No newsgroup selected 420 Current article number is invalid
Přítomnost tohoto p říkazu je indikována schopností HDR. Tento p říkaz umož ňuje vypsat hodnotu pro požadovaný hlavi čkový řádek z článku, který se bu ď ur čí pomocí Message-ID, nebo pomocí parametru range (stejný význam jako u OVER nebo LISTGROUP), nebo se bude jednat o aktuální článek ve vybrané skupin ě v případ ě, že článek není nijak jinak ur čen. Název hlavi čkového řádku, jehož hodnotu chceme získat, se p ředá pomocí parametru field . Schopnost HDR udává též p řítomnost příkazu LIST HEADER.
LIST HEADER Syntaxe:
14 LIST HEADERS [MSGID|RANGE]
Odpov ědi: 215 Field list follows (multi-line)
Tento p říkaz vypíše názvy hlavi čkových řádk ů získatelných prost řednictvím p říkazu HDR. Použitelné názvy mohou být jiné p ří selekci článku pomocí Message-ID nebo pomocí parametru range . Pro jakou variantu p říkazu HDR chceme seznam použitelných názv ů hlavi čkových článk ů získat specifikujeme nepovinným parametrem.
Příkazy pro autentizaci
Autentizace v ůč i NNTP serveru je popsána v RFC 4643 [10]. V případ ě, že je použito zabezpe čené spojení mezi NNTP klientem a serverem, m ůže být autentizace provedena následujícím zp ůsobem. V případ ě, že je možno se k danému serveru p řihlásit, musí server disponovat schopností AUTHINFO USER. Po úsp ěšném p řihlášení uživatele, již tato schopnost nesmí být v seznamu schopností obsažena. Pro samotné p řihlášení jsou k dispozici následující p říkazy:
Syntaxe: AUTHINFO USER username AUTHINFO PASS password
Odpov ědi: 281 Authentication accepted 381 Password required 481 Authentication failed/rejected 482 Authentication commands issued out of sequence 502 Command unavailable
Uživatel nejprve specifikuje prost řednictvím p říkazu AUTHINFO USER své uživatelské jméno. Server vyzve uživatel k zadání hesla odpov ědí se stavovým kódem 381. Uživatel zadá heslo ke svému účtu prost řednictvím p říkazu AUTHINFO PASS. V případ ě, že je autentizace úsp ěšná, je navrácena odpov ěď s kódem 281, v opa čném p řípad ě server navrací chybovou odpov ěď s kódem 481. Pokusí-li se uživatel zadat p říkaz AUTHINFO USER, aniž by p ředchozím p říkazem zadal své uživatelské jméno, je serverem navrácena odpov ěď s kódem 482. V případ ě, že je již uživatel úsp ěšn ě p řihlášen, odpovídá server na další pokusy o p řihlášení odpov ědí se stavovým kódem 502.
Odpov ědi NNTP Serveru
Existují dva druhy odpov ědí, odpov ědi vracející status a odpov ědi textové. Textová odpov ěď je zaslána pouze po numerické hodnot ě udávající status a signalizující, že bude následovat text. Text je zaslán jako série řádk ů, ukon čených dvojicí CRLF. Řádek obsahující
15 pouze te čku je použit k signalizaci konce textové odpov ědi (jedná se o posloupnost znak ů CRLF.CRLF). Z tohoto d ůvodu musí být te čky na samostatné řádku v těle zpráv zdvojeny a pak p ři interpretaci klientem op ět uvedeny do p ůvodního stavu. Toto p ředzpracování a zapracování je v režii NNTP klient ů. Status obsažený v informacích udává odpov ěď na naposledy p řijatý p říkaz od klienta. Odpov ěď s informací o statusu se skládá z číselného kódu (3 číslice) a n ěkteré tyto odpov ědi mohou obsahovat ješt ě textové up řesn ění.
První číslice výstupu signalizuje úsp ěch, chybu, nebo proces zpracování p ředchozího p říkazu: 1xx – Informa ční zpráva 2xx – P říkaz OK 3xx – Zatím je p říkaz OK, zašlete jeho zbytek 4xx – P říkaz byl správn ě, ale z nějakého d ůvodu nem ůže být proveden 5xx – P říkaz neimplementován nebo je nesprávný, nebo nastala n ějaká vážná chyba v programu.
Další číslice v kódu indikuje kategorii odpov ědi na funkci: x0x – Spojení, nastavení x1x – Výb ěr diskusní skupiny x2x – Výb ěr článku x3x – Distribu ční funkce x4x – Zasílání x8x – Nestandardní (vyhrazené pro soukromou implementaci) rozší ření x9x – Ladící výstup
Některé odpov ědi obsahující status mohou obsahovat též parametry jako číslice a jména. Číslo a pozice takovýchto parametr ů jsou stálé pro každý kód odpov ědi. Parametry v odpov ědích jsou od sebe a od kódu odpov ědi odd ěleny jednou mezerou. Jedná-li se o číselné parametry jsou uvedeny v desítkové soustav ě a mohou být uvedeny nulou.
Příklad dvou obecných odpov ědí serveru: 200 server ready - posting allowed 502 access restriction or permission denied
Kdykoliv b ěhem sezení m ůže server klientovi zaslat jednu z těchto obecných odpov ědí: • 500 – pokud p říkaz není rozeznán, nebo není serverem implementován.
16 • 501 – pokud je chyba v syntaxi argument ů rozeznaného p říkazu, nebo pokud je p říkaz delší než je povoleno. Stejn ě tak musí být tento kód navrácen v případ ě, že základní p říkaz je implementován, ale není implementována n ějaká jeho nepovinná varianta. • 403 – v případ ě, že došlo k interní chyb ě serveru. • 480 – klient se musí autentizovat. • 483 – klient musí založit bezpe čnou komunikaci na již navázaném spojení (nap ř. prost řednictvím SSL, nebo TLS). • 401 – klient musí zm ěnit stav spojení n ějakým jiným zp ůsobem. • 400 – server ukon čil z nějakého d ůvodu spojení s klientem.
Formát diskusních p řísp ěvk ů
Formát diskusních p řísp ěvk ů byl p ůvodn ě definován standardem RFC 850 [5], nyní je definován přímo v RFC 3977. Článek se skládá ze dvou částí – hlavi čky a t ěla. Tyto části jsou odd ěleny pomocí jednoho prázdného řádku, jinými slovy pomocí dvou následujících pár ů CRLF. Aby článek spl ňoval obecné požadavky NNTP, článek nesmí obsahovat bajt s hodnotou NUL, nesmí obsahovat bajty s hodnotami LF a CR, pokud tyto netvo ří dvojici CRLF. A musí kon čit dvojicí CRLF. Tato specifikace neklade žádné další omezení na t ělo článku, m ůže být i prázdné. Hlavi čka článku se skládá z jednoho a více hlavi čkových řádk ů. Každý takový řádek se skládá z názvu, dvojte čky, mezery, obsahu a dvojice CRLF v uvedeném po řadí. Jméno se skládá z jednoho nebo více tisknutelných ASCII znak ů jiných než dvojte čka a pro ú čely RFC 3977 není citlivé na velikost písmen. M ůže existovat více hlavi čkových řádk ů se stejným jménem. Obsah nesmí zahrnovat dvojici CRLF, ale m ůže být prázdný. Hlavi čkový řádek m ůže být rozložen do více řádk ů, pokud se CRLF dvojce umístí p řed znak mezery nebo tabelátoru na řádku. Znaky CRLF ur čené pro roz řádkování nejsou považovány za obsah hlavi čkového řádku. Obsah hlavi čky by m ěl být v kódové sad ě UTF-8. Každý článek musí mít unikátní Message-ID, dva r ůzné články na serveru nesm ějí mít stejné Message-ID. Message-ID musí spl ňovat následující požadavky. Message-ID musí za čínat znakem „<“ a kon čit znakem „>“. A tyto znaky nesmí obsahovat jinde než na konci. Message-ID. Musí mít délku 3 až 250 znak ů. Message-ID se nesmí skládat z jiných znak ů, než z tisknutelných US-ASCII znak ů. Dv ě Message-ID jsou stejná, pokud a jenom pokud se skládají ze stejné sekvence bajt ů.
17 Popis HTTP protokolu
Úvod
Hypertext Transfer Protocol – HTTP/1.1 je definován v RFC 2616 vydaném v červenci roku 1999. V dnešní dob ě je tato verze protokolu HTTP implementovaná ve všech dostupných prohlíže čích. A obecn ě je protokol HTTP jedním z nejpoužívan ějších protokol ů v Internetu. Jedná se o pom ěrn ě jednoduchý protokol. Komunikace je textová a probíhá metodou dotaz odpov ěď . Tento protokol pracuje s adresami URL a zpracovává informace r ůzných typ ů tj. hypertextové informace (text, obraz, video, …). Pomocí odkaz ů vytvá ří orientovaný graf po jehož struktu ře se uživatel pohybuje. Jedná se o bezstavový protokol, který má jen málo p říkaz ů, které se zde nazývají metody. Standard MIME je využit pro zakódování dat p řenášených http protokolem, což umož ňuje p řenášet tém ěř jakýkoliv typ dat. Jedná se o protokol typu klient/server . Komunikace mezi klientem a serverem probíhá pomocí protokolu TCP/IP a výchozím portem je port 80. Jak už bylo řečeno HTTP je textový protokol, kde jednotlivé pole hlavi čky mají obecn ě tvar jméno pole : hodnota pole a jsou ukon čeny dvojicí znak ů CR LF. Řádk ů hlavi čky m ůže být u r ůzných zpráv r ůzný po čet. Za hlavi čkou následuje prázdný řádek a pak vlastní t ělo zprávy zakódované podle standartu MIME (informace o MIME kódování a typu aplikace jsou uvedeny v hlavi čce). Rozlišujeme dva typy zpráv - požadavky a odpovědi
Požadavky
Zpráva s požadavkem z klienta na server obsahuje metodu, která bude aplikována na zdroj, identifikaci zdroje a verzi protokolu. Request = Request-Line *(( general-header | request-header | entity-header ) CRLF) CRLF [ message-body ]
Požadavek za číná řádkou Request-line , která za číná specifikací metody a za mezerou pokra čuje URI zdroje a za další mezerou je verze protokolu HTTP. Request-Line = Method SP Request-URI SP HTTP-Version CRLF
Jednotlivé metody říkají co se má s danými daty na daný požadavek provést. Zde je seznam metod protokolu HTTP 1.1:
Method = "OPTIONS" | "GET" | "HEAD" | "POST" | "PUT" | "DELETE" | "TRACE" | "CONNECT"
18 | extension-method extension-method = token
Pro ú čely tohoto projektu sta čí popsat pouze nejvýznamn ější metody. Nejprve se jedná o metodu GET. P říkaz GET zasílá klient a jeho provedení má za následek na čtení dat specifikovaných adresou URL v požadavku ze serveru a jejich zaslání klientovi. Další metodou je metoda HEAD, která se do zna čné míry podobá p říkazu GET. Návratovou hodnotou po provedení tohoto p říkazu jsou ale pouze meta informace o zdroji na dané URL. Další metodou je metoda POST, která slouží pro zasílání údaj ů z klienta na server. M ůže se nap říklad jednat o data odeslaná pomocí formulá ře na webové stránce. Data lze na server zaslat i pomocí metody GET a jejich za člen ění do URL, ale v tomto p řípad ě je délka zasílaných dat omezena maximální délkou URL. U metody POST toto omezení není. Metoda PUT již nepat ří mezi povinn ě podporované p říkazy, sloužila k odeslání dat z klienta na server. Metoda DELETE není také b ěžn ě podporovaná. Jejím ú čelem je vznesení požadavku o odstran ění zadané URL.
Odpov ědi
Po obdržení zprávy s požadavkem vrací server odpov ěď .
Response = Status-Line *(( general-header |response-header | entity-header ) CRLF) CRLF [ message-body ]
Odpov ěď za číná řádkem Status-Line, dále následují řádky hlavi čky. Každý řádek je ukon čen dvojicí CR LF za prázdným řádkem pak m ůže následovat t ělo zprávy. Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line nejprve obsahuje verzi protokolu, mezeru, číselný kód odpov ědi, další mezeru a dopl ňující textovou informaci. Protokol HTTP definuje množinu stavových kód ů, jimiž dává najevo v jakém stavu se požadavek nachází. Stavový kód se skládá ze t ří číslic, která stav identifikují a následného textového řet ězce, který stav vysv ětluje. Zde je seznam nej čast ěji se vyskytujících návratových kód ů:
Stavový kód Textové vysv ětlení 200 OK Požadavek úsp ěšn ě spln ěn. 201 Created Požadavek typu POST úsp ěšn ě vy řízen. 202 Accepted Odpov ěď na asynchronní požadavek, potvrzení jeho správného p řijetí. 204 No Content Požadavek byl úsp ěšný, ale není co zobrazit.
19 300 Multiple Choices Požadovaný dokument je dostupný z více míst. V odpov ědi se vrací seznam možností. Pole Location odpov ědi obsahuje možnost doporu čenou serverem. 301 Moved Požadovaná adresa URL byla p řesunuta na jinou URL, která je obsažena Permanently v poli Locations odpov ědi. 302 Moved Požadovaná adresa byla p řesunuta do časn ě na jinou adresu, ta je op ět Temporarily uvedena v poli Locations. 304 Not Modified Dokument nebyl od doby definované polem If-Modified-Sience modifikován. 400 Bad Request Server nerozumí požadavku. 401 Unauthorized Požadavek musí být autentizován. 403 Forbiden Požadavku nelze vyhov ět. 404 Not Found Zadané URL nebylo nalezena. 500 Internal Server Vnit řní chyba serveru . Error 501 Not Implemented Požadavek není implementován. 502 Bad Gateway Brána obdržela od serveru neplatnou odpov ěď . 503 Service Server do časn ě nem ůže zpracovat požadavek (nap říklad z důvodu Unavailable přetížení).
URL
URL (Uniform Ressource Locator) p ředstavuje konec šipky orientovaného grafu hypertextového prost ředí. Obsahuje ur čení protokolu, IP adresy zdroje ( často prost řednictvím pln ě kvalifikovaného doménového jména), číslo portu a p řesnou lokaci požadovaného prost ředku. Obsaženy mohou být další dodate čné informace, nej čast ěji ve form ě parametru pro interpret zpracovávající data. P říklad URL: http://login.seznam.cz:80/?language=cz&remember=0&set_disableSSL=0&set_forceSSL=0&logged URL=http%3A%2F%2Femail.seznam.cz%2Fticket&serviceId=email
Pole v hlavi čkách
Obecná pole: Tato pole se vyskytují nezávisle na tom jestli se jedná o požadavek nebo odpov ěď . Connection Ur čení voleb týkajících se spojení, token close signalizuje, že se jedná o poslední požadavek b ěhem persistentního spojení. Date Definice data a času vzniku zprávy
20 Pragma Pole obsahující direktivy závislé na konkrétní implementaci Transfer-Encoding Ur čuje metodu kódování aplikovanou na p řenášená data
Pole v požadavcích Accept Typy standartu MIME, které budou akceptované v odpov ědích. Je možné použít zástupný znak hv ězdi čky Accept-Charset Akceptovatelné znakové sady. Krom ě implicitních. Accept-Encoding Obsahuje množinu p řijatelných hodnot pole Content-Encoding v odpov ědi. Hodnota je definovaná standardem MIME Accept-Language Omezuje množinu akceptovaných jazyků v odpov ědi Authorization Pro použití serveru, které nedovolují anonymní p řístup ke zdroj ům. Zasílají se též informace o oprávn ění uživatele. From E-mailová adresa uživatele, který odeslal požadavek Host Specifikuje adresu a port serveru na kterém klient žádá o data If-Modified-Since Modifikátor p říkaz ů GET. GET na čte pouze data v případ ě, že byla od zadaného časového údaje modifikována Referer Ur čuje URL z něhož získal klient požadované URL User-Agent Jméno a verze klienta HTTP
Pole v odpov ědích Age Sd ěluje zasilateli o čekávané množství času od doby, kdy byla odpov ěď vygenerována na p ůvodním serveru. Location Využití tohoto pole je popsáno výše. Proxy-Authenticate Toto pole musí být sou částí odpov ědi s kódem 407 a hodnota obsahuje autentika ční schéma a parametry aplikovatelné na Proxy-Server. Etag Poskytuje konkrétní hodnotu entity pro požadovanou variantu. Retry-After Pole definuje časový interval, po který nebudou požadované služby k dispozici. Server Jméno a verze serveru HTTP. Accept-Ranges Umož ňuje serveru zjistit jeho akceptování ur čitého rozsahu požadavku na daný zdroj WWW-Authenticate Pole se používá pro p řístup s jednoduchou autentizací typu výzva/odpov ěď . Informace o uživatelském oprávn ění se nešifrují
21 Spojení:
HTTP/1.1 server by m ěl p ředpokládat, že HTTP/1.1 klient bude chtít udržovat persistentní spojení, dokud nezašle řádek hlavi čky Connection s hodnotou close . Pokud server uzav ře spojení ihned po obsloužení požadavku, m ěl by vybavit řádek hlavi čky Connection hodnotou close . Pokud klient nebo server zašlou hodnotu close uvnit ř řádku hlavi čky Connection , požadavek se stává posledním požadavkem pro dané spojení.
Služby systému Windows NT
Služba NT je proces b ěžící na pozadí, který je spušt ěn Service Control Managerem jádra systému NT. Obvykle je služba spušt ěna po startu systému, ješt ě p řed tím, než se n ějaký uživatel p řihlásí k systému a b ěží nezávisle na p řihlášení r ůzných uživatel ů k systému. Není-li služba spušt ěna automaticky p ři startu systému, m ůže být spušt ěna uživatelem bu ďto p řes ovládací panel Služby, nebo prost řednictvím jiného programu, který obsahuje rozhraní pro ovládání Service Control Manageru. Jedním z mnoha typ ů program ů, který p římo vybízí k implementaci v podob ě služby systému NT jsou sí ťové servery, u nichž často vyžadujeme nep řetržitý b ěh, který není nijak ovlivn ěn p řihlašováním a odhlašováním uživatel ů k systému. Služby jsou normální 32 bitové aplikace pro systém Windows a mohou být bu ď vybaveny grafickým uživatelským rozhraním ( s WinMain() funkcí) nebo mohou být pouze konzolové ( s main() funkcí). Hlavní funkce služby by nem ěla d ělat nic, pouze zaregistrovat servisní ServiceMain() (tento název je dán konvencí, ale m ůže být i jiný) funkci, zavoláním StartServiceCtrlDispatcher() a skon čit. Systém Windows NT bude potom volat zaregistrovanou funkci ServiceMain() při požadavku na spušt ění služby. ServiceMain() by potom m ěla spustit hlavní vlákno, které aktuáln ě provádí kód vlastní služby. Po tomto se však funkce ServiceMain() nesmí ukon čit do té doby, než je služba zastavena. V případ ě, že je pot řeba službu restartovat, Service Control Manager jednoduše znovu zavolá funkci ServiceMain(). Funkce Handler() p řejímá řídící požadavky od Service Control Manageru. Zde je uvedena standardní množina požadavk ů, kterou používá SCM k řízení služby:
• Stop (SERVICE_CONTROL_STOP): Přikáže služb ě, aby se zastavila. • Pause (SERVICE_CONTROL_PAUSE): P řikáže služb ě, aby provedla operaci pauza. • Continue (SERVICE_CONTROL_CONTINUE): Přikáže služb ě, aby obnovila sv ůj běh po pauze. • Interrogate (SERVICE_CONTROL_INTERROGATE): Požaduje zjišt ění aktuálního stavu služby • ShutDown (SERVICE_CONTROL_SHUTDOWN): Signalizuje služb ě, že nastává vypnutí systému
22 Funkce Handler() pak p říchozí požadavky obsluhuje r ůznými zp ůsoby. Požadavky Pause a Continue jsou obslouženy jednoduchým pozastavením a op ětovným spušt ěním hlavního vlákna. Požadavky ShutDown a Stop v ětšinou vedou k nastavení sdílené prom ěnné, která se testuje v hlavním vláknu a v případ ě, že její stav signalizuje konec, je hlavní jádro ukon čeno a taktéž je následn ě ukon čeno vlákno ServiceMain() . Požadavek Interrogate je obsloužen aktualizací informace o stavu služby. Tato aktualizace je provedena i p ři jakékoliv jiné zm ěně stavu. Stavy, ve kterých se služba může nacházet, jsou následující:
- SERVICE_START_PENDING - SERVICE_RUNNING - SERVICE_PAUSE_PENDING - SERVICE_PAUSED - SERVICE_CONTINUE_PENDING - SERVICE_STOP_PENDING
Služb ě mohou být též p ředány uživatelsky definované řídící požadavky a jakékoliv pot řebné parametry mohou být umíst ěny v systémovém registru a to v oblasti vyhrazené pro danou službu. Každá služba m ůže vytvá řet podklí če a hodnoty ve svém klí či:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Kde Servicename je jméno služby registrované v ControlManageru.
Rela ční databáze
Úvod
Rela ční databáze (pop ř. rela ční databáze s podporou objekt ů) jsou v dnešní dob ě nejpoužívan ější databázovými systémy. V roce 1969 p řišel doktor E. F. Codd se svou p ředstavou o databázi založené na matematickém aparátu rela čních množin a predikátové logiky. Databázová relace se od matematické pon ěkud liší. Má zavedený pomocný aparát nazvaný schéma relace. Schéma relace říká, jaký je název relace, kolik má atribut ů a jaké jsou jejich názvy a domény (doména ur čuje p řípustné hodnoty pro daný atribut). V databázích je schématem relace definice struktury tabulky. Jednotlivé atributy tvo ří sloupce tabulky. Každý sloupec má definován jednozna čný název, typ a rozsah (doménu). Záznam se stává n-ticí ( řádkem) tabulky. Pokud jsou v r ůzných tabulkách sloupce stejného typu, pak tyto sloupce mohou vytvá řet vazby mezi jednotlivými tabulkami. Tabulky se poté napl ňují vlastním obsahem - konkrétními daty. Ovšem relací není jenom tabulka, ale cokoliv strukturovaného do řádk ů a sloupc ů. Což znamená, že relací je i výsledek jakéhokoliv dotazu, a tak s ním m ůžeme pracovat. Kolekce více tabulek, jejich funk čních vztah ů, index ů a dalších sou částí tvo ří rela ční databázi.
23 Cizí klí č je sloupec databázové tabulky, který odkazuje na jiný sloupec (jiné tabulky nebo i stejné tabulky). Hodnoty takového sloupce musí být shodné s n ěkterou z hodnot ve sloupci, ke kterému je klí čem. Vytvá ří se tak reference – odkaz. Podmínka shody se kontroluje p ři všech operacích nad databází, což se ozna čuje jako referen ční integrita. Primární klí č je pole nebo kombinace atribut ů, jednoznačně identifikující každý řádek v databázové tabulce. Žádný atribut, který je sou částí primárního klí če, nesmí obsahovat nedefinovanou hodnotu. Každá tabulka m ůže mít definovaný pouze jeden primární klí č. Primární klí č musí mít následující vlastnosti: jedine čnost, nem ěnnost, nenulovou hodnotu. Typickým p říkladem primárního klí če je rodné číslo v seznamu osob, identifika ční číslo v seznamu podnik ů apod.
SQL
SQL je standardizovaný dotazovací jazyk používaný pro práci s daty v rela čních databázích. SQL je zkratka anglických slov Structured Query Language (strukturovaný dotazovací jazyk). SQL p říkazy se typicky d ělí do čty ř základních skupin. 1. Příkazy pro manipulaci s daty – jedná se o p říkazy ur čené pro získávání a modifikaci dat. Ozna čují se jako DML – Data Manipulation Language (jazyk pro manipulaci s daty). 2. Příkazy pro definici dat – jedná se o p říkazy ur čené k vytvá ření jednotlivých struktur databáze (tabulek, index ů, pohled ů, …). N ěkteré struktury lze také upravovat. Tato skupina p říkaz ů se nazývá DDL – Data Definition Language (jazyk pro definici dat). 3. Příkazy pro řízení databáze – jedná se o p říkazy ur čené k nastavování přístupových práv a řízení transakcí. Ozna čují se jako DCL – Data Control Language, n ěkdy také TCC – Transmission Control Commands. 4. Ostatní p říkazy jsou ur čeny pro správu databáze. Pomocí nich lze p řidávat uživatele a nastavovat systémové parametry. Tato skupina není standardizována a konkrétní syntaxe příkaz ů závisí na použitém databázovém systému.
Pro modelování struktury rela ční databáze se používají ER diagramy.
Regulární výrazy
Regulární výrazy budou v tomto projektu využity p ředevším pro lexikální analýzu, tj. pro zjiš ťování, zda p říkazy zaslané na server spl ňují formu p ředepsanou standardem. A dále budou použity pro získání pod řet ězc ů z řet ězc ů s p říkazem, nap ř. pro získání konkrétních parametr ů zaslaného p říkazu. Formální definice regulárních výraz ů je následující: Regulární výrazy nad kone čnou abecedou Σ a regulární množiny, které ozna čují, jsou rekurzívn ě definovány takto: I. ε je regulární výraz ozna čující regulární množinu { ε }
24 II. Ø je regulární výraz ozna čující regulární množinu Ø III. a je regulární výraz ozna čující regulární množinu {a} pro všechny a z Σ, IV. jsou-li p, q regulární výrazy ozna čující regulární množiny P a Q, pak a. (p + q) je regulární výraz ozna čující regulární množinu P U Q , b. (pq ) je regulární výraz ozna čující regulární množinu P.Q , c. (p*) je regulární výraz ozna čující regulární množinu P*. V. Žádné jiné regulární výrazy nad ∑ neexistují.
Při praktickém použití se obvykle využívají rozší řené definice regulárních výraz ů, které umož ňují b ěžné konstrukce zapsat jednodušším zp ůsobem (ale schopnosti takto rozší řených výraz ů se od základní definice neliší). Nej čast ější jsou následující konstrukce: • Namísto znaku + (plus) se pro alternativy používá znak | • Výb ěr z uvedených znak ů: zápis [a-z0-9A-Z] znamená libovolný znak v rozsahu a–z, 0–9,A-Z (tedy alfanumerický znak). • Jeden z neuvedených znak ů: zápis [^a-z0-9A-Z] znamená libovolný znak mimo znak ů v rozsahu a–z, 0–9,A-Z. V některých implementacích se místo st říšky používá znak ! (vyk řičník). • Libovolný znak : symbol . (te čka) znamená jakýkoliv libovolný znak. • Vymezení za čátku řet ězce : zápis ^n ějakývýraz popisuje pouze takové řet ězce nějakývýraz , které se nachází na za čátku řádku. • Vymezení konce řet ězce: zápis nějakývýraz$ popisuje pouze takové řet ězce nějakývýraz , které se nachází na konci p řed koncem řádku. • Volitelná část: zápis xy? znamená, že znak x m ůže, ale nemusí, být následován znakem y. • Libovolný po čet opakování, ale nejmén ě jednou: zápis x+ vyžaduje (narozdíl od x* ) alespo ň jeden výskyt znaku x (a je ekvivalentní k zápisu xx* ). • Ur čený po čet opakování: zápis x{3,6} popisuje, že znak x se musí opakovat minimáln ě t řikrát a maximáln ě šestkrát. • Definované množiny znak ů: n ěkteré speciální skupiny znak ů mají zkratkový zápis, nap ř. \d pro libovolnou desítkovou číslici, \s pro bílý znak apod.
Návrh systému
Návrh struktury aplikace
Struktura aplikace je znázorn ěna na obr. 1.
25 Webový prohlíže č NNTP klient GUI konfigurátor
HTTP rozhraní pro NNTP rozhraní pro Soubor s přístup k diskusi přístup k diskusním konfigurací NNTP klient přísp ěvk ům
NNTP klient Diskusní server
Vzdálené NNTP Databáze MySQL servery
Obr. 1: Struktura aplikace
Základem je databázový systém, pro ukládání všech pot řebných persistentních informací, kterými jsou diskusní skupiny, diskusní články a s nimi asociované údaje. Vytvá řený NNTP server je ve skute čnosti program poskytující sí ťové rozhraní s příkazy NNTP protokolu pro p řístup k databázi. Druhým programem je HTTP Server, který má v sob ě integrovaného NNTP klienta. Tento server převádí HTTP požadavky na NNTP p říkazy a zasílá je NNTP serveru. P říchozí odpov ědi navrací jako HTML stránky. Takto zvolená struktura aplikace navíc umož ňuje mít server umíst ěný na jiném po číta či, než je umíst ěn databázový systém a stejn ě tak je umožn ěno, aby nad danou databází operovalo více server ů. Uživatel tak m ůže využít pro p řístup k diskusním p řísp ěvk ům specializovaného NNTP klienta (Mozilla Thunderbird, Outlook Express) nebo webový prohlíže č. Dále umož ňuje, aby HTTP rozhraní zobrazovalo články z nějakého cizího NNTP serveru, pokud je lokální NNTP server v proxy módu. Protože bývá problém s grafickým rozhranním programu, který b ěží jako služba NT, je konfigurátor odd ělená aplikace s GUI, která pouze vygeneruje konfigura ční soubor. Tento konfigura ční soubor si na čte služba p ři startu, resp. p ři restartu. Konfigura ční program obsahuje též grafické rozhranní k databázi, pomocí kterého se dá provád ět administrace (p řidávání/ odebírání skupin, článk ů, uživatel ů, ...) NNTP server navíc obsahuje NNTP klienta, který se spouští v ur čitých časových okamžicích a který stahuje nové články a diskusní skupiny ze vzdálených diskusních server ů a ukládá je do lokální databáze.
26 Návrh NNTP rozhraní
NNTP rozhraní bude reprezentované vlastním programem, ve kterém se nejprve na čtou konfigura ční informace. Ty obsahují informace o tom, na kterém portu má NNTP server naslouchat a zda bude pracovat s lokální databází a nebo bude p řeposílat požadavky na vzdálený NNTP server tj. bude v módu proxy. V případ ě proxy módu jsou IP adresa a port vzdáleného NNTP serveru obsaženy také v množin ě konfigura čních informací. Nejprve dojde k vytvo ření serverového socketu pro protokol TCP/IP, který m ůže být voliteln ě zabezpe čený. Následn ě se zahájí naslouchání na daném socketu. V cyklu se bude testovat, zda se nevyskytlo n ějaké p říchozí spojení. Pokud tomu tak je, tak se toto spojení akceptuje. Dále se vytvo ří a spustí obsluhující vláknu a tomuto vláknu se jako parametr p ředá socket s příchozím spojením a jeho úkolem je p říchozí spojení obsloužit. Funkce reprezentující obslužné vlákno budou dv ě: jedna se bude používat pro obsluhu proxy módu a druhá pro obsluhu práce s lokální databází. Při práci se socketem je také možnost použití časova če, který vyprší v případ ě, že po nastavenou dobu nedojde k žádné vstupn ě výstupní operaci na daném socketu. V takovém p řípad ě bude klientovi zaslána zpráva Connection Timeout a spojení bude uzav řeno. Funkce reprezentující vlákno použité k zajišt ění komunikace v proxy módu bude vypadat následovn ě. Po akceptování p říchozího spojení server vytvo ří klientský socket, pomocí n ěhož se připojí na vzdálený NNTP diskusní server. IP adresa tohoto serveru a port služby budou obsaženy v množin ě konfigura čních informací. Po úsp ěšném p řipojení na vzdálený server budou data mezi klientským a serverovým socketem p řenášena následovn ě. Data na čtená z klientského socketu se zapíší do serverového socketu a data na čtená z klientského socketu budou zapsána do serverového socketu. Do dat nebude programem nijak zasahováno, tj. nebudou nijak upravována ani filtrována. Stejn ě tak jsou mezi ob ěma sockety propagována uzav ření socket ů. Tj. v případ ě že je uzav řen jeden ze socket ů, je následn ě uzav řen i ten druhý. Funkce reprezentující vlákno obsluhující požadavky na lokální databázi s diskusními p řísp ěvky bude vypadat asi následovn ě. V případ ě, že funkce o čekává na vstupu p říkaz NNTP protokolu, bude maximální délka p řijímaných dat omezena na 512 znak ů. P ři p řekro čení této velikosti bude zobrazena chybová zpráva. Pro každý p říchozí p říkaz bude zjišt ěno, zda vyhovuje n ěkterému z regulárních výraz ů, které budou nastaveny tak, aby pokrývaly syntaxi p říkaz ů NNTP standardu. Pokud p říkaz nevyhovuje žádnému z regulárních výraz ů, jedná se o nepodporovaný nebo chybn ě zapsaný p říkaz a o této skute čnosti je op ět uživateli podáno chybové hlášení. Pomocí regulárních výraz ů se také ze syntakticky dob ře zapsaných p říkaz ů extrahují parametry. U některých složitých p říkaz ů jako nap ř. příkaz NEWNEWS bude pot řeba použít i víceúrov ňovou extrakci parametr ů prost řednictví regulárních výraz ů. Na základ ě toho o jaký dotaz se jednalo a jaké parametry byly zadány, se vytvo ří p říkaz SQL. V některých p řípadech je pot řeba transformovat NNTP p říkaz na sekvenci SQL dotaz ů. Takto formulované dotazy jsou zaslány modulu, který zprost ředkovává komunikaci mezi serverovým
27 rozhraním a databázovým systémem. Tento modul provede databázové dotazy a navrátí data získaná jako výsledek t ěchto dotaz ů. Ta potom budou serverovým rozhraním transformována na odpov ědi vyhovující NNTP standadtu. Tyto odpov ědi budou zaslány pomoci socketu klientovi. Mírn ě odlišné je zpracováni p říkazu POST, kdy se nejprve na čtou textová data, jejichž maximální délka je omezena konfigura čními nastaveními, a teprve po na čtení t ěchto dat je zkonstruován SQL p říkaz, kterým se data zapíší do databáze. V případ ě, že je databázový systém nedostupný je uživateli sd ěleno informa ční hlášení o vnit řní chyb ě programu.
Návrh HTTP rozhraní
Sí ťový podsystém HTTP rozhraní je stejný jako u rozhraní NNTP, tj. op ět existuje hlavní serverové vlákno inicializované podle konfigura ční nastavení, které spouští jednotlivá vlákna obsluhující příchozí požadavky. Funkce, kterou je reprezentováno vlákno obsluhující p říchozí požadavky bude pracovat následujícím zp ůsobem. Funkce bude o čekávat požadavek založený na metod ě GET nebo POST a na protokolu HTTP/1.1 nebo HTTP/1.0. Pokud budou tato dv ě kritéria spln ěna, z URL požadavku se vypreparuje požadovaný cíl. Na základ ě toho, na jaký imaginární cíl požadavek odkazuje se zavolá p říslušná funkce. Nejprve se o čekává, že klient bude chtít zobrazit úvodní stránku tedy cílem požadavku bude „/“. Server na základ ě tohoto požadavku vygeneruje HTML stránku, která bude obsahovat seznam diskusních skupin na serveru. Seznam skupin a další informace se vždy získají prost řednictvím integrovaného NNTP klienta, který se p řipojí na lokální NNTP server (zabezpe čeným nebo nezabezpe čeným spojením), prost řednictvím p říkaz ů NNTP protokolu získá požadované informace a následn ě je transformuje na HTML kód. Ve výše uvedeném seznamu diskusních skupin bude každá položka odkazem na seznam článk ů ve zvolené diskusní skupin ě, který bude organizován podobn ě jako seznam diskusních skupin, ale místo názv ů skupin v něm budou uvedeny p ředm ěty, auto ři a data jednotlivých článk ů. Každá položka tohoto seznamu bude odkazem na článek jejíž předm ět ji tvo ří. V seznamu bude implementováno řazení a odsazení jednotlivých řádk ů tak, aby odpovídalo hierarchii odpov ědí mezi články. Sou částí stránky bude též odkaz k zobrazení formulá ře pro zaslání nového článku a odkaz pro návrat na p ředchozí stránku. Pokud je požadováno zobrazení n ějakého článku, je odkaz na n ěj specifikován dv ěma parametry a to pomocí identifikátoru diskusní skupiny a číslem článku v diskusní skupin ě.. V případ ě, že je požadováno zobrazení článku, je vygenerována speciální stránka, na které bude zobrazen odesílatel (obsah hlavi čky From ), datum (obsah hlavi čky Date ) a p ředm ět (obsah hlavi čky Subject ) článku. Dále bude následovat t ělo článku. Sou částí každé stránky se zobrazeným článkem budou odkazy na následující článek v dané diskusní skupin ě (pokud existuje), na p ředcházející článek v dané skupin ě (pokud existuje), odkaz pro odpov ěď na článek a odkaz pro návrat na p ředchozí stránku. V případ ě, že se nepoda ří dané URL p řevést na n ějaké volání interní funkce, nebo parametry zadané jako sou část
28 URL nebudou správné, nap ř. budou odkazovat na neexistující článek apod., bude vrácena odpov ěď 404 Not Found . V případ ě, že bude server NNTP vyžadovat autorizaci, bude zobrazeno webovým klientem okno pro zadání uživatelského jména a hesla a tyto autentiza ční údaje budou zaslány NNTP serveru.
Návrh konfigura čního rozhraní
Bude se jednat o samostatný program, který zobrazí grafické uživatelské rozhranní pro zadání pot řebných konfigura čních informací. Po zadání t ěchto informací uživatelem program zkontroluje správnost zadaných údaj ů a v případ ě, že je vše v po řádku, uloží zadané informace do souboru. Pokud je v údajích detekována n ějaká chyba, bude uživateli zobrazeno chybové hlášení. Druhá část tohoto rozhranní bude zprost ředkovávat grafické zobrazení informací uložených v databázi a jejich administraci, kterou se myslí administrace uživatel ů, diskusních skupin, článk ů, distribu čních vzor ů a seznamu server ů pro vzdálené stahování diskusních p řísp ěvk ů.
Návrh automatizovaného NNTP klienta
Základem vlákna zajiš ťujícího toto distribu ční rozhraní bude časova č, který jednou za nastavený čas spustí NNTP klienta. Tento NNTP klient bude mít za úkol z databáze na číst IP adresy vzdálených NNTP server ů, na tyto adresy se p řipojit a postahovat nové články z diskusních skupin. Wildmats řet ězce pro vymezení názv ů požadovaných diskusních skupin budou taktéž v databázi. Po provedení těchto krok ů se NNTP klient ukon čí. Přesn ěji bude b ěh NNTP klienta fungovat následovn ě. Nejprve se na čte seznam IP adres vzdálených NNTP server ů a seznam diskusních skupin pro aktualizaci. Potom se NNTP klient za čne v cyklu postupn ě p řipojovat prost řednictvím socket ů k jednotlivým server ům. Z databáze si vyzvedne čas poslední aktualizace článk ů (tj. čas svého posledního spušt ění) a následn ě serveru zašle p říkaz NEWGROUPS pro zjišt ění, zda od té doby nebyly na serveru vytvo řeny n ějaké nové diskusní skupiny. Pokud tomu tak je, vytvo ří ve své databázi nové diskusní skupiny. Následn ě zašle p říkaz NEWNEWS s parametrem wildmats ur čujícím názvy požadovaný skupin, které hodlá aktualizovat, a datem poslední aktualizace. V případ ě, že v požadovaných diskusních skupinách jsou n ějaké nové články, vrátí server v odpov ědi seznam identifikátor ů t ěchto článk ů. Pomocí p říkazu ARTICLE
29
Návrh databáze
Pro zvolenou aplikaci bude použit databázový systém MySQL, ve kterém bude vytvo řeno šest tabulek pro uložení informací o diskusních skupinách, o jednotlivých článcích, o náležitostech článk ů ke skupinám, o uživatelských ú čtech, ú čtech vzdálených NNTP server ů a o distribu čních vzorech. Pro
bližší popis je zde umíst ěn ER diagram (obr. 2).
Obr. 2: ER diagram
Implementace systému
Projekt je implementován v programovacím jazyce Java a ke komunikaci s databázovým prost ředím MySQL využívá rozhraní JDBC (ovlada č Connector/J 5.0.4). Jazyk Java byl vybrán, protože je voln ě dostupný a disponuje množstvím t říd (Socket, URL, URI, String, ...), které umož ňují rychlou a pohodlnou implementaci sí ťových služeb. Dalším d ůvodem pro výb ěr tohoto jazyka je automatická správa pam ěti, p řenositelnost a v ětší systémová bezpe čnost. Tyto aspekty jsou dány tím, že programy v Jav ě jsou p řekládány do bajtkódu, který je p ři spušt ění interpretován Java Virtual Machine (JVM). Tento mechanismus si však vybírá svou da ň p řed v podob ě vyšší pam ěť ové a procesorové náro čnosti aplikací.
30 V následujících kapitolách je popis implementace jednotlivých rozhraní aplikace, jejich dekompozice do t říd a popis funk čnosti jednotlivých t říd a jejich vzájemné komunikace. Pro snazší pochopení částí týkajících se databázových transakcí je uvedena kapitola s popisy použitých databázových tabulek systému MySQL. Obsažena je také kapitola v ěnující se problému užití Java aplikací jako služeb NT.
Implementace NNTP rozhraní
Server je implementovaný tak, aby zcela vyhovoval RFC3977. Server umož ňuje zabezpe čený a nezabezpe čený p řístup. Dále je možné p řepínat mezi lokálním a proxy módem. Pokud NNTP server poskytuje zabezpe čené p řipojení, je možná autentizace uživatele. Administrátor m ůže také ur čit dobu vypršení spojení, maximální velikost zasílaných článk ů, název serveru, mód kompatibility se starým RFC a jeho rozší řeními, zakázání zasílání článk ů, zapnutí výpis ů log ů, zapnutí synchronizace s jinými NNTP servery (nevyžadujícími autentizaci) a nastavení intervalu této synchronizace. Vytvo řený server disponuje p říkazy spadajícími pod následující seznam schopností ( capabilities ): READER, POST, OVER, NEWNEWS, AUTHINFO USER, LIST ACTIVE, LIST ACTIVE.TIMES, LIST DISTRIB.PATS, LIST NEWSGROUPS, LIST OVERVIEW.FMT . Programový kód implementující NNTP rozhranní je rozd ělen do t říd NNTPServer, SocketHandler, NNTPprocesor, NNTPProxy, Head, Update. Následovat bude popis jednotlivých t říd, jejich funkce a zp ůsob jejich propojení a komunikace.
Popis t řídy NNTPServer
Tato t řída obsahuje metodu public static void main(String args) , kterou se spouští celý NNTP server. Metoda main() se pokusí na číst ze souboru objekt s konfigurací, tento objekt je instancí t řídy Configuration . Pokud se tento objekt nepoda ří na číst, vytvo ří se instance nového objektu s konfigurací s výchozím nastavením. Následuje inicializace statických prom ěnných se vzory regulárních výraz ů ve tříd ě NNTPprocessor voláním metody NNTPprocesor .initializeRE() a dále zavedení databázového ovlada če voláním NNTPprocesor .initializeJDBC() . Pokud se n ěkterá z těchto inicializa čních metod nepoda ří, program se ukon čí. Pokud je to konfigurací vyžadováno, dojde k vytvo ření zabezpe čeného serverového socketu, k tomu je pot řeba, aby v konfigura čním objektu byla obsažena cesta k souboru s klí čem a heslo k tomuto souboru. Pokud zabezpe čený server není požadovaný, vytvo ří se standardní serverový socket, reprezentovaný instancí t řídy Socket . Tento socket se sváže s požadovaným číslem portu (získané z konfigura čního objektu) a zahájí se na n ěm naslouchání. P říchozí požadavky jsou akceptovány a pro jejich obsluhu se vytvo ří vlákno, které je bu ď instancí t řídy SocketHandler v případ ě, že je požadována práce s lokálními složkami, nebo je instancí t řídy NNTPProxy , pokud je
31 požadováno p řeposílání požadavk ů na vzdálené diskusní servery. Konstruktoru zvoleného vlákna se předá odkaz na objekt s konfigurací a odkaz na objekt t řídy Socket s navázaným klientským spojením. V této úvodní části se též spouští vlákno, které je instancí t řídy Update a které zajiš ťuje stahování přísp ěvk ů ze vzdálených NNTP server ů v ur čitých časových intervalech.
Popis t řídy SocketHandler
Konstruktor této t řídy si uloží do lokálních prom ěnných konfigura ční informace, které vezme z konfigura čního objektu p ředaného jako parametr konstruktoru. V metod ě run() této t řídy se nejprve vytvo ří instance t řídy NNTPProcesor(), jejíž metody slouží ke zpracování p říchozích NNTP p říkaz ů. Dále se z klientského socketu vytvo ří vstupní a výstupní proudy. Vstupní i výstupní proudy jsou dva. První dvojice čte data ve znakové sad ě UTF-8 a slouží pro na čítání p říkaz ů a výpis ů t ěch odpov ědí serveru, které neobsahují data z článk ů a jejich sou částí.. Druhá dvojice čte data ve formátu ISO-8859- 1 a slouží pro na čítání a výpis t ěl a hlavi ček článk ů. Kódová sada UTF-8 m ůže reprezentovat jeden znak ur čitou sekvencí n ěkolika bajt ů, kdežto u kódování ISO-8859-1 každý bajt odpovídá jednomu znaku. Na základ ě toho, jestli je v konfiguraci povolené zasílání článk ů na diskusní server, zašle server klientovi p říslušnou uvítací zprávu. Následuje cyklus, ve kterém se nejprve testuje, jestli objekt t řídy NNTPProcesor nepožaduje ukon čení cyklu čtení a zpracování p říkaz ů z d ůvodu zaslání p říkaz QUIT . To se zjistí voláním metody int getStatus() výše uvedeného objektu. Pokud tomu tak není, zjistí se jestli navrácená hodnota neur čuje, že se místo p říkazu mají zaslat data článku, tj. že p ředchozím příkazem byl p říkaz POST . Pokud tomu tak bylo, čte se ze socketu článek až po koncovou sekvenci CRLF.CRLF . A na čtená data se p ředají instanci t řídy NNTPProcesor pomocí metody postArticle(dataBuffer) ke zpracování. V případ ě, že není požadováno na čítání článku, čte se p říkaz voláním lokální metody readCommand(commandReader) . Návratová hodnota této metody signalizuje, zda byl na čten p říkaz správn ě, nebo zda p ři čtení došlo k chyb ě, nebo jestli nebyl zadán p říliš dlouhý příkaz. V takovém p řípad ě, je klientovi zaslána zpráva 501 Command too long . V dalším kroku se klientskému socketu nastaví časova č, jehož hodnota je získána také z konfigurace. Pokud b ěhem nastaveného časového intervalu nedojde k žádné operaci se socketem, generuje se výjimka SocketTimeoutException , která vede k uzav ření socketu z důvodu vypršení času relace. Na čtený p říkaz se p ředá objektu t řídy NNTPProcesor ke zpracování prost řednictvím metody processCommand (String command ). Pomocí metody getOutput() stejného objektu se na čte odpov ěď na zadaný p říkaz (pop ř. na zaslaná data článku) a dále se pomocí metody getSetOutputType() zjistí, jaký výstupní proud má být použit (UTF-8 nebo ISO-8859-1) a vynuluje se interní ozna čení tohoto proudu pro p říští p říkaz. Do vybraného výstupního proudu se zašle odpov ěď .
32 Popis t řídy NNTPProxy
Tato t řída implementuje vlákno, které obsluhuje klientský socket v případ ě, že je požadován proxy mód. Konstruktorem se p ředají všechna pot řebná konfigura ční nastavení, kterými jsou port vzdáleného NNTP serveru, adresa tohoto serveru, cesta k souboru s klí čem a heslo k tomuto souboru v případ ě, že je požadováno zabezpe čené p řipojení na vzdálený NNTP server. Samoz řejmostí je také předání ukazatele na Socket s příchozím spojením. Problém s proxy módem v Jav ě je ten, že neexistuje zp ůsob, jak zjistit, jestli je dané spojení opravdu aktivní. Jinými slovy, nedají se detekovat situace, když druhá strana uzav ře spojení, nebo když dojde nap ř. k fyzickému p řerušení spojení). Jediným zp ůsobem jak se dá takováto situace detekovat, je zápis nebo čtení ze socketu, které v takovém p řípad ě skon čí výjimkou. Tato technika je z hlediska proxy serveru nepoužitelná, protože nechceme, aby do probíhající komunikace bylo nějakým zp ůsobem zasahováno. Ale nem ůžeme situaci takto nechat, aby zbyte čně nez ůstávaly otev řené sockety a aktivní vlákna, která obsluhují porušené spojení. Je totiž pot řeba detekovat uzav ření jednoho ze socket ů a na základ ě této události uzav řít i socket druhý. Řešení proxy módu ve zde popisovaném systému je následující. Nejprve se vytvo ří objekty reprezentující vstupní a výstupní proudy pro oba sockety. Následuje „nekone čný“ cyklus, ve kterém se postupn ě otestuje jeden a druhý socket, jestli n ěkterý z nich neobsahuje data, a pokud ano, tak se data na čtou ze vstupního proudu jednoho socketu a zapíší do výstupního proudu druhého socketu. Pokud k takovéto vým ěně dojde, vynuluje se interní číta č. V každé iteraci cyklu se vlákno na ur čitý čas uspí voláním metody sleep() a po obnovení b ěhu vlákna se zvýší hodnota interního číta če. Pokud hodnota interního číta če dosáhne p ředem definované hodnoty, cyklus se ukon čí a oba dva sockety se zav řou. Tj. k uzav ření spojení dojde po ur čité dob ě ne činnosti. Druhá možnost, kdy se cyklus ukon čí a dojde k uzav ření obou socket ů je, že b ěhem n ěkteré operace se socketem dojde k výjimce. Jinými slovy, vlákno vytvá ří ur čité sezení v proxy módu, které m ůže vypršet v případ ě delší ne činnosti, i když druhá strana tj. vzdálený NNTP server si ješt ě p řipojení ukon čit nep řeje (nap ř. doba sezení zde ješt ě nevypršela).
Popis t řídy Head
Objekt této t řídy poskytuje funkce pro zpracování hlavi čky diskusního článku a získání informací v ní obsažených. Konstruktor této třídy o čekává jediný parametr, kterým je hlavi čka diskusního článku v podob ě textového řet ězce. Metoda boolean check() slouží k otestování, zda hlavi čka spl ňuje všechny požadavky na její formát, dané v RFC3977. Metoda check využívá regulárních výraz ů sestavených přesn ě podle syntaktických pravidel uvedených v onom RFC. Hlavní metodou, která zpracování hlavi čky provede, je metoda buildOverview(int bytes, int lines) , která vytvo ří na základ ě hodnot v hlavi čce řet ězec, který je pozd ěji vrácen serverem jako odpov ěď na p říkaz OVER . Tj. vypreparuje
33 z hlavi čky hodnoty pro hlavi čkové řádky Subject , From , Date , Message-ID , References a doplní po čet bajt ů t ěla článku a po čet řádk ů t ěla článku. Tyto údaje jsou p ředány parametry p ři volání metody buildOverview . Mezi jednotlivé položky umístí znak tabelátor a výsledný řet ězec uloží do prom ěnné output . Obsah této prom ěnné je možné získat voláním getOutput(). P řed tímto voláním je však nutné zavolat metodu getErr() , kterou se zjistí, zda p ři zpracování nedošlo k nějakým chybám. Pokud v hlavi čce není obsažen hlavi čkový řádek Message-ID, je nové Message-ID vygenerováno na základ ě jména NNTP serveru (p ředáno konfigura čním objektem) a aktuálního času. Vygenerované Message- ID pro daný objekt t řídy Head lze získat voláním getMessageID() . Druhá d ůležitá metoda této t řídy je metoda LinkedList getNewsGroups(Connection conn) . Úkolem této metody je zjistit obsah hlavi čkového řádku Newsgroups , vybrat z něj názvy jednotlivých diskusních skupin a s využitím databázového p řipojení ( Connection ) zjistit pomocí SQL dotazu, zda jsou uvedené skupiny obsažené v lokální databázi. Názvy skupin, které jsou obsažené v lokální databázi jsou vloženy do seznamu ( LinkedList ), který tato metoda navrací. Než jsou však názvy skupin použity v SQL dotazu, musejí být z kódování ISO-8859-1, ve kterém jsou jako sou části hlavi čky na čteny, p řevedeny do kódování UTF-8, ve kterém jsou uloženy v databázi. K tomuto p řekódování slouží metoda private String encodeString(String str) .
Popis t řídy Update
Tato t řída implementuje vlákno zajiš ťují stahování diskusních p řísp ěvk ů ze vzdálených NNTP server ů. V databázi je uložen seznam server ů, tedy p řesn ěji pro každý vzdálený NNTP server je tam uložena jeho adresa, port, wildmat řet ězec (vymezuje názvy skupin, jichž se bude synchronizace týkat) a časové razítko (udává čas poslední aktualizace) a informace o tom zda byl použit lokální nebo GMT čas. Konstruktorem se této t říd ě p ředají konfigura ční informace, kterými jsou řet ězec pro p řipojení k NNTP databázi (p ř.: jdbc:mysql://localhost/nntp?user=user_name&password=password& useUnicode=true &characterEncoding=utf8 ) a dále časový interval po kterém se má aktualizace spoušt ět. Dále metoda provádí v cyklu následující operace. Nejprve na čte z databáze adresu a port vzdáleného NNTP serveru a pomocí objektu Socket se k němu p řipojí. Následn ě vzdálenému NNTP serveru zašle p říkaz CAPABILITIES . Pokud server odpoví na tento p říkaz kódem 500, tj. že zadaný příkaz nezná, jedná se o server implementovaný podle starší verze NNTP protokolu. Pokud server na příkaz CAPABILITIES odpoví kódem 101 a v seznamu schopností serveru je schopnost READER a NEWNEWS , m ůže za čít stahování nových p řísp ěvk ů. V případ ě, že v seznamu schopností není schopnost READER , ale MODE-READER , jedná se o mode-switching server a je pot řeba serveru zaslat p říkaz MODE READER pro p řepnutí módu a otestovat dostupnost pot řebných schopností op ětovným zasláním p říkazu CAPABILITIES . Pokud nejsou schopnosti READER a NEWNEWS dostupné, spojení s tímto serverem se ukon čí. V případ ě, že se jedná o server implementovaný podle
34 RFC977, zašle se pro jistotu p říkaz MODE READER a to, že požadované p říkazy nejsou dostupné se zjistí až když budou použity a server navrátí p říslušnou chybovou odpov ěď . Následuje zaslání p říkazu NEWGROUPS následovaného časovým razítkem p řevedeným ve tvaru YYYYMMDD HHmmss a tokenem GMT v případ ě, že se nejedná o lokální, ale GMT čas. Výsledkem tohoto dotazu je více řádková odpov ěď , která obsahuje seznam nov ě vytvo řených skupin od zadaného data. Z každého řádku se vyjme jen první parametr, kterým je název diskusní skupiny a ten se uloží do dynamického pole reprezentovaného objektem t řídy Vector . Následn ě se pomocí iterátoru objekt t řídy Vector prochází a pomocí p říkazu LIST NEWSGROUP název_skupiny se program pokouší pro každou skupinu získat její popis, který je t řetím parametrem v odpov ědi na výše uvedený p říkaz. Pokud se serveru poda ří popis skupiny získat, vytvo ří v lokální databázi pomocí příkazu jazyka SQL novou prázdnou skupinu s oním popisem. Dále klient zašle serveru p říkaz NEWNEWS wildmat YYYYMMSS HHmmss [ GMT ], tento p říkaz by m ěl vypsat Message-ID všech nových zpráv vytvo řený od zadaného data a jejichž skupina vyhovuje uvedenému wildmat řet ězci. Každý řádek této odpov ědi (tj. Message-ID) se uloží do dynamického pole reprezentovaného objektem t řídy Vector . Toto pole se iterátorem prochází a pro každé Message-ID se zašle p říkaz ARTICLE
Popis t řídy NNTPProcesor.java
Třída NNTPProcesor zajiš ťuje vlastní zpracování NNTP p říkaz ů. Krom ě prom ěnných sloužících k uložení konfigurace z konfigura čního objektu, který je p ředán jako parametr konstruktoru, obsahuje tato t řída d ůležité prom ěnné activeNewsgroup a activeArticle, pomocí kterých jsou implementovány vnit řní ukazatele na aktuáln ě nastavenou skupinu a článek. Třída obsahuje dv ě statické metody, první initializeJDBC () zajiš ťuje nahrání databázového ovlada če, druhá initializeRE () zajiš ťuje inicializaci vzor ů ( Pattern ) pro vytvá ření regulárních výraz ů. Tyto vzory jsou bezpe čné z hlediska vláken a jejich kompilaci tímto zp ůsobem sta čí provést jen jednou p řed tím, než se z dané t řídy za čnou vytvá řet její instance. Funkce processCommand(String command) zajiš ťuje vlastní zpracování NNTP p říkazu předaného jako textový řet ězec v parametru command . Funkce nejprve provede p řevod došlého příkazu na velká písmena, protože všechny regulární výrazy jsou vystav ěny nad velkými písmeny.
35 Jako první se provede porovnání došlého p říkazu s regulárním výrazem, který zkontroluje, zda p říkaz obsahuje na za čátku řet ězec n ěkterého z implementovaných výraz ů. Pokud tomu tak není, do prom ěnné output , jejíž obsah je posléze zasílán klientovi se zapíše chybové hlášení 500 Unknown command . Pokud je základní p říkaz znám, postupn ě se testuje na shodu s regulárními výrazy, které již kontrolují, jestli jsou i jeho parametry ve správném tvaru. V případ ě, že základ p říkazu byl správn ě, ale nepoda ří se nalézt shodu s podrobným regulárním výrazem pro daný p říkaz, je zapsáno hlášení 501 Syntax error .
Zpracování p říkazu AUTHINFO Nejprve se porovná došlý p říkaz na shodu s regulárním výrazem pro p říkaz AUTHINFO . Pokud dojde ke shod ě, musí se nejprve zjistit, jestli je server v zabezpe čeném stavu tj. jestli je použito šifrování na transportní vrstv ě. Není-li, je uživateli zaslána zpráva 483 Datastream is insufficiently secure a autentizace není povolena. Je-li bezpe čné spojení navázáno, nejprve se otestuje jestli už byl zaslán příkaz AUTHINFO USER s uživatelským jménem, což je ozna čeno pravdivostní prom ěnnou. V případ ě, že tomu tak není a uživatel nyní použil p říkaz AUTHINFO s parametrem PASS, je navrácena zpráva 482 Authentication commands issued out of sequence . Je-li nyní specifikováno uživatelské jméno, uloží se a pozna čí se do pravdivostní prom ěnné tato skute čnost, stejn ě tak je zaslána uživateli zpráva 381 Password required . Po zaslání obou p říkaz ů tj. po p ředání uživatelského jména i hesla, se na řet ězec s heslem zavolá metoda hashPassword(String password) , kterou se vytvo ří MD5 hash hesla. V databázi se totiž neukládá p římo heslo, ale jeho MD5 hash. Řet ězec s zahashovaným heslem a uživatelským jménem se p ředá metod ě makeAuth(String user, String hashedPassword) . Tato metoda se připojí k databázovému serveru a SQL dotazem SELECT name FROM users WHERE name=? AND pass=? zjistí, zda je daný uživatel v databázi s daným heslem asociován. Ke všem dotaz ům na databázi v tomto programu se používá objekt t řídy PreparedStatement , pomocí kterého je bezpe čné sestavovat SQL dotazy, protože sám zajistí ohlídání taktiky SQL injection, kdy se uživatel zadáním neregulárního vstupu snaží získat z databáze citlivé a nedovolené údaje. Je-li záznam v databázi nalezen, prob ěhla autentizace úsp ěšn ě a metoda makeAuth() vrací pravdivostní hodnotu true . Na základ ě té je vygenerována NNTP odpov ěď 281 Authentication accepted , vrátí-li metoda makeAuth() false , návratová zpráva bude 481 Authentication failed/rejected . Dojde-li b ěhem zpracování nap ř. b ěhem operace s databází k nějakému problému, je v tomto p řípad ě ostatn ě jako i v celém dalším kódu uživateli zobrazena chybová zpráva 403 internal program error . Po úsp ěšné autentizaci se nastaví pravdivostní prom ěnná userAuthenticated , což zamezí p ři výpisu schopností (p říkaz CAPABILITIES ) vypisovat schopnost AUTHINFO USER a také p ři dalším pokusu o p řihlášení zobrazí zprávu 502 User already authenticated .
36 Zpracování p říkaz ů ARTICLE, STAT, BODY, HEAD Další testovaným p říkazem je p říkaz ARTICLE , STAT , BODY , HEAD , který se testuje reg. výrazem, pomocí kterého se z příkazu získají dva řet ězce. Prvním je p říkazové slovo a druhým parametr, který nemusí být obsažen, nebo je jím číslo udávající článek, nebo Message-ID článku. Tyto dva řet ězce se předají funkci article() , která provede zpracování. P ředtím, než se však parametry p říkazu p ředají funkci pro zpracování (a to platí pro všechny dále zpracovávané p říkazy) zavolá se funkce authRequired() , která zjistí zda je požadována autentizace a v případ ě, že ano, vrací zprávu 480 Authentication required a zastaví zpracování aktuálního p říkazu. Metoda article() tedy nejprve zjistí, zda je požadována specifikace článku pomocí číselného parametru nebo Message-ID. V případ ě, že je založena na číselném parametru, musí být již vybrána nějaká aktivní skupina, jejíž id je v prom ěnné activeNewsgroup . V případ ě, že vybrána není, je v activeNewsgroup hodnota -1 a uživateli je zobrazeno chybové hlášení 412 no newsgroup has been selected . Není-li zadán parametr žádný, p ředpokládá se použití ukazatele na aktuální článek reprezentovaného prom ěnnou activeArticle . Pokud je tento nastaven na hodnotu -1, není zvolen žádný aktuální článek a je zasláno chybové hlášení 420 no current article has been selected . Podle základního p říkazu a metody specifikace článku se vytvo ří dotaz nad databází. P říklad tohoto dotazu pro p říkaz ARTICLE a specifikaci pomocí čísla článku je SELECT number, news.msg_id, head, body FROM news, includes WHERE news.msg_id = includes.msg_id AND includes.number=? AND includes.grp_id=? . Kombinace p říkaz ů a metod specifikace článku vede na osm r ůzných dotaz ů. V případ ě, že prob ěhlá transakce vrátí výsledek, je tento p ředán do prom ěnné output jako odpov ěď protokolu NNTP na daný p říkaz p ři zvolené metod ě ur čení článku. Pokud po provedení dotazu, kdy ur čení článku záviselo na aktuáln ě nastavené skupin ě pop ř. aktuáln ě nastaveném článku, nejsou navrácena databází o čekávaná data, je proveden test, ve kterém se zjistí, zda-li v databázi opravdu existuje aktuáln ě nastavená skupina pop ř. aktuální článek. Tyto údaje mohli být b ěhem NNTP relace smazány administrátorem, nebo n ějakým jiným zp ůsobem znep řístupn ěny a klient je o této skute čnosti informován chybových hlášení s kódem 412,420 nebo 423 no such article number in this group v případ ě, že aktuální skupina existuje, ale uživatelem zadané číslo článku je chybné.
Zpracování p říkazu LIST Dalším p říkazem, který se zpracovává, je p říkaz LIST . Pro tento p říkaz existují dv ě verze regulárních výraz ů. První testuje varianty p říkazu LIST , u kterých není povolen parametr wildmat . Jedná se tedy o příkaz LIST bez parametr ů a p říkaz LIST s parametrem DISTRIB .PATS nebo OVERVIEW .FMT . Pokud je zjišt ěna verze p říkazu LIST bez parametru, zavolá se metoda list(String wildmat) s parametrem null . Popis této metody bude uveden pozd ěji.
37 Je-li zjišt ěna varianta OVERVIEW .FMT , vypíše se jako odpov ěď obsah řet ězce, který obsahuje uspo řádání položek v OVERVIEW databázi. U varianty DISTRIB .PATS dojde k zavolání funkce listDistribPats() . Tato metoda pouze získá z databáze celý obsah tabulky distripats , mezi jednotlivé položky každého řádku získaného z databáze vloží dvojte čky a tyto řádky vrací jako více řádkovou odpov ěď NNTP serveru na výše uvedený p říkaz. U variant p říkazu LIST , které mohou být následovány nepovinným parametrem wildmat se postupuje takto. Zjistí-li se varianta p říkazu ACTIVE .TIMES volá se metoda listActiveTimes() , jejímž parametrem je zadaný wildmat řet ězec. Uvnit ř této metody se nejprve zavolá metoda wildmatProcessing(wildmat) , která na základ ě zadaného wildmatu vrátí část databázového dotazu, která se p řidá za klauzuli WHERE SQL p říkazu pro zjišt ění požadovaných informací a ovlivní tím rozsah p říkazu pouze na skupiny, které vyty čuje wildmat řet ězec. Metoda activeTimes() pomocí takto připraveného SQL p říkazu zjistí název, čas a adresu uživatele zodpov ědného za vytvo ření dané skupiny. Časové razítko p řevede na sekundy a tyto hodnoty naformátuje tak, aby odpovídali standardu NNTP. Použití klí čového slova ACTIVE má za následek vyvolání metody list(wildmat) . Tato metoda provede stejné zpracování parametru jak je uvedeno výše, vygenerovanou část dotazu p řidá za klauzuli WHERE p říkazu pro zjišt ění jména skupiny, maximálního a minimálního čísla článku v dané skupin ě a zjišt ění, zda je do skupiny umožn ěno zasílání. Tento p říkaz je celkem komplikovaný, skládá se ze dvou poddotaz ů a musí být ošet řeno, že minimální a maximální číslo článku u prázdné skupiny nesmí být null, ale číslice nula. Zjišt ěné řádky s odpov ěď mi jsou naformátovány tak, aby konformovali s NNTP protokolem. U varianty p říkazu LIST s klí čovým slovem NEWSGROUPS probíhá zpracování podobn ě jako u předchozích variant, je však provád ěno metodou listNewsgroups() a informace, která se zjiš ťuje, je název a popis diskusní skupiny. Základem všech t ří výše uvedených metod je, jak již bylo napsáno, metoda wildmatProcessing (String wildmat ). Tato metoda v cyklu zpracovává každý wildmat_pattern , ze kterého se skládá p ředaný wildmat řet ězec. Využije se funkce LIKE jazyka MySQL, která má sv ůj formát parametru wildmat , kdy místo znaku * slouží k ozna čení sekvence znak ů znak % (procento) a k ozna čení práv ě jednoho znaku, znak _ (podtržítko). Proto je pot řeba v zadaném wildmat _pattern tyto znaky neutralizovat tím, že se p řed n ě vloží znak \ (zp ětné lomítko) a následn ě znak * nahradit znakem % a znak ? znakem _. V případ ě, že wildmat _pattern za číná znakem ! (vyk řičník) tj. je požadována negace vyhledávání, použije se MySQL funkce UNLIKE . P ři zpracování se musí postupovat odzadu a musí se zajistit spojení negace porovnání s předchozími porovnáními logickou spojkou AND, kladné porovnání s p ředchozími porovnáními spojkou OR a pomocí závorek zajistit zpracování tak, aby vyhovovalo RFC 3977. P říklad p řevodu dvou wildmat řet ězc ů na MySQL podmínku jsou: a*,!*c,d* -> (E like d%) OR ( E NOT LIKE %c AND ( E LIKE a%)) a*,c?d,d* -> (E like d%) OR ( E LIKE c_d OR (E LIKE a%))
38 Zpracování p říkazu GROUP Dalším zpracovávaným p říkazem je p říkaz GROUP . Tento p říkaz má jediný parametr, kterým je jméno skupiny. To se p ředá metod ě group(String groupName) . Tato metoda se podobným SQL příkazem, který byl použit v metod ě list() pokusí zjistit maximální a minimální číslo článku ve specifikované skupin ě a id této skupiny. Pokud je provedení p říkazu úsp ěšné, vloží se získané id do prom ěnné activeNewsgroup a do activeArticle se vloží číslo prvního článku (tj. minimální číslo článku) ve skupin ě. Uživateli je v tomto p řípad ě zobrazena zpráva s kódem 211. P ři nenalezení zadané skupiny v databázi je navrácena zpráva 411 no such newsgroup .
Zpracování p říkazu LISTGROUP Následuje test na p říkaz LISTGROUP . Tento p říkaz m ůže být následován nepovinným názvem skupiny a nepovinným parametrem range . Pro zpracování parametru range je použit následující reg. výraz: ((\\d{1,16})(-|-(\\d{1,16}))?)?)?, pomocí n ěj se zjistí o jakou variantu parametru range se jedná (existují 3 r ůzné varianty). Metod ě listGroup() se p ředá jméno diskusní skupiny a informace týkající se parametru range . V případ ě, že této metod ě nebyl p ředán název skupiny, zjistí zda je nastavena aktuální skupina a pokud tomu tak není, nebo pokud nastavená aktivní skupina v databázi reáln ě neexistuje, je navrácena zpráva 411 no such newsgroup . V opa čném p řípad ě, nebo při specifikaci skupiny parametrem, se složí MySQL dotaz, jehož úkolem je získat nejprve max. a min. číslo článku. A další SQL dotaz, jehož úkolem je získat čísla článk ů, ležící mezi hodnotami specifikovanými parametrem range . V jedné transakci jsou oba tyto p říkazy provedeny a výsledek zobrazen v souladu s NNTP protokolem. V případ ě, že byla pomocí parametru specifikována diskusní skupina a databázová operace byla úsp ěšná, dojde k přenastavení ukazatel ů na aktuální článek a aktuální skupinu.
Zpracování p říkazu NEWGROUPS Příkaz NEWGROUPS má dva povinné parametry, kterými jsou čas a datum a jeden nepovinný parametr, který udává, zda se jedná o GMT údaje. Všechny tyto údaje jsou zpracovány prost řednictvím metody newgroups(Matcher mStat) . Nejprve se zjistí, který ze dvou možných formát ů data byl použit, všechny číselné údaje se složí do jednoho řet ězce, který se doplní řet ězcem udávajícím zónu, která m ůže být bu ď GMT-00:00 nebo výchozí časová zóna systému, na kterém je server spušt ěn. Výsledný řet ězec je tedy ve tvaru yyyyMMddHHmmssz nebo yyyyMMddHHmmssz . Tento řet ězec se převede na časové razítko, které je následn ě využito v rámci SQL dotazu k nalezení t ěch záznam ů v tabulce newsgroups, jejichž časové razítko je nov ějšího data, než to získané z příkazu. V rámci uvedeného p říkazu se musejí též získat minimální a maximální číslo článk ů z nalezené skupiny. Získané údaje se použijí k sestavení NNTP odpov ědi, která je svým formátem stejná jako u p říkazu LIST nebo LIST ACTIVE .
39 Zpracování p říkazu NEWNEWS Následuje zpracování p říkazu NEWNEWS . Tento p říkaz má navíc oproti p říkazu NEWGROUPS parametr wildmat udávající, které skupiny mají být prohledávány na p řítomnost nového článku. Zpracování p říkazu je v režii metody newnews(Matcher mStat) , která zpracuje zadané údaje naprosto stejným zp ůsobem jako metoda NEWGROUPS, tj. p řevede je na časové razítko. Dále zavolá metodu wildmatProcessing() na zadaný wildmat řet ězec, která je popsána u p říkazu LIST . Následuje složení SQL p říkazu, který získá Message-ID zpráv, jež byly vytvořeny d říve, než udává získané časové razítko. K tomuto p říkazu se p řipojí omezující SQL kód, získaný prost řednictvím p říkazu wildmatProcessing() . Po provedení takto zkomponovaného p říkazu se vypíší získaná Message-ID v souladu s NNTP standardem.
Zpracování p říkazu OVER Příkaz OVER je zde uvedenou implementací podporován pouze v doporu čené variant ě s parametrem range . P ři použití p říkazu OVER s parametrem Message-ID je vypsáno hlášení 503 this over variant not implemented . V konfiguraci je možné zvolit, aby místo klí čového slova OVER fungovalo slovo XOVER , které je využíváno nyn ějšími implementacemi NNTP klient ů a pat ří mezi jedno z rozší ření původního protokolu RFC 977. Zpracování parametru range je provedeno stejným zp ůsobem jako u příkazu LISTGROUP . Informace o parametru range jsou p ředány metod ě over( long param1, long param2) , která nejprve zjistí, jestli existuje n ějaká aktuální skupina podle obsahu prom ěnné actualNewsgroup , pokud tomu tak není, vypíše "412 no newsgroup current selected ", pokud není zadán žádný parametr a je p ředpokládána volba článku daného ukazatelem aktuálního článku, je tento ukazatel otestován a v případ ě, že aktuální článek není nastaven je navrácena odpov ěď 420 No article selected . Následuje složení SQL p říkazu, jehož úkolem je získání čísla článku a řet ězce s položkou overview z databáze. Rozsah čísel článk ů, o nichž budou tyto údaje z databáze získány je omezený hodnotami parametru range . Po úsp ěšném provedení databázové operace je pro každý získaný řádek spojeno číslo článku s řet ězcem z položky overview pomocí znaku tabelátor a takto vzniklý řet ězec je navrácen jako NNTP odpov ěď . Pokud nebyla SQL p říkazem získána, žádná data, testuje se, jestli náhodou nebyla b ěhem NNTP relace smazána aktuální diskusní skupina, nebo aktuální článek. V takovém p řípad ě je zobrazeno p říslušné chybové hlášení, jinak je vypsáno chybové hlášení 423 Empty range , udávající, že byl zadán invalidní rozsah.
Zpracování p říkazu POST Při zjišt ění, že je zadán p říkaz POST, se na základ ě toho, zda je na server povoleno zasílání nebo ne, vygeneruje bu ď zpráva 340 Input article - end with
40 příkazu. T ělo článku je nad řazeným objektem p ředáno metod ě postArticle(String article) , kdy parametrem je textový řet ězec s daty článku, jehož uložení do databáze je požadováno. Metoda postArticle() nejprve zjistí, jestli t ělo článku neobsahuje n ěkteré nepovolené znaky. Pokud tomu tak je, je navrácena chybová zpráva 441 Posting failed - invalid article format . Dále se nalezne v textu článku první prázdný řádek, který odd ěluje hlavi čku od t ěla, a článek se rozd ělí práv ě na tyto dv ě části. Následuje vytvo ření instance objektu Head pro hlavi čku práv ě zpracovávaného článku. V další části se spo čítá po čet řádk ů t ěla článku (po čet výskyt ů pár ů CRLF ) a po čet bajt ů článku (ten je rovný po čtu znak ů). Tyto údaje se p ředají metod ě buildOverview() náležející k d říve vytvo řené instanci t řídy Head . Taktéž se zavolá metoda getNewsGroups(conn) , která pro danou hlavi čku navrátí seznam s názvy skupin, které jsou spravovány lokální databází. Pokud n ěkterá z těchto metod skon čí neúsp ěšn ě, je op ět navrácen chybový kód 411. V opa čném p řípad ě se p říkazem getOverview () získá overview položka pro daný článek, p říkazem getMessageID() Mesage-ID daného článku a pomocí getHead() zpracovaná pop ř. upravená hlavi čka článku. Tyto informace a řet ězec s tělem článku se použijí pro zkomponování SQL p říkazu, který tyto údaje vloží do tabulky news . V databázi se pomocí SQL p říkazu LOCK TABLE uzamknou tabulky newsgroups , news a includes pro zápis. Vloží se článek se všemi údaji do tabulky news . Následn ě se pro každou skupinu ze seznamu získaném p říkazem getNewsGroups() zvedne číta č maximálního čísla článku skupiny v tabulce newsgroups , a do tabulky includes se vloží Message-ID článku, id skupiny a číslo článku, které je v daný okamžik práv ě oním maximálním číslem článku pro danou skupinu. Po zpracování všech skupin, do kterých m ěl být článek zaslán se vypíše 240 article posted ok . V případ ě, že se do databáze nepoda řilo článek vložit, je bu ď zobrazena zpráva 441 posting failed - posted Message-ID still exists , pokud je to z důvodu toho, že článek s daným Message-ID již existuje, nebo zpráva 403 program error, function not performed , pokud je to z důvodu jiného.
Zpracování ostatních p říkaz ů Příkaz CAPABILITIES pouze vypíše schopnosti serveru. V případ ě, že je server v bezpe čném módu a je vyžadována autentizace je tento seznam schopností dopln ěn o položku AUTHINFO USER . Tato položka je ze seznamu schopností odebrána po úsp ěšném p řihlášení.uživatele. Příkaz HELP pouze zobrazí textový popis všech možných p říkaz ů NNTP serveru. Příkaz DATE zobrazí aktuální GMT čas ve formátu p ředepsaném NNTP standardem. Příkaz QUIT vloží do prom ěnné output řet ězec: 205 Connection closing a nastaví pomocnou prom ěnnou status na -1, čímž zajistí ukon čení hlavního cyklu zpracování p říkaz ů v instanci t řídy SocketHandler a následné ukon čení spojení s klientem. Při zpracování p říkazu LAST a NEXT je volána metoda lastNext() s parametrem udávajícím, ze kterého p říkazu je volána. Tato metoda nejprve ov ěř í existenci aktuální skupiny a aktuálního článku, pop ř. vypíše chybová hlášení. Je-li vše v po řádku, pokra čuje metoda aplikací SQL p říkazu, kterým se u p říkazu NEXT zjistí číslo následujícího článku a u p říkazu LAST číslo p ředchozího článku. Pro
41 zjišt ěné číslo článku se dalším SQL dotazem pokusí z databáze získat Message-ID daného článku. Pokud se mu to povede, nastaví zjišt ěné číslo článku do prom ěnné actualArticle udávající aktuální článek a navrátí odpovídající NNTP odpov ěď s kódem 223.
Implementace HTTP rozhranní
Vytvo řený webový server poskytuje zabezpe čený (HTTPS) nebo nezabezpe čený (HTTP) p řístup. Dále je podporován výb ěr diskusních skupin k prohlížení, prohlížení seznamu článk ů v dané skupin ě a prohlížení jednotlivých článk ů. Do skupiny lze prost řednictvím tohoto rozhraní zaslat nový p řísp ěvek, nebo reagovat na p řísp ěvek existující. Spojení rozhraní s NNTP serverem m ůže být taktéž zabezpe čené nebo nezabezpe čené. P řes webové rozhraní m ůže být provedena i autentizace uživatele vůč i NNTP serveru, pokud si autentizaci NNTP server vyžádá. Kód implementující HTTP rozhranní je rozd ělen do t říd HTTPServer, NNTPClient, SocketHandler, Mime, Article, ArticleBuild, RequestProcessor, Overview. Následovat bude popis jednotlivých t říd, jejich funkce a zp ůsob jejich propojení a komunikace.
Popis t řídy HTTPServer
Tato t řída obsahuje metodu public static void main(String[] args)). Tedy tato t řída bude použita pro spušt ění celého programu. Úkolem této t řídy je nejprve ze souboru na číst objekt, který je instancí t řídy Config . N ěkteré informace z tohoto objektu budou následn ě využity i ostatními spolupracujícími objekty. Dále t řída vytvo ří serverový socket (reprezentovaný objektem Socket ) naslouchající na portu, jehož číslo je získáno metodou getHttpPort() z konfigura čního objektu . V případ ě, že je vyžadován zabezpe čený HTTP p řístup tj. protokol HTTPS, vytvo ří se zabezpe čený serverový socket pomocí mechanismu SSLv3. Pro vytvo ření takovéhoto zabezpe čeného socketu je pot řeba programu navíc předat název souboru s klí čem ( KeyStoreFile ) a heslo k tomuto souboru ( KeyStorePassword ). V případ ě, že je se serverovým socketem navázáno spojení, spustí se vlákno, které bude toto spojení obsluhovat. Vlákno je instancí t řídy SocketHandler .
Popis t řídy SocketHandler
Pomocí konstruktoru této t řídy se nové instanci obslužného vlákna p ředá objekt reprezentující socket s klientským p řipojením a dále informace s konfigurací. Metoda run() této t řídy má nejprve za úkol vytvo řit instanci t řídy RequestProcessor , která slouží k syntaktické a sémantické analýze HTTP požadavk ů, a následn ě čte ze socketového vstupu jednotlivé řádky HTTP požadavku. Konec vstupu (požadavku) je signalizován na čtením prázdného řádku. Na čtený požadavek se p ředá metod ě processHeader() objektu t řídy RequestProcessor . Tato metoda vrací hodnotu typu int, udávající, jak
42 analýza požadavku dopadla. V případ ě, že je navrácena hodnota -1, šlo v požadavku o metodu POST a je pot řeba na číst ješt ě t ělo požadavku. V případ ě, že je navrácena hodnota 0, prob ěhla analýza požadavku v po řádku, je-li navráceno číslo vyšší jako 0, jedná se o kód chyby protokolu HTTP. Po analýze požadavku, je možné jednotlivé atributy tohoto požadavku (verzi HTTP protokolu, použitou metodu, žádaný URI, délka t ěla u metody POST, …) získat pomocí p říslušných metod s prefixem get (nap ř. getMethod() ). V případ ě, že byl navrácen chybový kód, je p ředán metod ě sendErrorReply() , která vytvo ří hlavi čku pro HTTP odpov ěď s požadovaným chybovým kódem a jako t ělo této odpov ědi na čte soubor s odpovídajícím HTML kódem. V případ ě, že nedošlo k žádné chyb ě, jsou atributy požadavku předány metod ě sendOKReply() . Tato metoda nejprve dekóduje z předaného URL cestu (nap ř. /groups.html ) a vlastní dotaz (nap ř. group=pokus.net ). Požadavek na soubory s obrázky, nebo se souborem kaskádového stylu, je obsloužen prostým načtením daného souboru z disku a odesláním v podob ě HTTP odpov ědi. P ři odesílání HTTP odpov ědi se volá metoda composeHttpHeader() , které se p ředá délka t ěla, jenž bude p řipojeno k odpov ědi. Tato metoda vygeneruje kompletní HTTP hlavi čku tak, aby byla v souladu s protokolem HTTP/1.1. Dále jsou obslouženy požadavky na následující umístění: / ( root ), v tomto p řípad ě se z disku na čte soubor groups.html . Tento soubor bude sloužit k zadání wildmat řet ězce, pro výb ěr skupin k zobrazení. Po na čtení souboru se v n ěm pomocí regulárního výrazu nahradí řet ězec za * (Což je výchozí wildmat řet ězec, jehož použití zp ůsobí výpis všech skupin na serveru) a řet ězec za název znakové sady získaný z konfigura čního souboru. Znaková sada je obdobným zp ůsobem nastavována pro všechny generované HTML stránky. Na zobrazené stránce se uživateli tedy zobrazí vstupní pole pro omezení výpisu seznamu diskusních skupin a tla čítko Send . Kliknutí na tla čítko Send má za následek zaslání požadavku (metoda GET) na /groups.html?filter=* . Pokud funkce sendOKReply detekuje tento požadavek, vytvo ří instanci objektu NNTPClient() a p ředá mu údaje nutné pro zabezpe čené nebo nezabezpe čené p řipojení ke vzdálenému NNTP serveru. Bohužel Java neumož ňuje žádným zp ůsobem zjistit, zda-li je navázané p řipojení stále aktivní, proto je nutné p řed každým zasláním smysluplného p říkazu NNTP serveru zaslat takzvaný HEARTBEAT příkaz, kterým se zjistí, zda je p řipojení aktivní. V případ ě, že je, server odpoví, že daný p říkaz nezná. V případ ě, že p řipojení aktivní není, je nutné prost řednictví metody quit() objektu nntpClient spojení ukon čit a vytvo řit novou instanci tohoto objektu. Tato technika je zde z toho d ůvodu, že protokol HTTP1.1 udržuje perzistentní spojení, b ěhem kterého m ůže relace s NNTP serverem vypršet, takhle je relace znovu navázána a uživatel sedící u webového prohlíže če nic nezpozoruje. V případ ě, že p řijde požadavek na seznam skupin, je p ředán metod ě listActive(String pattern ) objektu nntpClient , která zašle na NNTP server p říkaz LIST ACTIVE pattern a výsledek tohoto p říkazu zformátuje jako HTML kód, kdy každý název skupiny je na samostatném řádku a tvo ří odkaz na umíst ění /group.html?group=nazev_skupiny . Status odpov ědi NNTP serveru je návratovou hodnotou funkce listActive a v případ ě, že signalizuje úsp ěšné provedení, m ůže být výše uvedený HTML kód z NNTP
43 klienta vyzvednut prost řednictvím metody getOutput() . Následn ě je z disku na čtena op ět stránka groups.html , do které je na místo řet ězce vložen výše uvedený html kód. A na místo řet ězce je vložena hodnota pattern použitá v tomto požadavku. V případ ě, že NNTP server navrátil n ějakou chybu, je tato získána voláním metody getOutput() a vložena do stránky na místo seznamu skupin. V případ ě, že metoda listActive vrátí hodnotu 480, signalizující, že server vyžaduje autentizaci, zkusí se nejprve vyzvednou z doru čeného požadavku autentiza ční údaje. Tyto údaje jsou obsaženy v hlavi čkovém řádku Authorization , který má tvar Authorization: Basic username:password , řet ězec username:password je zakódovaný pomocí Base64. Pokud jsou tyto údaje v požadavku obsaženy, provede se prost řednictvím NNTP klienta jednoduchá autentizace zasláním p říkaz ů AUTHINFO USER username a AUTHINFO PASS password . V případ ě, že je autentizace úsp ěšná, volá se metoda listActive() znovu. Pokud nejsou autentiza ční údaje v požadavku obsaženy, navrácena je HHTP odpov ěď s kódem 401 Unauthorized a hlavi čkou WWW-Authenticate: Basic realm=“ProNNTP“ . Uživateli webový klient zobrazí dialog s přihlašovacím formulá řem, kde musí zadat autentiza ční údaje a webový klient zopakuje požadavek. Tento postup zpracování je opakován u všech následujících požadavk ů. Požadavek na získání p řehledu článk ů volá metodu nntpClient.getOverview(String group) , která vytvo ří HTML kód se seznamem článk ů v dané diskusní skupin ě se řazeným podle odpov ědní hierarchie, kdy u každé zprávy je její p ředm ět odkazem na aritcles.html?group=nazev_skupiny&article=cislo_clanku. Seznamem článk ů se nahradí výraz ve stránce articles.html . Tato stránka se odešle klientovi. Kliknutím na odkaz v předm ětu článku se vyšle výše uvedený požadavek. Takovýto požadavek má za následek vyvolání metody nntpClient.getArticle(group,artNumber). Tato metoda na čte z NNTP serveru článek a vytvo ří instanci t řídy ARTICLE , která navíc krom ě vlastního textu článku obsahuje i odkazy na p ředchozí a následující článek v diskusní skupin ě. Tyto odkazy pozd ěji slouží pro implementaci naviga čních tla čítek prev a next v lišt ě HTML stránky, kdy se v na čtené stránce article.html nahradí výrazy a práv ě t ěmito odkazy. Dále se nahradí výraz adresou odesílatele, výraz p ředm ětem článku, výraz datem vytvo ření článku a výraz vlastním t ělem článku. V okamžiku p řipojení k NNTP serveru je zjišt ěno, zda tento server umož ňuje zasílání nových článk ů. V případ ě, že tomu tak je, je v naviga ční lišt ě na stránce pro prohlížení skupiny zobrazeno tla čítko New Article , nebo na stránce pro prohlížení článk ů zobrazeno tla čítko Reply . Kliknutí na jedno z výše uvedených tla čítek má za následek vygenerování požadavku na send.html?group=nazev_skupiny&article=cislo_clanku , který vede k zobrazení formulá ře pro zaslání nového článku do diskusní skupiny. V případ ě, že cislo_clanku je 0, neodpovídá se na žádný p ředešlý článek a je zobrazen pouze prázdný formulá ř, v případ ě, že je číslo článku jina čí než nula, odpovídá se na n ějaký konkrétní článek a je volána metoda getRefAndSubject() , kterou se získá p ředm ět onoho článku p ředcházený prefixem Re: a dále reference (tj. posloupnost Message-ID, tak jak bylo na článek
44 odpovídáno). Tyto údaje jsou dále vloženy do skrytých ( HIDDEN ) polí formulá ře pro odeslání článku ve stránce send.html a jsou zaslány i s textem tohoto článku p ři kliknutí na tla čítko Send() . D ůležité je ješt ě zd ůraznit, že jakýkoliv text získaný z NNTP serveru, je nutné p řed vložením do HTML stránky převést na HTML kód, tj. nahradit zna čky < > ‘’ \ HTML kódem, p řevést konec řádku na tag a každé dv ě mezery nahradit sekvencí mezera ; Tla čítko Sendt na formulá ři s novým článkem jako jediné generuje metodu POST , URL této metody je stránka send.html a t ělo požadavku tvo ří sekvence from=[text] &subject=[text] &body=[text] &references=[text]& newsgroup=[text]. Tento řet ězec se předá konstruktoru t řídy ArticleBuild , který zadaná data zkontroluje a vytvo ří z něj článek, který je ve formátu vhodném k zaslání NNTP serveru. Tento článek lze získat z objektu t řídy ArticleBuild metodou getArticle() jako textový řet ězec v případ ě, že metoda getErrorStatus() stejného objektu nenavrátí žádnou chybu. Nejprve je zavolána metoda nntpClient.post() , která zažádá o zaslání článku, a v případ ě, že je žádost úsp ěšn ě vy řízena je metodou nnptClient.post2(String clanek) odeslán článek na diskusní server. Dále je na čtena stránka sent.html , do které je na místo řet ězce vložena odpov ěď NNTP serveru na zaslání, pop řípad ě, vložena chybová zpráva, kterou vygeneroval objekt třídy ArticleBuild . Tato stránka je zaslána uživateli. Spojení s webovým klientem je ukon čeno v případ ě, že jde o verzi protokolu HTTP 1.0 nebo je to požadováno hlavi čkou Connection: close v požadavku protokolu HTTP 1.1.
Popis t řídy NNTPClient.java
Jak již bylo uvedeno výše tato t řída p ředstavuje implementaci nntpClienta , který zasílá dotazy serveru a na základ ě získaných odpov ědí generuje HTML kód, který ukládá do prom ěnné private String output , která m ůže být získána metodou getOutput() této t řídy. V případ ě, že došlo k chyb ě, je chybová zpráva vložena do prom ěnné output namísto HTML výstupu. Číselný status odpov ědi z NNTP serveru je p římo navracen jednotlivými metodami t řídy NNTPClient . Na základ ě tohoto čísla lze rozlišit, zda došlo k chyb ě a v prom ěnné output je chybová zpráva nebo požadovaný HTML kód. Typické zpracování více řádkové odpov ědi na NNTP p říkaz probíhá následujícím zp ůsobem. Ze socketu se na čte první řádek odpov ědi, podle kterého se ur čí, zda došlo nebo nedošlo k chyb ě a zda budou následovat další řádky odpov ědi. V případ ě, že budou následovat, čtou se řádky do té doby, než je na čten prázdný řádek s te čkou (konec více řádkové odpov ědi). Každý řádek se požadovaným zp ůsobem zpracuje a výsledek se transformuje na HTML kód, který je uložen do již zmi ňované prom ěnné output . V případ ě volání metody getOverview(název skupiny) je využita instance t řídy Overview , do které se pro každý článek uloží informace o n ěm získané p říkazem OVER nebo XOVER z NNTP serveru. Jedná se o hodnoty hlavi ček From, Subject, Date, Newsgroups, References a Message-ID . Třída Overview navíc obsahuje metody, jež usnadní seskládání a odsazení řádk ů s popisem jednotlivých článk ů za sebe tak, aby odpovídaly odpov ědní hierarchii mezi články, kdy se využívá
45 především obsahu řádk ů Message-ID a References u jednotlivých článk ů. Hlavi čkový řádek References obsahuje posloupnost Popis t řídy ArticleBuild Jak již bylo popsáno výše, tato t řída slouží k převodu článku a p říslušných atribut ů tohoto článku z formátu daného t ělem metody POST na článek vyhovující standardu RFC 3977. Úkolem této t řídy je především otestovat správnost jednotlivých d ůležitých hlavi čkových řádk ů jako je From , Subject , References , Newsgroups a doplnit řádek Date s aktuálním datem ve správném formátu. U řádk ů From a Subject je pot řeba p řekódovat jejich části obsahující ne ASCII znaky do kódování a formátu předepisovaného standardem RFC 2047 [8]. K tomuto ú čelu slouží metoda encodeHeaderLine(String line) . P ři zpracování t ěla je pot řeba zdvojit znaky te čka „.“ umíst ěné na za čátcích řádk ů tak, aby nekolidovali s koncem článku. Popis t řídy Article Úkolem této t řídy je z hlavi čky a článku získaného dotazem ARTICLE z NNTP serveru vypreparovat prost řednictvím regulárních výraz ů hodnoty pro jednotlivé hlavi čkové řádky a zp řístupnit je prost řednictvím dotazovacích metod (nap ř. getSubject() pro získání hodnoty p ředm ětu článku). Dále 46 tento objekt ruší zdvojení znaku te čka „.“ na za čátcích řádk ů. Pro získání záhlaví Subject a From v čitelném stavu je pot řeba použít metod t řídy Mime. Popis t řídy Mime Tato t řída poskytuje ve řejnou metodu String decodeHeaderLine(String line) . Pomocí, které se dekódují hodnoty hlavi ček Subject a From , které jsou ve tvaru definovaném standardem RFC2047 [8] a mají následující tvar: ASCIITEXT=?KODOVANI?ZNAKOVA_SADA?ZAKODOVANY_TEXT?=ASCIITEXT . Kde ASCIITEXT je text složený pouze z ASCII znak ů, KODOVANI je dáno budˇpísmenem Q nebo B, kdy Q zna čí kódování podobné kódování Quoted printable a B zna čí kódování Base64, ZNAKOVA_SADA je řet ězec ur čující znakovou sadu a ZAKODOVANY_TEXT je text zakódovaný uvedeným kódováním. Třída tedy navíc obsahuje ve řejnou metodu base64Decode() a quotedDecode() pro dekódování řet ězc ů z výše uvedených kód ů. Metoda base64Decode() je navíc použita i p ři dekódování řádku Authorization u HTTP požadavk ů s autentiza čními údaji. Popis t řídy RequestProcessor Tato t řída p řevezme HTTP požadavek a provede jeho syntaktickou analýzu s tím, že vypreparuje pot řebné atributy, kterými jsou URI požadavku, verze HTTP protokolu, zda je obsažena hlavi čka Host a Date (u HTTP 1.1 musí být obsaženy), jaká je hodnota hlavi čky Connection (pokud je close , je vyžadováno uzav ření spojení) a dále je zjišt ěn obsah hlavi čky Authorization , která obsahuje autentiza ční údaje. Dalším takovým údajem je délka t ěla u metody POST. Všechno toto zpracování je provedeno v rámci metody processHeader(), která vrací hodnotu int udávající, jak zpracování prob ěhlo. V případ ě, že byla navrácena hodnota 0 (zpracování úsp ěšné) nebo -1 (zpracování úsp ěšné, ale nutno na číst t ělo metody POST), mohou být hodnoty jednotlivých atribut ů získány prost řednictvím funkcí s prefixem get , nap ř. getMethod (), getHttpVer (), getPostBodyLength (),... Implementace konfigura čního rozhraní Jako konfigura ční rozhraní slouží dv ě samostatné aplikace v Jav ě s grafickým uživatelským rozhranním. Jedna je ur čena pro konfiguraci NNTP rozhraní a druhá pro konfiguraci HTTP rozhraní. Tyto aplikace umož ňují nastavit jednotlivé volby pro b ěh NNTP a HTTP rozhraní. Konfigurátor NNTP serveru dále nabízí grafické prost ředí pro práci s databází, kde je možné vytvá řet, modifikovat a mazat diskusní skupiny, uživatelské ú čty, distribu ční vzory a ú čty vzdálených NNTP server ů pro synchronizaci. Samoz řejmostí je možnost vymazávat z diskusních skupin necht ěné 47 přísp ěvky. Podrobný popis použití uvedených konfigura čních nástroj ů je v příloze této práce. Ob ě aplikace pracují na stejném principu. Základem je objekt t řídy Configuration , jež obsahuje všechny pot řebné konfigura ční údaje pro dané rozhraní. Tento objekt disponuje metodami s prefixem get , kterými lze z objektu získat hodnotu pro požadovanou položku, nap ř. getProxyMode() , pro získání informace o tom, zda má být použit proxy nebo lokální mód. Dále jsou obsaženy metody s prefixem set, kterými lze do objektu vložit hodnotu ur čitého konfigura čního údaje nap ř. setDbPassword() pro vložení hesla k databázi. Konfigura ční aplikace pracuje následovn ě. P ři kliknutí na tla čítko Save setting se zjistí, zda jsou konfigura ční údaje zadané prost řednictvím prvk ů grafického rozhranní vyhovující (nap ř. jestli hodnota pro číslo portu je opravdu číselná). V případ ě, že tomu tak je, vloží tyto konfigura ční údaje do objektu třídy Configuration . Dále vytvo ří objekt reprezentující speciální vstupn ě/výstupní proud pro serializaci objekt ů a uloží celý objekt do souboru. V případ ě, že je požadováno restartování služby NNTP nebo HTTP rozhraní tla čítkem Restart Service , program pomocí p říkaz ů NET START a NET STOP zajistí restart uvedených služeb. A programy reprezentující webové a NNTP rozhraní si p ři novém startu na čtou konfigura ční objekt ze souboru a nastaví podle n ěj své parametry b ěhu. Grafická část konfigurátoru je vystav ěna nad knihovnou Swing. Popis tabulek databáze MySQL Tabulka distribpats Tabulka slouží k uložení řádk ů s údaji pro p říkaz LIST DISTRIB.PATS. Položka Typ dat Parametry Integritní omezení Popis sloupce Weight int(11) NOT NULL Váha tohoto záznamu Pattern varchar(128) NOT NULL UNIQUE KEY Wildmat řet ězec Value varchar(256) NOT NULL Názvy diskusních skupin Tabulka includes Tabulka slouží jako spojovací tabulka mezi diskusní skupinou a do ní náležejícím článkem. Položka Typ dat Parametry Integritní omezení Popis sloupce NOT NULL FOREIGN KEY REFERENCES msg_id varchar(256) Message-ID článku character set latin1 `news` (`msg_id`) unsigned, NOT číslo článku v dané diskuzní Numer int(16) NULL skupin ě unsigned, NOT FOREIGN KEY REFERENCES Identifikátor diskusní grp_id int(6) NULL `newsgroups` (`id`) skupiny Tabulka news 48 Tabulka slouží k uložení jednotlivých diskusních p řísp ěvk ů. Položka Typ dat Parametry Integritní omezení Popis sloupce NOT NULL msg_id varchar(256) PRIMARY KEY Message-ID článku character set latin1 Uložení overview řet ězce overview text popisujícího článek head text Uložení textu hlavi čky článku body text Uložení textu t ěla zprávy NOT NULL, default Časové razítko udávající čas time timestamp CURRENT_TIMESTAMP vytvo ření zprávy Tabulka newsgroups Tabulka slouží k uložení jednotlivých diskusních skupin. Položka Typ dat Parametry Integritní omezení Popis sloupce NOT NULL, id int(6) PRIMARY KEY Identifikátor skupiny unsigned, auto_increment name varchar(128) NOT NULL Jméno diskusní skupiny description varchar(128) NOT NULlL Popis diskusní skupiny default time timestamp Čas vytvo ření diskusní skupiny CURRENT_TIMESTAMP Udává zda, je do skupiny dovoleno p tinyint(1) NOT NULL, default 1 zasílat user varchar(128) default NULL Emailová adresa správce skupiny last int(16) NOT NULL default 0 číslo posledního článku ve skupin ě Tabulka users Tabulka slouží k uložení uživatelských ú čtů. Položka Typ dat Parametry Integritní omezení Popis sloupce name varchar(128) NOT NULL PRIMARY KEY přihlašovací jméno pass varchar(32) NOT NULL hash hesla Tabulka remote Tabulka slouží k uložení informací pot řebných pro synchronizaci se vzdálenými NNTP servery. Položka Typ dat Parametry Integritní omezení Popis sloupce Id int(6) auto_increment UNIQUE KEY Id záznamu address varchar(256) NOT NULL Adresa vzdáleného serveru port int(6) unsigned, NOT NULL číslo portu vzdáleného serveru Wildmat pro specifikaci názv ů wildmat varchar(256) NOT NULL diskusních skupin time timestamp NOT NULL Čas poslední aktualizace gmt tinyint(1) NOT NULL, default 1 Používá se čas GMT 49 Java aplikace jako služba Windows NT V Jav ě neexistuje žádný nativní mechanismus, kterým by šlo aplikaci naprogramovat p římo jako službu Windows NT. Java však p řináší velice silné nástroje pro rychlou a robustní implementaci serverových systém ů, u kterých je požadavek na b ěh v rámci služby NT docela častý. P říkladem takové aplikace m ůže být nap říklad aplika ční server Tomcat . Možným řešením tohoto problému je využití JNI (Java Native Interface) a naprogramování aplikaci v jazyce, který m ůže p římo p řistupovat k Win32Api. Tato aplikace bude fungovat jako služba NT, spoušt ějící JVM (Java Virtual Machine) s požadovanou aplikaci v Jav ě. Tento postup se ukázal jako možné řešení, ale implementace není nijak jednoduchá a vzniklo n ěkolik r ůzných projekt ů, v rámci nichž se mén ě či více úsp ěšná řešení tohoto problému poda řila vytvo řit. P říkladem takových projekt ů je nap ř. JavaServiceLauncher nebo Java Service Wrapper. Pro tuto aplikaci byl zvolen projekt JavaService, jehož domovské stránky jsou na webové adrese: http://javaservice.objectweb.org/js_doc_frame.html a který je voln ě dostupný v rámci licence GPL. JavaService je software, který spravuje rozhranní mezi JVM a WindowsNT Service Handlerem. Využívá k tomu kód napsaný v C++ a Java JNI mechanismy. Mezi hlavní rysy tohoto programu pat ří, že není pot řeba d ělat žádné zm ěny v Java aplikaci, která má b ěžet jako služba, pracuje na systémech Windows NT4, XP, 2003, služba m ůže být konfigurována pro automatický nebo manuální start, existuje integrace s administrativními nástroji systému Windows (nap ř. s Prohlíže čem událostí). Pro b ěh implementovaných serverových řešení je pot řeba mít nainstalováno prost ředí JDK minimáln ě verze 6. Instalace služby probíhá následovn ě. Nejprve se soubor JavaService.exe (získaný z projektu JavaService) p řejmenuje na jméno požadované služby, takže chceme-li aby se služba jmenovalo ProNNTP, p řejmenujeme soubor na ProNNTP.exe. Pro instalaci služby spustíme soubor s následujícími parametry (ve složených závorkách psaných kurzívou jsou vysv ětlující komentá ře): ProNNTP.exe -install Orion {ur čení názvu služby} {JDK_HOME}\jre\bin\{hotspot|server|classic}\jvm.dll {ur čení cesty k jvm} -Djava.class.path={NNTP_HOME} {nastavení prom ěnné classpath} -start nntp.NNTPServer {cesta ke t říd ě s metodou main()} -out {NNTP_HOME}\log\stdout.log {soubor pro záznamy ze std. výstupu} -err {NNTP_HOME}\log\stderr.log {soubor pro záznamy z chybového výstupu} -current {NNTP_HOME} {ur čení aktuálního pracovního adresá ře} -depends mysql {název služby, která má být spušt ěna p řed touto službou} -description "NNTP Server" {Popis služby zobrazí se v Service Control Manageru} 50 Po provedení tohoto p říkazu se nainstaluje služba ProNNTP, která se bude automaticky spoušt ět při startu Windows a v rámci které pob ěží Java aplikace ur čená parametrem -start . Tuto službu lze ovládat prost řednictvím konzole Služby systému Windows nebo prost řednictvím p říkaz ů NET. 51 Záv ěr V rámci této práce se poda řilo navrhnout a implementovat diskusní NNTP server na základ ě specifikovaných požadavk ů. V pr ůběhu práce na projektu došlo k vydání standardu RFC 3977, který definuje novou verzi protokol NNTP. Z tohoto d ůvodu byl p ůvodní návrh vycházející ze staré verze NNTP protokolu upraven a implementován byl server podle nového standardu. Vytvo řený systém je navíc vybaven režimem kompatibility tak, aby mohl spolupracovat s existujícími NNTP klienty. Dále bylo vytvo řeno univerzální webové rozhraní, které lze využít i pro p řipojení k jakémukoliv jinému NNTP serveru. P ři návrhu a implementaci bylo dbáno také na bezpe čnost vytvá řeného serverového řešení. Server disponuje zabezpe čenými variantami použitých protokol ů a p ři implementaci byl brán ohled na zamezení n ěkterým taktikám útok ů na systém. Implementace serveru v jazyce Java umožňuje nasazení vytvo řené aplikace i na jiných opera čních systémech. Objektov ě orientovaný návrh a d ůkladná dekompozice do t říd umož ňuje pom ěrn ě snadné rozší ření vytvo řeného systému. Z hlediska dalšího vývoje by bylo dobré doplnit aplikaci mechanismy specifikovanými v rozší řeních nového protokolu NNTP. Dále se nabízí možnost dopln ění sí ťového systému filtrem p říchozích spojení, kterým by se dalo zamezit p řístupu pop ř. zasílání článk ů z ur čitých IP adres. Vývoje by mohl také spo čívat v dopln ění možnosti definovat práva p řístupu jednotlivých uživatel ů k diskusním skupinám tj. definovat, zda má daný uživatel právo skupinu prohlížet, zasílat do ní, zda ji má mít viditelnou v seznamu skupin, atd. Pro zvýšení výkonnosti systému by bylo vhodné nahradit použitý databázový systém MySQL n ějakým výkonn ějším systémem, pop ř. vyvinout databázový systém specializovaný pro data, se kterými pracuje protokol NNTP. Systém stahování článk ů ze vzdálených server ů by bylo vhodné doplnit mechanismem, který dokáže stáhnout nov ě vytvo řené diskusní p řísp ěvky, aniž by využíval p říkazu NEWNEWS. Provedení tohoto p říkazu je totiž výpo četn ě náro čné a mnoho administrátor ů ho na svých NNTP serverech zakazuje. Komfort administrace systému by mohl být zvýšen dopln ěním webového rozhraní pro vzdálenou správu. Možnost nasazení systému v praxi byla ov ěř ena n ěkolikatýdenním provozem aplikace v menší organizaci, kde server zprost ředkovával p řístup k několika často používaným diskusním skupinám. 52 Literatura [1] CommSoft Systems Development: An Introduction to NT Services . 2000. Dokument dostupný naURL http://www.commsoft.com/services.html (kv ěten 2007). [2] Feather, C.: RFC 3977 Network News Transfer Protocol.. 2006. Dokument dostupný na URL http://www.ietf.org/rfc/rfc3977.txt (kv ěten 2007). [3] Fread, F., Borenstein, F.: RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies . 1996. Dokument dostupný na URL http://www.ietf.org/rfc/rfc2045.txt (kv ěten 2007). [4] Halsall, F.: Computer Networking and the Internet . Fifth Edition, Addison Wesley, 2005. [5] Horton, M.: RFC 850 Standard for Interchange of USENET Messages. 1983. Dokument dostupný na URL http://www.faqs.org/rfcs/rfc850.html (kv ěten 2007). [6] Hruška, T., Burget, R.: Internetové aplikace (WAP) 1 . Brno, 2006. Dokument dostupný naURL https://www.fit.vutbr.cz/study/courses/WAP/private/oporaWAP1.pdf (kv ěten 2007). [7] Kantor, B., Lapsley, P.: RFC 977 Network News Transfer Protocol.. 1986. Dokument dostupný na URL http://www.ietf.org/rfc/rfc0977.txt (kv ěten 2007). [8] Loupanec, J.: NNTP server jako služba pro systémy založené na technologii Windows NT . Semestrální projekt, Brno, FIT VUT v Brn ě, 2007. [9] Moore, K.: RFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text . 1996. Dokument dostupný na URL http://www.faqs.org/rfcs/rfc2047.html (kv ěten 2007). [10] Network Working Group: RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1 . 1999. Dokument dostupný na URL http://www.w3.org/Protocols/rfc2616/rfc2616.html (kv ěten 2007). 53 [11] Vinocour J., Murchinson K.: RFC 4643 Network News Transfer Protocol (NNTP) Extension for Authentication.. 2006. Dokument dostupný na URL http://www.eyrie.org/~eagle/nntp/rfcs/rfc4643.txt (kv ěten 2007). [12] Wikipedie: Rela ční databáze . Dokument dostupný na URL: http://cs.wikipedia.org/wiki/Rela%C4%8Dn%C3%AD_datab%C3%A1ze (kv ěten 2007). Seznam p říloh [A] Manuál k vytvo řenému programu. 54 Přílohy A. Manuál k vytvo řenému programu A.1. Instalace programu Požadavky na systém Pro úsp ěšné spušt ění aplikace je pot řeba mít nainstalované tyto sou části: Opera ční systém: MS Windows (minimální verze NT4) Databázový systém: MySQL (minimální verze 5.0.47) Java: The Java SE Development Kit (JDK) (minimální verze 6) Příprava databáze MySQL 1.) Nainstalujte databázi MySQL. 2.) P řihlaste se k databázi prost řednictvím MySQL konzole. K přihlášení použijte heslo administrátora zadané b ěhem instalace. 3.) P říkazem INSERT INTO user VALUES('localhost', 'jméno_uživatele', PASSWORD('heslo'), 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N'); vložte nový uživatelský ú čet se zvoleným jménem ( řet ězec jméno_uživatele ) a heslem ( řet ězec heslo ). 3.) Vytvo řte nové schéma databáze, ve kterém budou pozd ěji vytvo řeny tabulky pot řebné pro ukládání dat NNTP serveru. Schéma databáze vytvo říte p říkazem CREATE DATABASE 'název_schematu ' /*!40100 DEFAULT CHARACTER SET utf8 */; 4.) Nastavte vytvo řenému uživatelskému ú čtu práva k vytvo řenému schématu prost řednictvím p říkazu 55 INSERT INTO db VALUES('localhost','název_schematu','jméno_uživatele','Y','Y','Y','Y ','Y','N','Y','N','N','N'); 5.)P říkazem FLUSH PRIVILEGES; zave ďte nového uživatele. 6.) P říkazem Exit; ukon čete práci s konzolou MySQL. Instalace služeb NNTP a HTTP rozhraní 1.) Adresá ř s programem ProNNTP umíst ěte na libovolné místo v adresá řové struktu ře tak, aby cesta k adresá ři neobsahovala mezeru. To je d ůležité, protože jinak nebudou fungovat instala ční skripty. 2.) V ko řenové složce programu se nachází skript CompileAll.bat , jehož spušt ěním prove ďte kompilaci všech sou částí programu. 3.) Klikn ěte pravým tla čítkem na ikonu souboru InstallProNNTPservice.bat a zvolte Upravit. V souboru upravte řádek set JAVA_HOME=C:\Progra~1\Java\jdk1.6.0_01 , tak aby obsahoval cestu k adresá ři s Java JDK ve vašem systému. Zm ěny uložte a takto upravený soubor spus ťte. Provede se instalace služby ProNNTP reprezentující NNTP rozhraní a její následné spušt ění. 4.) Zopakujte 3. krok i pro soubor InstallProNNTPwebService.bat . Tento krok má za následek vytvo ření služby ProNNTPweb reprezentující HTTP rozhranní a následné spušt ění této služby. 5.) Zkontrolujte soubory nntperrlog a httperrlog v ko řenovém adresá ři programu ProNNTP, které obsahují p řípadná chybová hlášení spušt ěných služeb. Další p řípadné problémy lze zjistit pomocí Prohlíže če událostí systému Windows (Start-Ovládací panely-Nástroje pro správu-Prohlíže č událostí). Vytvá ření souboru s klí či pro šifrovanou komunikaci Aplikace umož ňuje všechna použitá spojení zabezpe čit šifrováním. K tomu je pot řeba, aby byl vytvo řen takzvaný klí čový sklad ( keystore ). Tento sklad slouží k uložení soukromých klí čů a certifikát ů. Dále slouží také k uložení ve řejných klí čů server ů, ke kterým je umožn ěno klientské šifrované spojení. Výchozí implementace klí čového skladu v Jav ě reprezentuje tento sklad jako soubor chrán ěný heslem. Vytvo řené serverové řešení nedisponuje žádnými mechanismy k administraci tohoto souboru, proto je nutné tuto administraci provád ět manuáln ě. Možným řešením je využití program 56 keytool (sou část java runtime environment, v adresá ři /bin). Popis použití tohoto nástroje pro vytvo ření skladu s klí či a jeho následné administrace je popsán na webových stránkách http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html. A.2. Nastavení programu Konfigurace NNTP rozhraní Konfigurátor NNTP rozhraní se spustí skriptem ProNNTPconfig.bat z ko řenového adresá ře programu ProNNTP. Po spušt ění se zobrazí okno, v jehož spodní části jsou t ři tla čítka. Tla čítko Save settings provede uložení jednotlivých nastavených voleb do souboru. Tla čítko Restart service slouží k restartování služby ProNNTP a tím pádem k na čtení nových konfigura čních údaj ů. Hlavní nastavení Toto nastavení se provádí na záložce General setting (Seznam obrázk ů, obr.1). Edita ční pole Port umož ňuje nastavit port, na kterém bude NNTP server naslouchat. Zaškrtnutím polí čka Secure server je možné specifikovat, že má server akceptovat pouze šifrované spojení. Aby mohl být tento typ spojení navázán musí být ješt ě specifikován soubor se skladem klí čů ( KeystoreFile ) a heslo (KeystorePassword ) k tomuto souboru. Ve spodní části okna je možno zvolit, v jakém módu NNTP server pob ěží. Lokální mód (volba Local server ) udává, že server bude pracovat s lokální databází, proxy mód (volba Proxy server ) znamená, že p říchozí NNTP p říkazy budou p řeposílány na jiný NNTP server. Nastavení lokálního serveru Záložka Local Setting (Seznam obrázk ů, obr.2) slouží k nastavení atribut ů týkajících se lokálního módu. První edita ční pole ( Server name ) umožňuje specifikovat jméno serveru. P řepína čem u položky Posting : je možné specifikovat, zda je povoleno na server posílat diskusní p řísp ěvky (volba Enabled ) nebo není (volba Disabled ). Dále je možné ur čit maximální velikost zasílaného článku v kilobajtech (Max. article size ) a časový interval v milisekundách, po kterém vyprší neaktivní spojení se serverem (Connection timeout ). V panelu Server database connection setting se nastavují jednotlivé parametry pot řebné pro p řipojení k databázovému systému. Jedná se o adresu serveru ( Server :) s databázovým systémem MySQL, port (položka Port: ), na kterém tento systém naslouchá, p řihlašovací jméno (Login ), heslo ( Password ) a název schématu databáze ( Sheme). Nastavení proxy serveru 57 V rámci záložky Proxy setting (Seznam obrázk ů, obr.3), lze nastavit, adresu ( Remote server ) a port (Port ) serveru, na který budou p řeposílány NNTP p říkazy v případ ě, že NNTP rozhraní b ěží v proxy módu. Dále je možné ur čit, že pro spojení se vzdáleným serverem má být použito zabezpe čené spojení (Secure NNTP Client (SSL) ). V tomto p řípad ě je též nutné ur čit soubor s ve řejným klí čem vzdáleného serveru ( Keystore file ) a heslo ( Password ) k tomuto souboru. Synchronizace Na záložce Synchronization je možné nastavit, zda synchronizaci provád ět nebo neprovád ět (Synchronization enabled ). A v případ ě, že má být synchronizace provád ěna, ur čit interval jednotlivých synchronizací. Databáze Záložka Database umož ňuje spravovat informace uložené v databázi. Informace pro p řihlášení k databázi se nastavují prost řednictvím záložky Local Settings . (Nastavené údaje musejí být uloženy tla čítkem Save setting , aby byly použity) Databáze - Správa skupin a p řísp ěvk ů Použití tla čítka Newsgroups & news má za následek zobrazení okna se dv ěma seznamy. Seznam vpravo ( Newsgroups ) obsahuje názvy diskusních skupin. Prost řednictvím tla čítka Add je možné vyvolat formulá ř pro p řidání nové skupiny. Tla čítkem Edit formulá ř pro editaci ozna čené skupiny. Akce tla čítka Delete vymaže ozna čenou diskusní skupinu i se všemi články z databáze. V případ ě, že je vybrána n ěkterá diskusní skupina, v seznamu nalevo ( News ) se obrazí seznam p ředm ětů článk ů, které do zvolené skupiny náležejí. Výb ěrem článku a klinutím na tla čítko Open je možné si článek prohlédnout, tla čítko Delete umož ňuje smazání ozna čeného článku z diskusní skupiny. Databáze - Správa uživatelských ú čtů Použití tla čítka Users má za následek zobrazení okna se seznamem p řihlašovacích jmen ( Users ) v databázi uložených uživatel ů. Prost řednictvím tla čítek v tomto okn ě je op ět možné p řidávat ( Add ), upravovat ( Edit ) a odstra ňovat ( Remove ) uživatelské ú čty. Databáze - Správa distribu čních vzor ů Okno vyvolané stisknutím tla čítka Distribution Patterns disponuje seznam distribu čních vzor ů pro NNTP p říkaz LIST DISTRIB.PATS a umož ňuje nové hodnoty p řidávat ( Add ), m ěnit ( Edit ) a odebírat (Remove ). Databáze - Správa ú čtů vzdálených NNTP server ů 58 Okno pro správu ú čtů vzdálených NNTP server ů se vyvolá stiskem tla čítka Remote servers. Prost řednictvím seznamu ( Remote NNTP Servers ) v tomto okn ě je možné zadávat ( Add ), m ěnit ( Edit ) a odebírat ( Remove ) jednotlivé údaje obsahující adresu a port NNTP server ů pro synchronizaci. Pro každý záznam je možné ur čit řet ězec wildmat vymezující názvy diskusních skupin, jejichž obsah se má ze serveru specifikovaném daným záznamem získat. Databáze - Vytvo ření tabulek databáze V případ ě, že v daném schématu ješt ě nejsou vytvo řeny databázové tabulky pro uložení dat NNTP serveru, stiskem tla čítka Create DB tables se tyto tabulky vytvo ří. Konfigurace HTTP rozhranní Program pro konfiguraci HTTP rozhraní se spustí dávkou ProNNTPwebConfig.bat , která je umíst ěna v ko řenové adresá ři programu ProNNTP. Spušt ění této dávky má za následek zobrazení konfigura čního okna (Seznam obrázk ů, obr.4). Tla čítko Save provede uložení jednotlivých nastavených voleb do souboru. Tla čítko Restart service slouží k restartování služby ProNNTPweb a tím pádem k na čtení uložených konfigura čních údaj ů. Konfigurátor umož ňuje nastavit port ( Http server port) , na kterém bude HTTP server naslouchat. Dále je možné zvolit, zda-li má být použito zabezpe čené p řipojení ( Secure HTTP server ). V takovém případ ě je pot řeba nastavit cestu k souboru se skladem privátních klí čů a certifikát ů ( KeyStoreFile ) a dále heslo k tomuto souboru ( KeyStorePassword ). Dále je potřeba nastavit adresu ( Remote NNTP server address ) a port ( Remote NNTP server port ) NNTP serveru, ke kterému bude webové rozhraní připojeno. Pro práci s lokálním NNTP serverem je nutné zadat IP adresu 127.0.0.1 a port, na kterém server naslouchá nastavený prost řednictvím konfigurátoru NNTP rozhraní. Pomocí položky Secure NNTP Server je možné ur čit, že ke vzdálenému serveru se má webové rozhraní p řipojovat zabezpe čeným spojením. Pokud je tato volba aktivní, je pot řeba ješt ě ur čit soubor ( KeyStoreFile ) obsahující ve řejný klí č serveru, ke kterému je požadováno p řipojení a heslo ( KeyStorePassword ) k tomuto souboru. Pomocí edita čního pole Charset se nastavuje znaková sada html stránek zobrazovaných NNTP rozhraním. 59 Seznam obrázk ů Obr. 1: Záložka General setting Obr. 2: Záložka Local server 60 Obr. 3: Záložka Proxy setting Obr. 4: HTTP Configurator 61