TOKE: Eina de suport als processos de webmining basada en programari lliure by Internet Web Serveis S.L.

TOKE: Eina de suport als processos de webmining basada en programari lliure Albert Nadal i Garriga <albert.nadal@estudiants.urv.es>

Universitat Rovira i Virgili Escola T`ecnica Superior dâ&#x20AC;&#x2122;Enginyeria Enginyeria Inform`atica

Projecte de fi de carrera agost de 2005

1 Fins on pot arribar el programari lliure? No hi ha l´ ımits, llevat quan lleis com els sistemes de patents prohibeixen el programari lliure en la seva totalitat. L’objectiu final ´ es oferir programari lliure capa¸ c de realitzar totes les tasques que els usuaris volen dur a terme, i per tant fer aix´ ı el programari propietari obsolet...

´Index 1 Introducci´ o

2 Exploraci´ o Web 2.1 Requeriments . . . . . . . . . . . . . . . . . . . . . . . 2.2 Disseny general del web crawler . . . . . . . . . . . . . 2.2.1 Arquitectura . . . . . . . . . . . . . . . . . . . 2.2.2 Estructures de dades . . . . . . . . . . . . . . . 2.2.3 Comunicació entre el web crawler i un servidor 2.2.4 Extracció d’hipervincles . . . . . . . . . . . . . 2.2.5 Esquema general del web crawler . . . . . . . . 2.3 Anomalies que afecten a l’exploració . . . . . . . . . . 2.3.1 Problemes derivats de la xarxa . . . . . . . . . 2.3.2 Resoluci´ o massiva de DNS . . . . . . . . . . . . 2.3.3 Implementacions HTTP . . . . . . . . . . . . . . 2.3.4 Codificació HTML . . . . . . . . . . . . . . . . . 2.3.5 Caracter´ıstiques dels continguts web . . . . . . 2.3.6 P` agines web dinàmiques . . . . . . . . . . . . . 2.4 Paràmetres i configuracions . . . . . . . . . . . . . . . 2.5 Estratègies d’exploració . . . . . . . . . . . . . . . . . 2.5.1 Breadth-First . . . . . . . . . . . . . . . . . . . 2.5.2 Depth-First . . . . . . . . . . . . . . . . . . . . 2.5.3 Backlink-Count . . . . . . . . . . . . . . . . . . 2.5.4 Batch-Pagerank . . . . . . . . . . . . . . . . . . 2.5.5 Larger-sites-first . . . . . . . . . . . . . . . . . 2.6 Exploracions d’àrees restringides . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

6 9 10 12 16 21 22 24 25 25 27 27 29 30 31 32 35 36 36 39 39 39 40

3 Extracci´ o i indexaci´ o d’informaci´ o 42 3.1 Extracci´o d’informaci´o . . . . . . . . . . . . . . . . . . . . . . 42 3.2 Crear un ´ındex . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3 Esquema general de l’indexador . . . . . . . . . . . . . . . . . 49

´INDEX

4 Diagrames de classe 51 4.1 Aplicació exploradora . . . . . . . . . . . . . . . . . . . . . . 51 4.2 Aplicació indexadora . . . . . . . . . . . . . . . . . . . . . . . 52 4.3 Aplicació de cerca . . . . . . . . . . . . . . . . . . . . . . . . 61 5 Llibreries utilitzades 5.1 Lucene . . . . . . . 5.2 Jung . . . . . . . . 5.3 JTidy . . . . . . . 5.4 PDFBox . . . . . . 5.5 Jakarta POI . . . . 5.6 IR-Webutils . . . . 5.7 HTTPClient . . . . 5.8 JFreeChart . . . .

. . . . . . . .

73 73 73 76 76 77 78 79 80

A Manual d’aplicaci´ o per a l’usuari A.1 Requeriments . . . . . . . . . . . . . . . . . . . . A.2 Instal·laci´ o . . . . . . . . . . . . . . . . . . . . . A.3 Explorar . . . . . . . . . . . . . . . . . . . . . . . A.3.1 Panells de control . . . . . . . . . . . . . A.3.2 Configuraci´ o de paràmetres d’exploració . A.3.3 Panells de monitorització i estad´ıstiques . A.3.4 Exploració - Operacions bàsiques . . . . . A.3.5 Explorar una àrea restringida . . . . . . . A.3.6 Visualitzaci´ o de grafs . . . . . . . . . . . A.4 Indexar . . . . . . . . . . . . . . . . . . . . . . . A.4.1 Configuraci´ o dels paràmetres d’indexació A.4.2 Indexar - Operacions bàsiques . . . . . . . A.5 Cercar . . . . . . . . . . . . . . . . . . . . . . . . A.5.1 Cercar en un ´ındex local . . . . . . . . . . A.5.2 Cercar en un ´ındex remot . . . . . . . . . A.5.3 Montar un servidor de cerques . . . . . .

. . . . . . . . . . . . . . . .

82 82 82 84 86 88 89 92 98 101 103 103 108 111 111 113 113

. . . . . . . .

B Conclusi´ o i propostes per al futur

116

C Preguntes m´ es freq¨ uents

118

Cap´ıtol 1

Introducci´ o L’objectiu d’aquest projecte consisteix en dissenyar i elaborar una aplicació multifuncional en Java, per a fer possible l’exploració i indexació de continguts web. Aix´ı doncs, s’han desenvolupat tres eines dedicades a realitzar tasques d’exploració, indexació de documents explorats, i recerca de continguts espec´ıfics en la xarxa. La idea d’aquest projecte sorgeix del boom d’Internet en els u ´ltims anys i la necessitat de disposar de mitjans per a organitzar la informació i accedir a aquesta de forma ràpida. Actualment resulta dif´ıcil i complex classificar o categoritzar la informació, ja que aquesta creix a un ritme accelerat, tenint en compte que els continguts informatius tenen tendència a generar-se sense seguir un model o patró concret. A causa de la gran quantitat d’informació i la necessitat de localitzar aquesta en el menor temps possible, s’han desenvolupat sistemes per facilitar i flexibilitzar la tasca de cercar informació sense haver de recórrer al r´ıgid procediment de categoritzar-la jeràrquicament en un procés previ. En aquest terreny cal parlar dels sistemes d’extracció i indexació d’informació (Information Retrieval), entre els quals cal destacar-ne un que pot considerar-se com uns dels protagonistes o elements principals d’aquest projecte. Es tracta de Lucene, una llibreria de codi obert per a Java, que afegeix funcionalitats d’indexació i cerca a les aplicacions. L’element central d’aquest projecte de final de carrera, que s’hi ha dedicat més atenció, és l’eina d’exploració. Es tracta d’una eina for¸ca completa que pot sér utilitzada amb finalitats, que no només es limiten a les mencionades en les l´ınies anteriors, sinó que abarquen aspectes, no menys importants, com ara l’anàlisi i visualització de xarxes de nodes web. En aquest sentit cal destacar la possibilitat de generar estad´ıstiques, detectar problemes, i fins i tot, representar gràficament, i en forma de graf, les exploracions realitzades. Seguint amb aquesta l´ınia, les eines d’indexació i cerca són refor¸cades amb un conjunt de funcionalitats addicionals, com ara la

´ CAP´ITOL 1. INTRODUCCIO

generació de fitxers de freq¨ uències de paraules que poden ser usats per a realitzar estudis de cl´ ustering d’informació i, la possibilitat d’usar un servidor desenvolupat exclusivament per a realitzar cerques sobre ´ındexs d’informació remots. Juntament amb el software implementat s’inclou aquesta documentació o memòria del projecte, en la qual s’intenta explicar de manera general com s’han desenvolupat les diferents parts que composen l’aplicació, aix´ı com el seu funcionament intern detallat. Es pretén que la persona que ho llegeixi obtingui una idea clara del que s’ha fet, com s’ha fet i comprengui els beneficis que aporta usar una eina d’aquestes caracter´ıstiques. L’autor d’aquest projecte vol deixar constància que tot el material desenvolupat, tant el codi font com aquest document, és gratu¨ıt i de codi obert, per tant, aix` o dona dret a que qualsevol persona pugui obtenir i utilitzar aquest material. Com que es tracta de codi obert, totes les distribucions d’aquesta aplicació inclouen el seu corresponent codi font per tal que pugui ser estudiat, reciclat o modificat sense finalitats lucratives. Tot el material pot ser adquirit a través de la web http://toke.sourceforge.net o bé, a partir de la web del seu autor http://www.telefonica.net/web2/albertng

Cap´ıtol 2

Exploraci´ o Web Per tal de poder explorar i analitzar els documents emmagatzemats en els diferents servidors web que composen una xarxa local o una internet, fa falta disposar d’eines de cerca que duguin a terme la tasca d’explorar i recórrer documents web navegant a través dels seus corresponents hipervincles(URLs). Aquesta tasca es du a terme mitjan¸cant aplicacions anomenades web crawlers, les quals s’encarreguen de travessar la Web seguint hipervincles i emmagatzemant al disc els documents explorats i descarregats, per tal que més tard, puguin sér tractats per dur a terme determinades operacions d’anàlisis sobre els documents. Els web crawlers són principalment usats pels cercadors web, com ara, Google, Yahoo o Altavista, entre d’altres. Aquestes entitats proporcionen una potent eina de cerca pels usuaris d’Internet, els quals poden localitzar el document web que els interessa tant sols inserint un breu nombre de paraules clau relacionades amb la temàtica que busquen. De cara a l’usuari, la principal tasca dels cercadors web es limita a proporcionar aquella informaci´ o concreta que l’usuari vol trobar, el més ràpid possible, realitzant la cerca a través d’una base de dades adientment indexada. L’altra tasca dels cercadors web consisteix en explorar la Web per tal de proporcionar nova informació que serà emmagatzemada o actualitzada a la base de dades. Una aplicació de web crawling pot ser implementada amb tant sols unes poques l´ınies de codi en llenguatges de programació de d’alt nivell com ara Java o Python. Tanmateix, existeixen un conjunt de problemes que en una exploraci´ o a petita escala serien m´ınims, però que en una exploració a gran escala podrien resultar seriosament complicats. Un dels principals problemes és explorar documents emmagatzemats en servidors, que presenten comportaments que afecten al rendiment de la exploraci´ o. Per exemple, un servidor que accepta les connexions entrants, però que falla a l’hora de respondre, o simplement respon a una velocitat molt lenta.

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.1: Web crawling - Algorisme general

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.2: Funcionament intern de Google

Un altre tipus de trampa per a un web crawler és provar de descarregar documents que tenen un tamany excesivament elevat o explorar un servidor web que genera dinàmicament les seves pàgines i els corresponents hipervincles, de manera que una exploració sobre aquest servidor no finalitza mai. Una de les principals caracter´ıstiques d’un web crawler recau en el nombre de pàgines que és capa¸c d’explorar per unitat de temps. Per tal de descarregar un bilió de pàgines en un any, un web crawler hauria de ser capa¸c de mantenir una taxa de descàrrega de 32 pàgines per segon. Tanmateix, els motors de b´ usqueda emprats pels cercadors web més importants, no només han de ser capa¸cos d’explorar nous documents, sinó que a més a més, han de ser capa¸cos de detectar i descarregar aquells documents que ja han estat descarregats anteriorment i, que el seu contingut ha caducat o ha

´ WEB CAP´ITOL 2. EXPLORACIO

estat actualitzat. Aquest fet posa de manifest la importància d’efectuar exploracions el més ràpid possible. El web crawler proposat en aquest projecte ha estat dissenyat per suportar exploracions de mitjana escala, és a dir, explorar un conjunt de dominis d’Internet o simplement explorar la web d’una xarxa local amb un elevat nombre de servidors interconnectats entre si mitjan¸cant hipervincles. Amb una bona configuraci´ o, pot descarregar grans quantitats de documents aprofitant l’ample de banda i generar resultats i estad´ıstiques a partir de la informació d’estat acumulada durant l’exploració. Es tracta d’un web crawler flexible que permet configurar cada exploració modificant un gran nombre de paràmetres disponibles. Durant els pròxims apartats, es descriu el funcionament intern del web crawler implementat en aquest projecte. Concretament, es tractarà d’explicar detalladament els aspectes més destacats que afecten a l’estructura, rendiment, fiabilitat i les diferents estratègies de crawling emprades, aix´ı com les estructures de dades que calen per tal que tot el conjunt funcioni correctament i de manera eficient.

2.1

Requeriments

A continuació, s’expliquen els requeriments que ha de tenir un bon web crawler, i els procediments que cal seguir per a assolir-los: Flexibilitat Consisteix en que el sistema pugui ser utilitzat en diferents escenaris, aplicant el menor nombre de canvis possible. Baix cost i alt rendiment El sistema hauria de ser capa¸c de descarregar varis centenars de pàgines web per segon i centenars de milions de pàgines per exploraci´ o, i a més a més, hauria de funcionar amb el m´ınim cost possible ´ important destacar que l’´ en termes de hardware. Es us eficient dels accessos al disc és determinant per mantenir una alta velocitat, ja que en alguns casos la memòria principal de l’equip no és suficient per emmagatzemar les estructures de dades. Aquests casos només succeeixen després de descarregar varis milions de pàgines. Robustesa En aquest apartat hi ha diferents aspectes. Tot i que el sistema ha de ser capa¸c d’interactuar amb milions de servidors, a més a més, aquest ha de ser capa¸c de tolerar documents web mal formats, configuracions i comportaments estranys de servidors web, i moltes altres situacions anòmales. L’objectiu es basa en explorar amb precaució, i si es necessari,

´ WEB CAP´ITOL 2. EXPLORACIO

ignorar pàgines i servidors web sencers amb comportaments no desitjats, i per tant, descarregar només subconjunts de pàgines. A més a més, cal tenir en compte que una exploració pot durar semanes o mesos, i per tant, el sistema ha de ser capa¸c de tolerar fallides i interrupcions de la xarxa, intentant perdre la menor quantitat d’informació possible. Aix´ı doncs, l’estat del sistema ha de sér guardat al disc. Una bona estratègia consisteix en sincronitzar periòdicament les estructures principals al disc, i reexplorar un nombre limitat de pàgines després d’una fallida del sistema. ´ molt important seguir les convencions estàndars Control de velocitat Es d’exclusió de robots web (robots.txt i els meta tags de les pàgines web). A més a més, cal controlar la velocitat d’accés en diferents aspectes. Cal evitar saturar els servidors web mitjan¸cant descàrregues massives. és molt recomanable controlar la velocitat de descàrrega en un determinat nivell de domini(subdomini), amb l’objectiu de no generar denegacions de servei a petits servidors web de manera involuntària. Finalment, si el web crawler s’executa dins d’un entorn tancat, com ara, un campus universitari on la connexi´ o és compartida amb la resta d’usuaris de la xarxa, cal controlar detalladament la taxa de descàrrega del crawler. En particular, cal explorar a un ritme baix durant les hores de més activitat de la xarxa, i a un ritme elevat durant la nit que és quan el tràfic de la xarxa és m´ınim. Manejabilitat i reconfigurabilitat Una apropiada interf´ıcie és necess` aria per monitoritzar l’exploraci´ o incloent la velocitat d’aquesta, estad´ıstiques sobre els hosts i les pàgines, i els tamanys de les estructures principals. L’administrador ha de ser capa¸c d’ajustar la velocitat, afegir i treure components, aturar el sistema, for¸car una pausa, o simplement afegir hosts i dominis a una llista negra d’URLs que el web crawler haurà d’evitar descarregar. Després d’una fallida o aturada de la xarxa, el software del sistema pot sér modificat per arreglar els problemes i per tant, poder continuar l’exploració utilitzant una configuraci´ o diferent. Els resultats d’una llarga exploració acostumen a ser notablement diferents dels que hi havia al principi.

2.2

Disseny general del web crawler

Abans d’explicar l’esquema general, cal tenir clar que les quatre parts més importants d’un web crawler són les que s’expliquen a continuació: • Estructura de dades que conté les URLs pendents d’explorar. • Estructura de dades que conté les URLs ja explorades. • Sistema de resoluci´ o de DNS. • Sistema de descàrrega de documents.

´ WEB CAP´ITOL 2. EXPLORACIO

El web crawler ha de disposar d’una estructura de dades que emmagatzemi totes les URLs que resten pendents de ser explorades. Aquesta estructura s’ha d’interpretar com una llista d’elements, de manera que la seg¨ uent URL en ser explorada serà la primera de la llista. En funció de l’estratègia d’exploració que s’utilitzi, les noves URLs s’inseriran al principi, al final o en alguna posició concreta de la llista. L’estructura de dades que conté les URLs ja explorades té un pés molt important dins de l’aplicació. La seva tasca elemental es basa en memoritzar les URLs que han estat explorades i permetre saber si una URL ja ha estat explorada anteriorment, per tal d’evitar descarregar pàgines que ja ho estan. En el web crawler implementat, aquesta estructura proporciona una seguit de funcionalitats addicionals que s’explicaran més endavant. Ja que la prioritat principal és la velocitat d’exploració, és a dir, el nombre de pàgines explorades per unitat de temps, és molt important que les dos estructures de dades mencionades ofereixin temps de resposta m´ınims. La resolució de DNS o resolució de nom de domini s’empra per tal que el web crawler pugui obtenir l’adre¸ca IP associada al nom de domini d’una determinada url. En UNIX s’acostuma a utilitzar la crida gethostbyname(), mentre que Java ja disposa d’un sistema de resolució de DNS juntament amb la llibreria de classes dedicada al desenvolupament d’aplicacions de xarxa. La fase de resoluci´ o de DNS s’acostuma a implementar seguint el mateix sistema que s’utilitza per les descàrregues de documents. M´ ultiples peticions de resolució de DNS s’efectuen en paral·lel de manera ass´ıncrona o mitjan¸cant timeouts. En Java, la resoluci´ o de DNS és moderadament efectiva, perqué que la interf´ıcie de la API dedicada a aquesta tasca és del tipus synchronized, és a dir, m´ ultiples peticions de DNS simultànies s’encuen i són tractades de manera seq¨ uencial. La solució a aquest petit problema no ha estat implementada durant el desenvolupament d’aquest web crawler realitzat en Java, tanmateix; la implementaci´ o d’un sistema de resolució de DNS propi basat en m´ ultiples fils d’execuci´ o concurrents ho solucionaria. ´ important destacar que, a diferència de les persones, una aplicació de Es web crawling que treballa amb una connexió d’alta velocitat (ATM o Gigabit Ethernet), es limita bàsicament a provar de descarregar centenars de pàgines per minut, generant un tràfic i un nombre de peticions de descàrrega molt elevats en poc temps. Això pot provocar problemes de denegació de servei a petits servidors web amb recursos limitats, activar el mode d’alarma en sistemes de detecció d’intrusions o fins i tot; acaparar tot l’ample de banda de la connexi´ o suposant que es posi en funcionament dins d’una petita xarxa local. Queda clar que cal configurar adientment el web crawler abans

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.3: Interacció entre l’aplicació de crawling i el gestor de descàrregues de posar-lo en marxa.

2.2.1

Arquitectura

Existeixen diferents possibilitats alhora de desenvolupar un web crawler. Per una banda, hi ha models basats en entorns distribu¨ıts, és a dir; estacions de treball que funcionen coordinadament a través d’una xarxa. Per l’altra, hi ha models totalment centralitzats, com és el cas que s’ha desenvolupat en aquest projecte. En aquest model s’efectuen totes les operacions sobre una u ńica màquina, mentre que en el model distribu¨ıt fa falta que existeixi almenys una estació de treball que planifiqui i reparteixi totes les tasques que han de realitzar la resta d’equips connectats. El model centralitzat desenvolupat, es divideix en dos parts clarament diferenciades: l’aplicació de crawling i el gestor de descàrregues. Ambdós parts interactuen entre si durant tot el procés d’exploració. L’aplicació de crawling s’encarrega de generar estad´ıstiques, escriure dades al disc i generar la informació d’estat, però la seva tasca principal és extreure els hipervincles de les pàgines descarregades i proporcionar les URLs al gestor de descàrregues. En canvi, la tasca del gestor de descàrregues consisteix en mantenir i gestionar les estructures de dades de les URLs pendents i de les URLs ja descarregades, a més a més, de planificar les descàrregues HTTP i proporcionar els documents descarregats a l’aplicació de crawling.

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.4: Esquema general del nucli La interacció entre ambdós parts o mòduls es basa en un comportament del tipus productor i consumidor en circu¨ıt tancat, és a dir, les entrades d’un són les sortides de l’altre, i viceversa. El control de l’exploració el du a terme l’aplicació de crawling, ja que és aquest qui en gran mesura s’encarrega de controlar que es compleixin els paràmetres de configuraci´ o que afecten a la durada o dimensi´ o de la exploració: profunditat màxima, nombre l´ımit de pàgines a explorar o perm´ıs per explorar enlla¸cos externs. L’aplicació de crawling i el gestor de descàrregues constitueixen el nucli de l’aplicació. El nucli és totalment transparent a l’usuari, és a dir, l’usuari només pot interactuar amb els resultats generats pel nucli en temps d’exploració, configurar-ne el seu comportament abans d’iniciar el procés, o en tot cas, aturar-lo. La comunicació entre l’usuari i el nucli passa a través de la interf´ıcie d’usuari (GUI) i el controlador de l’aplicació respectivament mitjan¸cant les classes InterficieGrafica i WebCrawler del projecte.

Aplicaci´ o de crawling L’aplicació de crawling és implementada mitjan¸cant la classe Aranya del projecte. Es tracta d’un mòdul molt flexible en el sentit que pot sér utilitzat aplicant diferents combinacions de configuracions mitjan¸cant els paràmetres del seu constructor. Una de les principals caracter´ıstiques és la possibilitat

´ WEB CAP´ITOL 2. EXPLORACIO

de poder ser utilitzat en altres aplicacions de crawling sense necessitat de modificar el seu codi, o si més no, modificant-ne una petita part si resulta necessari. El mòdul gestor de descàrregues es pot considerar la segona part cr´ıtica del nucli del web crawler, ja que ha estat creat exclusivament per q¨ uestions de disseny. D’aquesta manera, a través del gestor de descarregues, queda encapsulat tot un conjunt d’elements que d’alguna manera tenen una forta dependència entre si, com ara, les estructures de dades de nodes visitats i nodes pendents, el logger d’errors o els fils d’execució de descàrregues HTTP. Tal i com s’ha dit anteriorment, la tasca principal de l’aplicació de crawling consisteix en extreure les URLs dels hipervincles dels documents HTML descarregats. L’aplicació determina, mitjan¸cant l’extensió del document, si es tracta d’un document HTML o no. El procés d’extracció d’hipervincles s’explica en detall en els pròxims apartats. De cada document s’obté el tamany, el domini i el tipus d’extensió. El tamany el proporciona el propi gestor de descàrregues, mentre que els altres dos atributs s’obtenen analitzant la URL del document. L’extracció dels hipervincles es du a terme mitjan¸cant l’´ us de la classe FiltreHTML del projecte. Totes les URLs extretes són proporcionades, una a una, al gestor de descàrregues. L’entrega de cada URL es fa indicant-ne la prioritat, el tipus d’operació que cal realitzar per a descarregar-la, la profunditat i l’identificador de la URL d’on s’ha extret. La prioritat determina si haurà d’anar a la cua de nodes prioritaris pendents de descarregar, o bé si anirà a la cua de nodes secundaris pendents de descarregar. Una URL és prioritària si el seu host és el mateix que el de la URL inicial, i a més a més, hi ha activat el paràmetre de prioritats. Els tipus d’operació de desc` arrega són tres: GET simple, GET amb cookies i POST amb cookies. El tipus d’operació escollit dependrà de si es fa una exploració en una regió p´ ublica, en una de restringida, o bé si es fa una operació d’auto-completar formulari respectivament. Mitjan¸cant la URL i el tamany dels documents proporcionats pel gestor de descàrregues, s’obtenen les dades necessàries per actualitzar les estad´ıstiques i la informació d’estat de l’exploració. D’aquesta manera es mantenen actualitzats els histogrames de tamany, extensió i domini. Cada document descarregat es guarda en una Intranet al disc. La gestió de la Intranet es fa mitjan¸cant l’´ us de la classe GestorIntranet del projecte, mitjan¸cant la qual es crea al disc una representació quasi exacta del sistema de fitxers dels servidors web explorats. Gestor de desc` arregues El gestor de descàrregues constitueix la part més important del nucli, i per tant, del web crawler. Aquest encapsula les estructures de dades que conte-

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.5: Exemple d’arbre de fitxers ´ dins nen informació sobre els nodes pendents i els nodes ja descarregats. Es del propi gestor de descàrregues on es genera la major activitat de l’aplicaci´ o durant una exploraci´ o, entenent per activitat, totes aquelles operacions que produeixen accessos continus a memòria, invocacions a mètodes, creació de processos o entrades i sortides via sockets. Tal i com s’ha comentat en l´ınies anteriors, el gestor de descàrregues és l’encarregat de decidir quins documents web seran explorats i quins cal descarregar en cada moment, ´ aplicant sempre els paràmetres de configuració assignats per l’usuari. Es aquest l’´ unic mòdul del conjunt que té accés a les estructures de dades i també el que marca el ritme de tota l’exploració. Els inputs o entrades que alimenten el gestor de descàrregues són les URLs proporcionades per l’aplicació de crawling. L’aplicació de crawling proporciona un flux constant de URLs mentre no s’assoleixen els l´ımits establerts de l’exploraci´ o. Cada nova URL és memoritzada, i per tant s’afegeix al magatzem de URLs(estructura de nodes explorats) amb estat pendent i no descarregat, a més a més, s’insereix a la cua de nodes pendents(estructura de nodes pendents). El gestor de descàrregues no es preocupa de com ha d’inserir o extreure elements a la cua de nodes pendents, ja que aquesta cua té un comportament o un altre, en funció de l’estratègia d’exploració escollida per l’usuari, gràcies a l’´ us del polimorfisme de classes que ofereix Java. Les URLs que ja han estat explorades o n’estan pendents, és a dir, es troben al magatzem de URLs i tenen l’estat de pendent o descarregat, són ignorades i només es té en compte el vincle entre aquesta i la pàgina d’origen de la qual s’ha extret, ja que aquesta u ´ltima informació és necessària per a la composició del graf de nodes web. La descàrrega de cada document web es fa per mitjà de diferents fils d’execuci´ o de desc` arrega que s’executen concurrentment. Els fils d’execució

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.6: Agrupació de threads són implementats heredant el comportament de la classe Thread de Java. El nombre de descàrregues simultànies l’assigna el propi usuari, i és també aquest qui determina el nombre màxim de descàrregues simultànies que es fan sobre un mateix host. Aquests dos factors són molt importants, ja que determinaran el ritme o velocitat d’exploració del web crawler, encara que depenen exclusivament dels recursos de l’equip on s’executa i de l’ample de banda de la connexi´ o utilitzada. El gestor de descàrregues no només ha de ser capa¸c de generar processos de descàrrega de continguts web, sinó que a més a més, ha de ser capa¸c de gestionar-los. Aquesta tasca implica conèixer el nombre de fils d’execució actius i el nombre de fils d’execució actius assignats a cada host en cada moment. Per poder dur a terme aquest control, s’identifica cada fil d’execuci´ o mitjan¸cant un identificador, de manera que si l’usuari només vol un màxim de cinc descàrregues simultànies, s’assignaran identificadors amb valors compresos entre zero i quatre. L’avantatge d’indentificar cada procés mitjan¸cant un identificador permet saber en tot moment si el fil n encara resta actiu o bé ha finalitzat. De la mateixa manera, permet saber si hi ha fils d’execució que s’han quedat penjats o no. El control dels fils d’execució assignats a cada host, es fa mitjan¸cant l’´ us d’una taula de dispersió o taula de hash, mitjan¸cant la qual es possible saber quants processos actius té assignat un host determinat. Quan ja no s’efectuen més descàrregues sobre un host, aquest s’elimina de la taula de hash fins que es tornin a produir descàrregues sobre aquest.

2.2.2

Estructures de dades

Les estructures de dades implementades han estat dissenyades per oferir temps de resposta molt baixos i un consum m´ınim d’espai en mem`oria.

´ WEB CAP´ITOL 2. EXPLORACIO

Totes les operacions de consulta i insersió s’han implementat aplicant algorismes amb costos computacionalment acceptables, ja que aquest tipus d’operacions succeeixen durant tot el transcurs d’una exploració de manera quasi ininterrumpuda. L’aplicació consta de nombroses estructures de dades, algunes de més complexes i d’altres de més simples, com ara, la taula de hash utilitzada pel control dels fils d’execució. Durant les pròximes l´ınies, s’explicaran, en detall les dos estructures de dades més importants d’aquesta aplicació: l’estructura de nodes(URLs) explorats i l’estructura de nodes pendents d’explorar. Estructura de nodes explorats Aquesta és l’estructura de dades més important de tot el web crawler. No només serveix per memoritzar aquelles URLs que s’han descarregat, sinó que conté informació detallada de qualsevol document web descobert durant el transcurs del procés, com ara, el tipus de document, la profunditat, l’identificador, el seu estat, les URLs de sortida o les URLs d’entrada. D’aquesta manera, el gestor de descàrregues pot obtenir la informació que necessita de qualsevol url. L’estructura consisteix en un arbre Trie(Arbre Digital de Cerca), el qual proporciona uns costos d’insersió i consulta d’ordre O (n) i un cost en termes d’espai molt bo. La raó d’utilitzar aquest model d’estructura és deguda a que la URL de la gran majoria de documents web que s’exploren, tenen el mateix prefix. Això succeix u ńicament en aquells documents que pertanyen a un mateix host, o pertanyen a un mateix host i tenen la mateixa ruta dins d’aquest. El gran avantatge que aporta aquesta estructura és que aprofita molt bé la memòria RAM disponible del sistema. En termes de velocitat també ofereix molt bons resultats, encara que depèn en gran mesura de la composició i organització dels sistemes de fitxers dels servidors web on s’explora. Un servidor web ideal seria aquell que té pocs documents web per directori i una distància màxima entre l’arrel i el subdirectori més llunyà de pocs nivells. Aquesta situació oferiria, a la pràctica, uns temps d’accés i d’insersió amb un cost d’ordre O (1). Tanmateix, la situació real és que els servidors web presenten sistemes de fitxers amb una estructura arbòria de molta amplada, però de poca fond` aria. Cada node de l’arbre representa un directori o fitxer, de manera que l’arbre es modela a partir de les URLs proporcionades per l’aplicació de crawling. La conclusió que s’extreu d’aqu´ı és que s’acaba simulant en memòria una rèplica exacta del sistema de fitxers de la Intranet que es crea al disc, amb la diferència que al disc s’hi guarda u ńicament el contingut dels documents web descarregats.

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.7: Arbre d’URLs Tal i com s’ha comentat en l´ınies anteriors, per a cada URL inserida a l’arbre s’emmagatzema informació seva. Concretament, s’emmagatzema el seu identificador de node(url), el nom del node(per exemple, el nom de www.domini.net/info/info.txt seria info.txt), el tipus(extensió), la profunditat, una llista d’identificadors de nodes de sortida i d’entrada, i l’estat. L’estat determina bàsicament si aquell node cal descarregar-lo, si s’ha descarregat o si està pendent de sér descarregat. Tota aquesta informació s’emmagatzema al moment d’inserir el node a l’arbre i s’actualitza en aquelles situacions en què l’estat del node canvia o bé es detecten nous enlla¸cos d’entrada que cal enregistrar per generar el graf. Totes les URLs inserides són identificades per un identificador numèric. Aquesta desició es causada per motius d’eficiència, ja que no seria una bona solució utilitzar llistes de nodes de sortida i d’entrada que emmagatzemin URLs senceres enlloc d’idendificadors d’URL que ocupen molt menys espai. L’´ us d’identificadors implica la necessitat de realitzar consultes sobre l’arbre, ja sigui mitjan¸cant la URL o l’identificador de node com a claus. Els identificadors de node són assignats de manera incremental, és a dir, la enèssima URL que s’insereix a l’arbre se li assigna l’identificador amb valor n. La tasca d’obtenir informació d’un node per mitjà del seu identificador no es pot realitzar eficientment mitjan¸cant l’estructura d’arbre que s’ha explicat. Per resoldre aquest cas, s’utilitza una segona estructura que complementa les funcionalitats de l’arbre. Es tracta d’utilitzar una llista ordenada de parelles d’identificador i apuntador a node de l’arbre, de manera que les insersions a la llista es fan ordenadament. Aix´ı doncs, el gestor de descàrregues pot obtenir informació d’una determinada URL mitjan¸cant la pròpia URL o bé mitjan¸cant un identificador de URL. Les consultes es fan aplicant un algorisme de cerca dicotòmica sobre la llista, amb la qual cosa, ´ important res’obtenen els resultats amb un cost d’ordre O (n ∗ log n). Es

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.8: Estructura d’URLs explorades per host marcar que les consultes per mitjà dels identificadors de node s’utilitzen principalment per accel·lerar la creació del graf de nodes i per recuperar exploracions guardades al disc. S’observa que l’´ us d’un vector seria molt més adient que el d’una llista, ja que si les insersions es fan seq¨ uencialment i les assignacions d’identificador es fan ascendentment incrementant cada vegada en una unitat el valor anterior, resulta que cada n´ umero de posició del vector coincidiria amb l’identificador de URL inserit en aquella posició. Això vol dir que amb un cost d’ordre O (1) es podria obtenir la informació desitjada mitjan¸cant l’identificador de la URL. Tanmateix, aix` o només és cert amb les condicions anteriors i suposant que l’assignació d’identificador es faci de la manera mencionada, però no serviria si en un futur es desitja canviar el procediment d’assignació per un altre de diferent. és per aquest motiu que es fan les insersions ordenadament sobre una llista. La solució explicada fins ara és vàlida només en el cas que l’exploració es faci u ńicament sobre els documents web d’un mateix host o domini. Però sempre hi ha hipervincles que fan referència a pàgines web que es troben en altres servidors web. Per tal que m´ ultiples hosts es puguin tenir en compte s’usa una taula de hash que emmagatzema parelles de host i arbre de nodes, de manera que hi ha un arbre per a cada host, i una u ńica llista de parelles d’identificador i apuntador a node d’arbre. Estructura de nodes pendents La tasca d’aquesta estructura és mantenir, seguint un ordre determinat, totes les URLs que han de ser explorades. Es tracta bàsicament de dos llistes d’URLs: una llista d’URLs prioritàries i una llista d’URLs secundàries. Les operacions més importants que efectua el gestor de descàrregues són afegir noves URLs i extreure la seg¨ uent URL de les llistes. La presència de dos

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.9: Estructura d’URLs explorades llistes amb prioritats diferents es degut al fet que l’usuari pot decidir si vol donar prioritat a les URLs que tenen el mateix host o subhost, que el host de la URL d’inici d’exploració. D’aquesta manera, a la llista prioritària s’hi afegeixen les URLs que pertanyen al host o domini d’inici, i a la llista sencundària s’hi afegeixen les URLs que pertanyen a altres hosts. El gestor de descàrregues interactua amb les llistes a partir de la interf´ıcie definida per la classe abstracta ContenidorDescarregues del projecte, d’aquesta manera es poden crear i utilitzar llistes amb comportaments diferents, és a dir, llistes que tenen implementacions diferents dels mateixos mètodes. Aix´ı doncs, en funció de l’estratègia de d’exploració que l’usuari determini, el gestor de descàrregues crearà instàncies de llistes FIFO(ContenidorDescarreguesFIFO), llistes LIFO(ContenidorDescarreguesLIFO ), o d’altres tipus. Quan l’aplicació de crawling proporciona una nova URL al gestor de descàrregues, aquest primer comprova que la URL no hagi estat enregistrada, si no ho està aleshores, l’afegeix tant al magatzem de nodes explorats(amb estat pendent i no descarregat) i a la corresponent llista de nodes pendents, en funci´ o de si es tracta d’una URL prioritària o no. Quan finalitza una descàrrega, es a dir, quan finalitza un fil d’execució de desc` arrega, aleshores el gestor extreu la seg¨ uent URL de la llista prioritària i inicialitza la descàrrega. Quan a la llista priorit` aria ja no queden elements, aleshores s’extreu de la llista secundària. Sempre que finalitza una descàrrega, cal canviar l’estat del node descarregat ja que aleshores el seu estat passa a ser de descarregat.

´ WEB CAP´ITOL 2. EXPLORACIO

´ important explicar que passa quan s’ha assolit el nombre màxim de Es descarregues simultànies admeses d’un host. En aquest cas pot passar que en les pròximes URLs de les llistes no hi hagi cap URL amb aquell host, o bé que n’hi hagi una o més d’una. En aquest u ´ltim cas, l’operació d’extracció de les llistes ha de proporcionar la seg¨ uent URL que té diferent host, i a més a més, es segueixin satisfent les condicions de màxim nombre de descàrregues simultànies per host en el host de la URL a extreure. Aquesta situació provoca una operació for¸ca costosa, ja que cal recòrrer a la llista fins trobar la URL ideal, i en el pitjor dels casos pot passar que cap URL satisfaci les condicions o bé que aquesta es trobi al final de la llista. La solució a aquest problema seria implementar i usar llistes i iteradors de llista capa¸cos de fer recorreguts per grup dins d’aquesta, amb uns costos computacionalment acceptables. La mecànica d’aquesta estructura es for¸ca simple, tot i que resulta determinant alhora de generar exploracions de qualitat. Les insersions que es fan a les llistes són molt importants, ja que l’exploració no serà la mateixa si s’afegeixen les URLs al final de la llista, al principi o seguint una estratègia determinada. De fet, si el nostre objectiu és descarregar tots els documents web d’un host, un conjunt de hosts, o d’una regió concreta, aleshores no té molta importància la manera d’explorar. Però si el nostre interés és realitzar una exploraci´ o massiva d’una regió que desconeixem, aleshores pot ser interessant usar un mètode o un altre, ja que si en algun moment cal aturar l’exploraci´ o manualment, aleshores disposarem al disc dels nodes que més ens interessen. No només és important en aquest sentit, sinó que també és important saber que hi ha estratègies que no són gaire bones, però que en canvi consumeixen menys recursos, com es el cas d’una exploració per fond` aria que requereix menys quantitat de memòria que una exploració per amplada.

2.2.3

Comunicaci´ o entre el web crawler i un servidor

Les descàrregues de fitxers dels servidors web es fan a travès dels fils d’execució de descàrrega. En funció del mètode que cal emprar s’utilitza un procediment de desc` arrega o un altre, és per això que s’han implementat tres tipus diferents de fils d’execució: ThreadDescarregadorUrl, ThreadDescarregadorUrlPost i ThreadDescarregadorUrlAmbCookies. Els fitxers es descarreguen seguint el protocol HTTP convencional, tanmateix l’´ us d’aquest protocol varia si cal explorar una àrea p´ ublica o una de privada. Les desc` arregues en àrees p´ ubliques es fan utilitzant els procediments convencionals de descàrrega de Java del paquet java.net. En aquest cas es solicita el contingut del fitxer a descarregar utilitzant el mètode GET

´ WEB CAP´ITOL 2. EXPLORACIO

a la cap¸calera HTTP de solicitud. Les descàrregues de fitxers en àrees privades o restringides cal fer-les d’una altra manera. El primer fitxer que cal descarregar és el que correspon a la URL on cal enviar el formulari d’identificació (formulari d’accés), aquesta URL és la URL d’acció. Per a aquest primer fitxer cal utilitzar el mètode POST a la cap¸calera HTTP de solicitud i, a més a més, en aquesta cap¸calera s’hi inclouen les dades del formulari d’accés, on hi ha el login i la contrasenya. El servidor respon enviant el codi HTML de la pàgina web d’inici de l’` area restringida. A partir d’aquest punt, la resta de fitxers es descarreguen aplicant el mètode GET. Tots aquests passos es fan tenint en compte l’´ us de les cookies, i s’implementen utilitzant la llibreria HTTPClient. Un altre aspecte a tenir en compte és la possibilitat de produir-se errors o situacions anòmales. En aquest sentit cal mencionar el fet que el fitxer a descarregar no existeixi al servidor, el servidor estigui saturat i no respongui, o que la connexi´ o establerta es perdi, entre molts altres casos. Tots aquests casos son notificats, en Java, en forma d’excepcions, de manera que cada incidència està associada a un tipus d’excepció concret. Quan es produeix una excepci´ o en un fil d’execuci´ o de descàrrega aquesta es captura i es notifica al Logger o gestor de d’incidèndies de l’aplicació. El logger està implementat amb la classe Logger (Logger.java) del projecte, i s’encarrega principalment de generar informació estad´ıstica.

2.2.4

Extracci´ o d’hipervincles

Els hipervincles s’extreuen u ńicament d’aquells documents que tenen contingut hipertextual, és a dir, documents amb format HTML, ja siguin estàtics o generats dinàmicament pels servidors web. El salt d’un document a un altre es fa per mitj` a dels hipervincles dels documents origen, que contenen les direccions dels documents dest´ı. Existeixen altres tipus de documents que disposen de formats amb caracter´ıstiques similars als documents purament hipertextuals, com ara, documents PDF o documents de Microsoft Word que, a més a més, de presentar referències creuades dins del propi document, poden tenir referències a altres documents de la xarxa per mitjà d’adreces URL. El web crawler implementat només extreu els hipervincles dels documents amb contingut HTML. Els hipervincles són representats usant adreces URL, per mitjà de les quals els clients web saben com i on han d’establir una connexió abans d’iniciar una desc` arrega d’un document. Les adreces URL constitueixen la unitat natural de treball del web crawler i són representades per una cadena de caràcters dividida en diferents parts. No totes les parts d’una URL s’han

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.10: Parts d’una URL d’indicar necessàriament, ja que per exemple, tot protocol reconegut segons els estàndars, té associat almenys un port per defecte, i per tant, no fa falta indicar el port, si no és que sigui estrictament necessari. • Protocol: Es troba a l’inici de l’adre¸ca URL i determina el protocol de nivell d’aplicació que caldrà usar per descarregar el fitxer web. Ha de ser un protocol de l’Internet Official Protocol Standards. • Usuari: Determina el nom d’usuari suposant que l’accés al fitxer requereixi una autorització prèvia. Es basa en el mecanisme estàndard d’autentificació en el qual s’envia un nom d’usuari(login) i una contrasenya. • Contrasenya: Determina la contrasenya d’accés si s’ha inserit un nom d’usuari a la URL. • Host(domini): Especifica el nom de la màquina on hi ha emmagatzemat el fitxer. Aquesta part és usada per identificar el tipus de màquina i on està localitzada a Internet. Per a cada nom de host desconegut cal realitzar el procés de resolució de DNS, d’aquesta manera s’obté primer l’adre¸ca IP de la màquina i després s’estableix la connexió mitjan¸cant aquesta adre¸ca. • Port: Determina el port remot on s’efectuarà la connexió. Normalment el port ve determinat pel tipus de protocol que s’utilitzi, de manera que cada protocol té associat almenys un port. Aquesta part de la URL no és necess` aria si no és estrictament necessària. • Ruta: Especifica la ruta i el nom de fitxer que es pretén obtenir del ´ exactament igual que especificar la ruta i el nom de fitxer en host. Es el sistema de fitxers d’una unitat de disc. • Consulta: S’utilitza per realitzar consultes determinades en el servi´ el procediment alternatiu dor web a través de la pàgina indicada. Es

´ WEB CAP´ITOL 2. EXPLORACIO

a l’´ us dels formularis web. Les consultes per mitjà de la URL s’acostumen a utilitzar en servidors amb comportaments dinàmics. Normalment les consultes són composades a la URL de forma automàtica per mitja dels clients web. Els hipervincles no tenen efecte visual sobre els documents, és a dir, no formen part del text en pla. Tanmateix, un fragment visible del document pot tenir associat un hipervincle que conté la URL d’un altre document del mateix host o d’un altre de diferent. Es tracta de processar el codi HTML de cada document, de manera que s’extreuen les URLs emmarcades per les marques href="..." i src="...". Cal tenir en compte que hi ha pàgines web que poden tenir algun sistema de redireccionament automàtic, com és el cas d’algunes pàgines web que han estat mogudes cap a altres llocs de la Web. Per resoldre aquests casos, cal comprovar sempre la presència del meta-tag de redireccionament <meta http-equiv="refresh"...> a cada pàgina web, i extreure’n la URL de dest´ı en cas que existeixi redireccionament. L’extracció d’hipervincles és una de les tasques més lentes, ja que cal recórrer tot el codi per a cada document HTML descarregat i aplicar les corresponents tècniques de filtratge. Cal tenir en compte que la validesa del codi de cada document és totalment imprevisible, la qual cosa comporta dos possibles alternatives: Intentar arreglar el codi HTML del document i després extreure’n els hipervincles, o bé simplement extreure els hipervincles fins que es detecti un possible error en el codi. Com que la primera opció és molt costosa computacionalment i els interessos principals són descarregar el major nombre de documents en el menor temps possible, el web crawler proposat es decanta per la segona alternativa. El procés d’extracci´ o dels hipervincles dels documents es fa utilitzant les eines proporcionades per les llibreries de classes JTidy i IR-Webutils. El primer és utilitzat per al processat de les cap¸caleres de meta-tags mitjan¸cant una anàlisi lèxica i sint` actica del document HTML, i el segon filtra el cos del codi HTML per tal de generar la llista d’hipervincles. Cal tenir en compte que un hipervincle no només pot ser un enlla¸c cap a un altre document, sinó que també pot ser un enlla¸c cap a una part concreta del mateix document.

2.2.5

Esquema general del web crawler

La figura 2.11 mostra l’esquema general del web crawler. Representa gr`aficament el transcurs normal que segueix una exploraci´o, des de que es passa la URL inicial, fins que s’extreuen els hipervincles dels documents HTML descarregats i s’encuen a la cua de nodes pendents de descarregar. Es tracta d’una repre-

´ WEB CAP´ITOL 2. EXPLORACIO

sentaci´ o molt general del funcionament del programa, ja que no reflexa, per exemple, el tema dels fils d’execuci´o explicats en detall en apartats anteriors.

2.3

Anomalies que afecten a l’exploraci´ o

En aquest apartat, es pretèn explicar breument els problemes més habituals amb que acostuma a trobar-se una aplicació de web crawling mentre efectua una exploraci´ o web. Són situacions anòmales que cal tenir en compte i, per tant, preveure durant l’exploració, ja que poden perjudicar els resultats o el rendiment de l’aplicació. Els aspectes més destacats són problemes derivats del mal funcionament de la xarxa, u ´s massiu del protocol de resoluci´ o de noms DNS, implementacions defectuoses del protocol HTTP, males codificacions de codi HTML, i problemes derivats dels continguts de les pàgines web.

2.3.1

Problemes derivats de la xarxa

Un dels reptes més importants de la exploració web recau en com descarregar pàgines web des de m´ ultiples fluxos d’informació, de la manera més uniforme possible, considerant que els temps de resposta dels servidors web són notablement variables. No es pot predir el temps de vida d’un servidor web ja que habitualment, es poden trobar servidors que resten inactius durant llargs per´ıodes de temps i més tard tornen a ser reactivats. Un web crawler comprensiu hauria de considerar que aquelles pàgines que en un determinat moment no estan disponibles, en un futur pot ser que si ho estiguin. Una recomanació per aquest problema seria que el web crawler reintenti explorar cada pàgina web un determinat nombre de vegades, mentre la pàgina resta fora de servei. Aquest intèrval de temps acostuma a ser de 13 hores en un màxim de 3 intents. Els web crawlers normalment generen falses alarmes als administradors de pàgines web, aix` o es degut al gran ample de banda que utilitzen quan exploren un servidor web. Accessos reiterats a una pàgina web sovint activen falses alarmes en el servidor. Algunes guies recomanen que els web crawlers s’identifiquin davant dels servidors web, mitjan¸cant la cap¸calera User-Agent HTTP, proporcionant almenys una adre¸ca de correu de contacte. També es recomana que entre accés i accés a un servidor web, el web crawler s’esperi un temps. Un altre problema relacionat amb la xarxa es produeix quan el sevidor web amb el qual s’ha establert connexió TCP a través del port 80, no respon. ´ a dir, l’operació connect() i send() conclouen amb èxit, però en canvi el Es servidor no envia informació de resposta. Aquesta classe de problemes són producte d’un firewall mal configurat que bloqueja el tràfic de sortida en el host remot. La conclusi´ o que s’extreu d’aqu´ı és que totes les operacions

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.11: Esquema general del web crawler

´ WEB CAP´ITOL 2. EXPLORACIO

han de tenir un timeout. El web crawler ha d’estar preparat per ser capa¸c d’avortar qualsevol operació de xarxa en qualsevol moment, ja que cada descàrrega activa pot deixar de rebre informació sense previ av´ıs del servidor web.

2.3.2

Resoluci´ o massiva de DNS

La resolució massiva de DNS acostuma a desencadenar problemes en els servidors locals de DNS de la xarxa on es troba el web crawler. Els servidors de DNS local encuen o deneguen connexions provocades per intents de resolució massiu de DNS. Aquest problema provoca que no es pugui resoldre la IP d’alguns servidors web i arribar a la falsa conclusió que el servidor està fora de servei o simplement no existeix. Una solució consisteix en testejar els servidors de DNS davant de jocs de proves cr´ıtics. Sovint el problema no és degut al servidor de DNS local, sinó que es causat per problemes amb el servidor de DNS remot. Alguns administradors acostumen a instal·lar en una mateixa màquina f´ısica, tant el servidor de pàgines web, com el servidor de DNS. En aquests casos, quan el servidor de DNS falla, el problema no es soluciona durant un llarg per´ıode de temps. Un altre cas curiós que cal tenir en compte és l’´ us del prefix www a la part del host de les URLs. En moltes pàgines web, tant www.domini.net com domini.net, resolen la mateixa adre¸ca IP, i per tant, tenen els mateixos continguts. Alguns administradors de pàgines web posen el prefix en els hipervincles de les pàgines web, mentre que n’hi ha d’altres que no ho fan. L’´ unica solució a aquest problema és considerar que tant www.domini.net com domini.net són la mateixa URL, o bé realitzant una comprovació individual per comprovar que ambdós pàgines web són duplicats o no.

2.3.3

Implementacions HTTP

En alguns casos, és impossible conèixer el tipus de document web a partir de l’extensi´ o de fitxer de la URL. Algunes URLs no tenen extensió i algunes altres tenen extensions ambig¨ ues. Per exemple, alguns fitxers que acaben en .exe en realitat són pagines web amb contingut HTML, ja que són pàgines creades dinàmicament pel servidor. Alguns clients o agents web, com es el cas de web browsers o web crawlers, treballen u ńicament amb alguns formats de document web concrets. El web crawler implementat només treballa amb documents HTML, PDF, TXT, DOC, RTF i alguns documents HTML creats dinàmicament pels servidors. La cap¸calera del protocol HTTP proporciona un camp per indicar el tipus de contingut del document web a descarregar: GET /pagina.html HTTP/1.1 Accept: text/plain, text/html

´ WEB CAP´ITOL 2. EXPLORACIO

Això indica que el web crawler u ńicament pot tractar amb text pla o documents HTML. Les cap¸caleres de resposta HTTP dels servidors web també proporcionen el camp Content-type que indica el tipus de document que s’està procedint a descarregar, tanmateix aquest camp no és obligatori, i per tant no existeix un cam´ı del tot fiable per esbrinar amb anticipació el tipus de contingut dels documents web que es descarreguen. Acordant a l’especificació HTTP, el servidor hauria d’enviar un codi de resposta 406(no acceptable) quan un document web del tipus especificat en l’operació GET no està present en el servidor de la URL donada. Alguns web browsers simplement omplen la cap¸calera amb el contingut Accept: */*, per tant, alguns servidors web ni tan sols comproven la presència del camp Accept. Aquest fet, d’alguna manera ha perdut importància amb el temps, i per tant, ara mateix qualsevol servidor web pot enviar un document web de qualsevol tipus. Per assegurar una bona cobertura de la Web, cal limitar la quantitat d’informació que es descarrega durant una descàrrega desde qualsevol servidor web. Això es pot aconseguir limitant el tamany màxim de la pàgina, i el n´ umero de pàgines web que són descarregades des de un servidor. Normalment, es limita el tamany màxim d’un document web entre 300 i 400KB, encara que el tamany màxim a descarregar en el web crawler implementat es de 5MB. Es considera que aquests tamanys són suficients per capturar les paraules claus necess` aries per indexar el document. Per informar el servidor web del tamany l´ımit cal usar el camp HTTP Range de la cap¸calera HTTP al moment de fer el GET. GET /pagina.html HTTP/1.1 Range: 0-400000 En alguns casos, els servidors web retornen el codi de resposta 416 (error de rang). Aquesta resposta succeeix quan els documents web tenen un tamany inferior al que s’ha indicat en el rang. Aquest tipus de resposta no és correcta ja que l’especificació del protocol indica que si el segon valor es major o igual al tamany del document, aleshores simplement es descarrega el document fins al seu tamany. Es tracta d’un mal u ´s del protocol HTTP en els servidors web. En el cas que sorgeixin errors de rang en les respostes, cal realitzar un segon intent de descàrrega, però en aquest cas no s’ha d’usar el camp Range a la cap¸calera. En tot cas, un servidor pot ignorar el camp de rang, per tant el web crawler ha d’estar preparat per desconnectar-se del servidor, o descartar part dels continguts del document web si el servidor envia més informació de l’admesa. Aquests casos explicats posen de manifest la presència de pàgines web amb cap¸caleres HTTP de retorn ambig¨ ues o incorrectes. Però existeixen casos en què els servidors web envien documents web sense la corresponent

´ WEB CAP´ITOL 2. EXPLORACIO

cap¸calera HTTP. Alguns clients web toleren aquesta classe de comportaments, mentre que d’altres no, i ho indiquen mitjan¸cant missatges d’error. Aquests casos puntuals normalment són conseq¨ uència de software o firewalls mal configurats. El web crawler ha d’estar preparat per rebre contingut sense cap¸caleres. Un cas similar es produeix quan s’envien documents amb cap¸caleres incomplertes, com ara, una resposta indicant un redireccionament cap a una altra URL, però la URL no està indicada. No hi ha una solució concreta per aquest problema, i per tant, la millor solució és no descarregar el document i tancar la connexió. ´ dif´ıcil constru¨ır un lloc web sense hipervincles interns trencats, és a Es dir, que contenen URLs amb destinacions inexistents. El codi de retorn d’un document web que no existeix dins d’un servidor web és el 404, mitjan¸cant el qual els clients web saben que aquell document no existeix. Tanmateix, els administradors web tenen tendència a fer que enlloc de retornar un missatge amb codi 404, es retorni una pàgina web concreta del servidor quan no existeix el document sol·licitat. El problema recau quan el web crawler considera que aquella pàgina és vàlida, encara que en realitat la pàgina no existeix. Una solució a aquest problema consisteix en que els administradors de servidors web indiquin d’alguna manera o altra els codis de resposta reals, indicant exactament els motius de l’error. Una part important dels ordinadors són configurats amb una data, hora o zona horària incorrecta. En aquests casos, no és possible esbrinar les dates reals de modificaci´ o o per´ıodes d’actualització de les p` agines web, tanmateix, no totes les dates han de sér descartades. Si un servidor web respon amb una marca de temps futura, però amb pocs minuts o hores de diferència respecte l’hora real, es pot considerar que el rellotge del servidor probablement està desfa¸cat, per exemple, té la zona horària incorrecta o està mal configurada. Es pot considerar que si l’´ ultima data de modificació d’una pàgina web és anterior a l’any 1993, aleshores aquella data és incorrecta. Per dates futures, una possible heur´ıstica consisteix en veure si no supera les 24 hores de diferència respecte l’hora actual, en aquest cas s’ha de canviar a la data actual. Si la data és superior a 24 hores, aleshores cal ignorar-la.

2.3.4

Codificaci´ o HTML

La tendència natural dels programadors de pàgines web és donar per vàlida una pàgina web quan aquesta es visualitza correctament en un client web. Tot i que una pàgina web es visualitzi correctament en un browser, no significa que el codi HTML de la pàgina sigui també correcte. Existeixen nombrosos errors de codificació en moltes pàgines web, i en alguns casos perjudiquen el web crawler. Alguns d’aquests errors són els que es mostren a continuació:

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.12: Mapa de temps • Combinar l’´ us de les doble cometes, cometes simples, o sense cometes. Per exemple: <IMG ALT="Text de la imatge"SRC=’imatge.jpg’ border=3> • Combinar marques en la forma HTML i en la forma XHTML. Per exemple: <BR> i <BR/> • Creuar entorns. Per exemple: <SMALL><B>Text</SMALL></B> • Combinar l’´ us de maj´ uscules i min´ uscules en les marques. Per exemple: <IMG src="text". En HTML, les marques s’han de posar en maj´ uscules, mentre que en XHTML en min´ uscula. • Cadenes sense final. Per exemple: <IMG ALT="...>. Aquesta situació és molt problem` atica ja que pot causar un desbordament de buffer si l’analitzador no es capa¸c de tractar-ho. Una manera de resoldre aquests casos es utilitzar un analitzador HTML orientat a events, ja que en molts casos no seria possible mapejar la pàgina ´ necessari que els administradors web utilitzin eines web en forma d’arbre. Es de correcció de codi HTML en les seves pàgines web.

2.3.5

Caracter´ıstiques dels continguts web

L’existència de rèpliques exactes de documents web és elevada a Internet. Detectar-ho no és f` acil, almenys abans de descarregar el document ja que cal verificar que el contingut descarregat coincideixi amb algun altre descarregat anteriorment. Detectar rèpliques pot resultar important, ja que d’aquesta manera no cal indexar documents idèntics. Una manera de detectar rèpliques consisteix en guardar el resultat d’aplicar una funci´ o de hash sobre cada document web descarregat, de manera que dos documents amb resums de hash idèntics són documents iguals. La funció de hash cal aplicar-la just després d’aplicar el filtratge de continguts

´ WEB CAP´ITOL 2. EXPLORACIO

HTML, de manera que dos documents amb estils diferènts, però amb continguts iguals es consideraran rèpliques. Aquest mètode evita emmagatzemar pagines iguals al disc, però no evita haver-les de descarregar. Un altre aspecte important a tenir en compte són les llistes de blogs, llistes de correu o f` orums de debat. Es tracta de grans repositoris d’informació, formats per petites aportacions d’individus. Aquests poden ser una font u ´til d’informació quan el tema que tracten no es pot trobar en cap altre lloc de la Web. Un t´ıpic exemple són els missatges de suport tècnic, que normalment descriuen solucions a problemes amb condicions i configuracions espec´ıfiques de software o hardware. Tanmateix, sovint les aportacions que es fan no són avaluables en comparació a altres pàgines, ja que tenen un contingut molt curt o bé són poc clars. El problema recau amb la granularitat de la informació, per exemple, una petita aportació conté poca informació, però en canvi, la conversa completa pot ser avaluable. A més a més, recentment els spammers estan comen¸cant a utilitzar els blogs per penjar hipervincles cap a les seves pàgines web de manera automàtica. Una solució a aquest problema és afegir el tag rel="nofollow", per tal d’indicar als web crawlers que el link no s’ha d’explorar.

2.3.6

P` agines web din` amiques

Alguns servidors web tenen comportament dinàmic, mitjan¸cant el qual generen pàgines web amb continguts espec´ıfics sota demanda. Una manera de tractar amb els diferents usuaris que es connecten al servidor és generar i afegir identificadors a les URLs, per exemple www.domini.net/web/index.html?jsessid=34E67235. Aquests identificadors, més tard, són usats per detectar sessions. Des del punt de vista d’un web crawler, l’´ us d’identificadors de sessió suposa retrobarse amb el problema de continguts duplicats. Els noms t´ıpics de variables utilitzades per a emmagatzemar identificadors de sessió són: CFID, CFTOKEN, PHPSESSID, JSESSIONID, etc. Aquestes variables són sovint utilitzades pels servidors web dinàmics i dos documents web que només difereixen en l’identificador de sessi´ o tenen tota la pinta de rèpliques. Una manera per evitar això és composar i utilitzar una llista d’identificadors de variable coneguts de forma manual, de manera que quan el web crawler detecti un d’aquests identificadors en posi el valor a null. Un error habitual al moment de codificar els hipervincles es oblidar-se de posar el directori arrel, per exemple: a/b/c quan en realitat es vol fer referència a /a/b/c. També és habitual trobar URLs amb subdirectoris que es repeteixen vàries vegades, com ara a/b/c/c/c/c/. Això és degut a les pàgines dinàmiques en les quals l’autor, per error, n’ha creat un enlla¸c relatiu quan en realitat hauria de sér l’enlla¸c absolut.

´ WEB CAP´ITOL 2. EXPLORACIO

Les pàgines web generades dinàmicament són, en general, lentes de transferir en comparaci´ o amb les pàgines web estàtiques, concretament acostumen a ser més lentes en un factor de 10 o 100, en funció de les implementacions i dels sistemes de caché emprats en el servidor web. En alguns casos, aix` o és degut a que la construcci´ o de la pàgina web requereix consultar diferents fonts d’informació, i en altres casos això pot ser degut a errors de programació. Una pàgina lenta pot malgastar recursos del web crawler for¸cant a aquest a mantenir connexions actives durant un llarg periode de temps. Es per aquest motiu que cal utilitzar sempre l’´ us de timeouts, o redu¨ır l’ample de banda destinat a aquestes connexions.

2.4

Par` ametres i configuracions

En aquest apartat s’expliquen els paràmetres de l’aplicació que es poden modificar per tal de configurar adientment les exploracions. El transcurs d’una exploraci´ o pot variar en funció dels seus paràmetres inicials. En aquest sentit hi intervenen aspectes importants com són la profunditat d’exploració, el nombre màxim de descàrregues simultànies, els tipus d’extensions dels fitxers que volem explorar, quins dominis explorar i quins no, si volem, o no, explorar els hipervincles amb destinacions externes al host inicial, etc. Exploraci´ o d’una ` area p´ ublica Consisteix en explorar els nodes web d’una regió p´ ublica d’una internet o LAN, en aquest sentit cal determinar una URL inicial dins d’aquesta àrea p´ ublica on s’efectuarà l’exploració. Exploraci´ o d’una ` area restringida Consisteix en explorar els nodes web d’una regió restringida d’una internet o LAN, en aquest sentit cal indicar un formulari d’accés omplert prèviament de forma manual mitjan¸cant l’eina d’Auto-LogIn de l’aplicació. En aquest formulari emmagatzemat al disc i consta, a part dels correponents camps del formulari i els seus valors, la URL on cal enviar el formulari mitjan¸cant el procediment POST, i que per tant serà la URL d’inici de l’exploració restringida. Cal emprar aquest tipus d’exploració si es desitja, per exemple, explorar un compte de webmail privat. Profunditat d’exploraci´ o Determina el l´ımit de l’exploració en termes de fond` aria, és a dir, els nodes que es troben a una fondària superior al l´ımit no s’exploren (no es posen a la cua de nodes pendents d’explorar). La fond` aria es mesura numèricament, de manera que la fondària d’un node és la distància en enlla¸cos desde el node inicial fins a aquest, es a dir, és el nombre d’enlla¸cos que cal recòrrer des de el node inicial fins a arribar al node. El node inicial sempre es troba a la fondària zero, per tant, una exploració

´ WEB CAP´ITOL 2. EXPLORACIO

limitada a una fond` aria zero només exploraria el node inicial. Aquest paràmetre cal usar-lo amb un cert grau de precaució, ja que si habilitem la possibilitat d’explorar hosts externs i, a més a més, indiquem un profunditat l´ımit molt elevada, ens podrem trobar que en determinats moments de l’exploraci´ o s’exploren nodes que no són del nostre interès. Desc` arregues simult` anies Determina el nombre màxim de descàrregues simultànies que efectuar` a l’aplicació en cada moment durant el transcurs de l’exploraci´ o. Tal i com s’ha explicat en apartats anteriors, cada descàrrega ´ important saber s’efectua mitjan¸cant fils d’execució concurrents de Java. Es aplicar correctament aquest paràmetre, ja que és molt important aprofitar tot l’ample de banda que ens ofereix la nostra connexió. Tanmateix, també cal recordar els problemes de xarxa explicats a l’apartat d’anomalies i tot el que comporta efectuar m´ ultiples descàrregues massives. Desc` arregues simult` anies per host Determina el nombre màxim de descàrregues que s’efectuaran simultàniament sobre un mateix host o sub´ a dir, limita el nombre de connexións que host (domini o subdomini). Es s’estableixen sobre cada host de manera simultània. Aquest aspecte també és molt important, i pot determinar, en part, l’èxit d’una exploració. Limitar el nombre de connexions sobre un servidor web té un seguit de justificacions. El primer motiu és evitar saturar les connexions dels servidors web, ja que el nostre ample de banda i el nostre equipament poden soportar-ho, però els servidors web remots no. El segon motiu es evitar que els servidors web ens deneguin les connexions, ja que poden considerar que les descàrregues del nostre web crawler són un intent d’atac. La tendència natural dels servidors web és admetre poques connexions procedents d’una mateixa adre¸ca IP d’origen. Si s’usa un valor elevat es refusaran moltes connexions, i per tant, fallaran moltes descàrregues durant ´ important remarcar que el seu valor no pot ser superior al l’exploraci´ o. Es nombre de descàrregues simultànies explicat al paràgraf anterior. Explorar enlla¸ cos externs Determina si s’exploraran aquells nodes que tenen el host diferent del host del node inicial. En aquest sentit, les URLs que tenen per host subhosts(subdominis) del host inicial també es consideren externes. Aquest paràmetre és u ´til si volem explorar u ńicament nodes que pertanyen exclusivament al host inicial. Explorar hosts del domini Aquest paràmetre complementa l’explicat en el paràgraf anterior. Aquest paràmetre només es té en compte si no es desitja explorar enlla¸cos externs. Activant aquest paràmetre s’exploraran

´ WEB CAP´ITOL 2. EXPLORACIO

subhosts(subdominis) que tenen per arrel el host(domini) del node inicial, de manera que far` a possible una exploració de tot un domini i els seus corresponents subdominis, si en té. Donar prioritat al host inicial Aquest paràmetre també complementa el paràmetre d’explorar enlla¸cos externs, però en aquest cas només es té en compte si es desitja explorar enlla¸cos externs. Si es desitja explorar enlla¸cos externs ens podem trobar que a vegades s’exploren primer nodes que pertanyen a hosts molt allunyats(poc relacionats) del host del node inicial. En la majoria de casos això no interessa, ja que ens sol interessar principalment els nodes que pertanyen al host inicial a diferència de la resta. Si s’activa aquest paràmetre, aleshores entra en funcionament el sistema de prioritats explicat anteriorment, de manera que els nodes que pertanyen al host o subhosts del host del node inicial, s’afegeixen a la cua de prioritaris, mentre que la resta s’afegeixen a la cua de secundaris. Sempre explorar el seg¨ uent disponible Aquest paràmetre es podria obviar ja que sempre hauria d’estar activat, tanmateix pot resultar interessant tenir-lo desactivat en alguns casos molt puntuals. Si limitem el nombre de descàrregues simultànies per host, ens trobarem que s’efectuen descàrregies simultànies sobre hosts diferents, ja que el web crawler sempre intentarà efectuar tantes descàrregues com les que s’hagin indicat. Per tant, quan sobre un host ja s’assoleix el l´ımit de descàrregues, cal localitzar dins de la cua de descàrregues pendents un altre node(URL) amb un host o subhost diferent per iniciar-ne la descàrrega. Aquest u ´ltim procés només s’efectuarà si tenim activat el paràmetre d’explorar el seg¨ uent disponible. Tenir desactivat aquest paràmetre pot ser u ´til si volem prioritat absoluta en descarregar primer els nodes que pertànyen al host inicial, ja que mai es provarà de descarregar un node d’un altre host fins que no en quedin del host inicial. Cerca Breadth-First Determina que s’emprarà una exploració amb estratègia Breadth-First. Consisteix en fer un u ´s FIFO de la cua de nodes pendents de descarregar. Aquesta estratègia s’explica en detall, a l’apartat d’estratègies d’exploració. Cerca Depth-First Determina que s’emprarà una exploració amb estratègia Depth-First. Consisteix en fer un u ´s LIFO de la cua de nodes pendents de descarregar. Aquesta estratègia s’explica en detall, a l’apartat d’estratègies d’exploració. Dominis explorables Representa el conjunt de dominis base d’Internet (.net, .org, .edu, etc.) que seran explorats si apareixen hipervincles cap

´ WEB CAP´ITOL 2. EXPLORACIO

a hosts allotjats en aquests dominis. Per tant, les URLs allotjades en els dominis que no pertanyen al grup no seran explorades. Extensions explorables Representa el conjunt d’extensions de document que seran explorades. En aquest sentit, els documents amb extensions no escollides no seran explorats. Els documents amb extensions no reconegudes(i per tant, ”vàlides”) són sempre explorats. Els documents amb extensions no vàlides són aquells que tenen alguna de les seg¨ uents extensions: .gif, .jpg, .ppt, .bmp, .png, .zip, .gz , .ps, .rar, .ace, .mid, .wav, .mp3, .mp2, .exe, .tar, .avi, .mpg, .mpeg, .mov, .swf, .bin i .ram. Es tracta d’extensions de fitxers que aparèixen freq¨ uentment a les pàgines web d’Internet i que han de ser descartades ja que no tenen contingut textual u ´til. Les extensions reconegudes, i que per tant tenen contingut textual que pot ser extret i indexat són les seg¨ uents: .asp, .cfm, .htm, .html, .jsp, .php, .php3, .phml, .pl, .shml, .pml, .chtml, .aspx, .js, .pdf, .doc, .txt i .rtf. Les extensions sense contingut HTML són les seg¨ uents: .pdf, .doc, .rtf i .txt.

2.5

Estrat` egies d’exploraci´ o

En aquest apartat, s’expliquen les diferents estratègies d’exploració que es poden utilitzar en aquest web crawler. Una estratègia d’exploració ve determinada bàsicament per la manera en què s’insereixen les URLs a la llista de nodes pendents d’explorar. Aix´ı doncs, ens pot interessar explorar primer un determinat tipus de documents, i deixar pel final aquells que no ens interessen tant. Les estratègies només tenen sentit quan cal fer exploracions massives a gran escala, ja que si només volem descarregar un conjunt concret de pàgines web, aleshores no importa l’ordre en què ho fem. La problemàtica que tenen les exploracions a gran escala, com les que fan els grans motor de cerca d’Internet, és que cal explorar una enorme quantitat de documents web. Aquestes exploracions no acaben mai, ja que no tenen uns l´ımits establerts i a més a més, han de reexplorar documents que s’actualitzen periòdicament. En aquests casos, cal explorar sempre els nodes més importants i descartar o deixar pel final la resta. Cada motor de cerca utilitza una sèrie de criteris per determinar si una pàgina és més bona que una altra i en aquest sentit, hi tenen molt a veure les estratègies d’exploració que s’utilitzin. En el web crawler implementat d’aquest projecte, s’han desenvolupat vàries estratègies d’exploració, algunes de les quals són les seg¨ uents: estratègia Breadth-First, Depth-First, Backlink-Count, Batch-Pagerank i Largersites-first. Cada estratègia d’exploració té una sèrie de caracter´ıstiques que la fan diferent de les altres, ja que per exemple, algunes utilitzen un menor

´ WEB CAP´ITOL 2. EXPLORACIO

consum dels recursos, però en canvi exploren amb igual preferència els nodes ´ important deixar clar en aquest punt, menys profunds i els més profunds. Es que la fond` aria d’un node és el nombre d’enlla¸cos que cal recòrrer per arribar fins a ell des de el node inicial. Abans d’iniciar una exploració cal configurar-la en funci´ o de les nostres necessitats.

2.5.1

Breadth-First

´ el tipus d’exploració que utilitzen pràcticament la gran majoria de motors Es de cerca d’Internet. Consisteix en que l’estructura de nodes pendents d’explorar és una cua, és a dir, és una estructura de dades amb una estratègia de moviments FIFO (el primer que entra és el primer que surt). En una cua, l’operació d’inserir consisteix en afegir un element a la fi d’aquest, mentre que la d’eliminar es fa sobre el primer element present a la cua (el que va ser inserit fa més temps). La cua modela un arbre, i quan es van inserint URLs, tendeix a crèixer en amplada i no en fond` aria, de manera que cada nivell de l’arbre representa un nivell de profunditat de l’exploració. Quan tots els nodes d’un nivell són explorats, es procedeix a l’eploració del seg¨ uent nivell i per tant, augmenta en una unitat la fond` aria de l’arbre. L’avantatge d’aquest sistema és que en cada moment sempre s’exploren els nodes menys profunds, és a dir, els nodes més pròxims al node inicial, deixant pel final aquells que són més profunds, i per tant, tenen menys valor. Es tracta d’una exploraci´ o completa ja que la profunditat és finita. Té la peculiaritat que els primers nodes són sempre els primers en ser explorats, la qual cosa vol dir que els nodes repetits sempre es detecten en profunditats més elevades. Aquesta caracter´ıstica no te cap rellevància amb el funcionament de l’algorisme Breadth-First, tanmateix la seva mancan¸ca és un problema en l’algorisme Depth-First tal i com s’explicarà en el seg¨ uent ´ important destacar el cost espaial de l’exploració Breadth-First, apartat. Es ja que té un cost molt elevat d’ordre O bd , on b és l’amplada i d la profunditat. Això és degut a que manté en memòria cada node de cada nivell de l’exploraci´ o. Per tant, cal disposar d’una gran quantitat de memòria si es pretèn realitzar una exploració de gran escala.

2.5.2

Depth-First

L’exploració Depth-First o, exploració en profunditat, consisteix en que l’estructura de nodes pendents d’explorar és una pila, és a dir, és una estructura de dades amb una estratègia de moviments LIFO (el darrer que entra és el primer que surt). Intu¨ıtivament, ens la podem imaginar com una pila de valors en la qual per treure’n un del mig, cal haver tret tots els que té al

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.13: Exemple FIFO damunt. La pila modela un arbre, tal que a mesura que es van inserint URLs, tendeix a crèixer en profunditat i no en amplada. L’algorisme explora l’arbre de branca en branca, de manera que en cada moment, sempre explora un node d’una branca fins a arribar al final d’aquesta. Quan arriba al final d’una branca, explora la seg¨ uent branca més pròxima. L’avantatge d’aquest sistema és que, en comparació amb l’exploració Breadth-First o exploració en amplada, consumeix molts menys recursos en termes d’espai. De manera similar al Breadth-First, el Depth-First també és complet, però té dos inconvenients que no el fan gaire u ´til a l’hora d’explorar. El primer d’aquests inconvenients és que no té en compte la necessitat d’explorar primer els nodes menys profunds, amb una clara tendència a donar prioritat als nodes més allunyats del node inicial, ja que les primeres subbranques en ser explorades sempre són les més pròximes a les fulles de l’arbre. El segon inconvenient fa referència al tema dels nodes repetits que s’havia comentat a l’apartat anterior. Consisteix en que l’algorisme no pot esbrinar mai si el node que està explorant en cada moment s’el trobar` a més endavant en una profunditat menor. Això no passa amb el Breadth-First, ja que aquest sempre sap que cada node que explora es troba en la profunditat menor possible.

´ WEB CAP´ITOL 2. EXPLORACIO

Figura 2.14: Exemple LIFO

Les conseq¨ uències d’aix` o perjudiquen seriosament l’exploració, ja que poden haver-hi molts nodes que caldrien ser explorats i al final no s’exploren. Suposem que cal explorar en profunditat una pàgina web, i que la profunditat l´ımit imposada per la configuració és de 5 nivells. Durant el transcurs de l’exploraci´ o s’arriba a un node del nivell 5 que té molts hipervincles, els quals no s’afegeixen a la pila perquè no es troben dins del l´ımit permès ja que tenen fond` aria 5+1. Més endavant, l’algorisme d’exploració detecta un hipervincle a aquest mateix node que ara es troba a una fondària de 3 nivells, aquest node ara és automàticament descartat ja que ja s’havia explorat amb anterioritat. S’observa que si l’algorisme hagués descobert primer aquest node en la fond` aria 3, s’hagués explorat tot el subarbre que arrelava aquest node. Per resoldre aquest problema, cal realitzar uns petits canvis en el funcionament de l’algorisme. Cada vegada que l’aplicació de crawling proporciona al gestor de descàrregues una URL, cal comprovar si aquesta ja ha estat explorada, i per tant descarregada anteriorment, o bé si es troba a la cua de descàrregues pendents (això es fàcilment comprovable consultant, a l’estructura de nodes explorats, si aquell node es troba en estat pendent). En el cas que ja hagi estat explorada, cal consultar la seva profunditat. Si la profunditat quan es va descarregar és superior a l’actual, caldrà explorar tots els seus hipervincles i canviar la seva antiga profunditat per la nova. En el cas que es trobi a la cua de descàrregues pendents, caldrà localitzar el node dins de la pila i fer la mateixa comprovació, és a dir, si l’anterior

´ WEB CAP´ITOL 2. EXPLORACIO

profunditat ´es superior, caldr`a actualitzar-la per la nova.

2.5.3

Backlink-Count

Aquesta és una estratègia d’exploració basada en les caracter´ıstiques de les pàgines web, concretament amb el nombre d’hipervincles. Consisteix en explorar primer, aquelles pàgines web tals que existeix un elevat nombre d’hipervincles que apunten cap a elles. Aix´ı doncs, la seg¨ uent pàgina a explorar és la més enlla¸cada des de les pàgines web anteriorment explorades. En aquest tipus d’exploració, es considera que les millors pàgines són sempre les més referenciades per les altres. Aquesta estratègia d’exploració no ha estat implementada en el web crawler desenvolupat.

2.5.4

Batch-Pagerank

Es basa en generar un valor de Pagerank a partir de pàgines explorades. El concepte de Pagerank es pot considerar com un indicador de la qualitat d’una pàgina web, vindria a sér allò que en programació genètica es coneix per fitness. En aquest sentit, interessa tenir en compte u ńicament aquelles pàgines que tenen un bon Pagerank. Aquesta estratègia calcula una estimació de Pagerank, a partir de les pàgines explorades recentment, concretament això es realitza cada K pàgines descarregades. Les seg¨ uents K pàgines web a descarregar són aquelles que tenen un Pagerank estimat més gran. Aquesta estratègia es considera millor que l’estratègia Backlink-count. Una variant del Batch-Pagerank és el Partial-Pagerank. Aquest és similar al mencionat anteriorment, però amb la diferència que entre recàlculs de Pagerank, s’assigna un Pagerank temporal a les noves pàgines web, a partir de la suma dels Pagerank de les pàgines que tenen hipervincles que apunten cap a ella, dividit pel nombre d’hipervincles de sortida d’aquestes pàgines. Ambdós estratègies no han estat implementades en el web crawler desenvolupat.

2.5.5

Larger-sites-first

Tal i com el seu nom indica, l’objectiu d’aquesta estratègia és evitar tenir massa pàgines d’un lloc web pendents de descarregar. Amb això es pretèn evitar haver de deixar pel final grans llocs web, de manera que és millor anar-los descarregant de mica en mica que de cop. El web crawler utilitza el nombre de pàgines sense explorar d’un mateix lloc web com a indicador de prioritat, i per tant, comen¸ca primer per aquells que tenen major nombre de pàgines pendents. Es considera que és millor que l’estratègia Breadth-First. Aquesta estratègia d’exploració no ha estat implementada en el web crawler desenvolupat.

´ WEB CAP´ITOL 2. EXPLORACIO

2.6

Exploracions d’` arees restringides

Una exploraci´ o en una ` area restringida consisteix en explorar un conjunt de nodes web, el contingut dels quals només està disponible si prèviament s’ha efectuat amb èxit un procés d’autorització mitjan¸cant la completació i enviament d’un formulari web. Quan un servidor web no accepta (dóna per vàlides) les dades enviades en el formulari, l’accés a la zona restringida continua essent restringit, tot i que no hi ha una forma concreta d’averiguar-ho. Existeixen diferents formes d’autentificar-se davant d’un servidor web, entre aquestes hi ha el mètode convencional implementat en el protocol HTTP, en el qual s’insereix u ńicament un login i una contrasenya. Tanmateix, la presència de formularis web amb m´ ultiples camps addicionals, generats i omplerts autom` aticament mitjan¸cant el comportament dinàmic d’alguns servidors, fa necessari emprar la metodologia POST per enviar els formularis al servidor. La idea que cal extreure de tot això és que primer cal obtenir un formulari, omplir-lo amb unes dades d’autentificació v` alides i finalment enviar-lo al servidor. Els dos primers passos d’obtenció i completació de formularis es fan mitjan¸cant l’eina d’Auto-LogIn implementada i adjunta al web crawler proposat. L’´ ultim pas del procés es fa just abans de descarregar la URL d’accés, que en aquests casos sempre serà la URL d’acció. Per a l’obtenció d’un formulari web, l’usuari ha d’indicar la URL on hi ha el formulari. L’aplicació descarrega, aplicant el procés habitual de descàrrega HTTP, el contingut HTML de la URL especificada. Com que els formularis d’autentificació no segueixen un patró concret i en una mateixa pàgina web hi poden haver varis formularis, s’extreuen tots els formularis del document. Aquest procés s’efectua aplicant una anàlisi lèxica i sintàctica del document HTML, que es realitza emprant la classe FiltreHTML (implementada a la vegada utilitzant la llibreria JTidy). De cada formulari s’extreu la URL d’acció i els seus camps i correspo´ important remarcar que hi ha camps que no tenen efecte nents valors. Es visual en els clients web ja que són de tipus hidden. Els camps hidden acostumen a ser camps omplerts automàticament pel propi servidor web i són utilitzats en llocs web dinàmics per emmagatzemar identificadors de sessi´ o i altra informació utilitzada per al correcte funcionament de la pàgina web. Aquests camps cal deixar-los intactes. La URL d’acció determina l’adre¸ca on s’ha de fer el POST del formulari. Com que en una pàgina web hi poden haver m´ ultiples formularis, l’aplicació es limita a llistar tots els formularis per pantalla, per tal que sigui el propi usuari el qui esculli quin serà el formulari que caldrà usar. Un cop l’usuari escull el formulari, l’aplicació mostra en una taula els

´ WEB CAP´ITOL 2. EXPLORACIO

camps del formulari juntament amb els respectius valors, si es que ja en tenen. Per a cada camp es mostra també el seu nom, normalment els desenvolupadors de pàgines web posen noms adequats als camps, de manera que no ha de suposar cap problema per a l’usuari identificar en quin camp cal posar el login i en quin la contrasenya. Un cop finalitzada l’edició d’un formulari, aquest s’emmagatzema al disc per al seu posterior u ´s, de manera que un formulari emmagatzemat al disc pot ser utilitzar en futures exploracions. La diferència entre una exploració normal i una que es fa en una àrea restringida, és que en la primera es descarreguen els nodes web seguint el procediment convencional de descàrrega, mentre que en el segon, el primer node que es descarrega és la resposta del servidor web després de fer el posting del formulari d’autentificació, i tots els nodes de l’exploració s’exploren tenint en compte les cookies. Per tenir en compte les cookies s’ha utilitzat la llibreria HTTPClient, que entre d’altres coses ofereix classes per a la composició i enviament de formularis web.

Cap´ıtol 3

Extracci´ o i indexaci´ o d’informaci´ o Aquesta part s’encarrega d’extreure la informació u ´til dels documents descarregats mitjan¸cant l’eina d’exploració web. Amb tota la informació que s’extreu, es crea un ´ındex que permetrà localitzar de forma ràpida en quins documents existeix una major freq¨ uència de les paraules que volguem cercar. Per a la creació dels ´ındexs s’usa la llibreria Lucene per a Java. Lucene és el que es coneix per Information Retrievaler, una llibreria escalable i d’alt rendiment per a recollir i analitzar informació.

3.1

Extracci´ o d’informaci´ o

De cada document descarregat i emmagatzemat a la Intranet durant el procés d’exploració, cal extreure’n la informació u ´til. La informació u ´til és el text en pla dels documents, de manera que cal filtrar tot allò que són marques de format, del que és text. Els tipus de documents dels quals s’extreu informació són els que tenen format HTML, PDF, RTF, TXT i DOC. D’aquests s’obté meta-informació addicional, com són el t´ıtol del document, el nom del seu autor, la seva descripci´ o o resum, i les paraules clau. La meta-informació que s’extreu es tracta d’informació que contenen tots els tipus de documents indicats, excepte en el cas dels fitxers TXT que no tenen cap meta de meta-informació. Per a extreure aquesta informació s’han utilitzat paquets i llibreries espec´ıfiques per al tractament d’aquests formats: JTidy per als documents HTML, PDFBox per als documents PDF, javax.swing.text.rtf per als documents RTF, POI per als documents de Microsoft Word, i per als documents TXT s’utilitzen els procediments convencionals de Java per a la lectura de fixers de text. S’han implementat un conjunt de filtres per a cada format. Aix´ı doncs, 42

´ I INDEXACIO ´ D’INFORMACIO ´ CAP´ITOL 3. EXTRACCIO

s’ha utilitzat el polimorfisme que ofereix Java per a filtrar els documents mitjan¸cant les classes FiltreHTML, FiltrePDF, FiltreRTF, FiltreDOC i FiltreTXT, totes elles són subclasses de la classe Filtre. L’elecció d’un filtre o un altre depèn u ńicament de l’extensió del document que cal filtrar en cada moment. No sempre es pot extreure la informació dels documents, ja que es freq¨ uent trobar documents mal formats. Les llibreries mencionades anteriorment proporcionen classes per corregir documents, tot i que no s’han utilitzat ja que exigeixen un cost addicional. Mirar la figura 3.1. Juntament amb la meta-informació de cada document, s’extreu el seu cos. Cal dir que la meta-informació són camps d’informació opcionals, de manera que la informació important és la que conté el propi cos del document. En els documents HTML el cos es troba dins de les marques <body> i </body>, per tant, si extraiem la informació del seg¨ uent document, obtindrem el text que es mostra al final: <html> <head> <title>MP3.com - the source for digital music!</title> <meta name="author"> content="MP3.com"> <meta name="keywords"> content="mp3.com, mp3, music, Robert Walter"> </head> <body> <dl><dd><div style="text-align: center"><div class="pad-5-bottom"> <a href="http://www.mp3.com/robert-walter/artists/194751/reviews.html&amp"> <dd><img src="http://image.com.com/mp3/images/artist/p24047pupb6.jpg" width="50" alt=" Robert Walter"></a> </dd> </div><dd><br/><a href="http://www.mp3.com/robert-walter/reviews.html"> <strong>Robert Walter</strong></a> <br/> <img style="padding-top:5px;"src="http://www.mp3.com/style/stars_5.0.gif"/> </dd></div><p class="f-small"><br/>Robert Walter Is unfortunatly in that class of musicans that is so good, that most people will probably never be lucky enough to stumble across. He’s a keyboarder from NewYork, one of the little...&quot; <br/><span class="f-grey">Reviewed by</span> <a href="http://www.mp3.com/users/magookie/review.php"><strong>magookie</strong> </a></p></dd></dl> </body> </html>

T´ıtol MP3.com - the source for digital music! Autor MP3.com Keywords mp3.com, mp3, music, Robert Walter Resum Cos Robert Walter "Robert Walter Is unfortunatly in that class of

´ I INDEXACIO ´ D’INFORMACIO ´ CAP´ITOL 3. EXTRACCIO

Figura 3.1: Filtres implementats

´ I INDEXACIO ´ D’INFORMACIO ´ CAP´ITOL 3. EXTRACCIO

musicans that is so good, that most people will probably never be lucky enough to stumble across. He’s a keyboarder from NewYork, one of the little..." Reviewed by magookie El seg¨ uent exemple mostra un simple document RTF i la seva corresponent informació extreta. S’observa que és fàcil extreure la meta-informació ja que aquesta està emmarcada clarament: {\rtf1\ansi\ansicpg1252\deff0\deflang3082{\fonttbl {\f0\froman\fcharset0 Times New Roman;}{\f1\fswiss\fcharset0 Arial;}} {\info {\title What is Artificial Life?}{\author Chris G. Langton}} \viewkind4\uc1\pard\sb100\sa100\f0\fs24 In order to derive general theories about life, we need an ensemble of instances to generalize over. Since it is quite unlikely that alien lifeforms will present themselves to us for study in the near future, our only option is to try to create alternative life-forms ourselves - Artificial Life literally ‘‘life made by Man rather than by Nature.’’\par \pard\f1\fs20\par}

T´ıtol What is Artificial Life? Autor Chris G. Langton Keywords Resum Cos In order to derive general theories about life, we need an ensemble of instances to generalize over. Since it is quite unlikely that alien lifeforms will present themselves to us for study in the near future, our only option is to try to create alternative life-forms ourselves - Artificial Life - literally ‘‘life made by Man rather than by Nature.’’ La informació que s’extreu és la informació u ´til que interessa als usuaris. No es fàcil classificar aquest tipus d’informació ja que no satisfà cap patró concret mitjan¸cant el qual es puguin realitzar cerques amb èxit. En els pròxims apartats s’explica com crear ´ındexs generats amb Lucene, mitjan¸cant els quals es poden realitzar cerques ràpides de continguts.

3.2

Crear un ´ındex

La creació d’´ındexs es realitza amb Lucene, la qual proporciona classes espec´ıfiques per crear ´ındexs d’informació textual, sense tenir en compte el seu origen, el seu format, i el seu idioma. Això significa que es pot usar Lucene per indexar i cercar informació emmagatzemada en fitxers: pàgines web de servidors web, documents emmagatzemats en sistemes de fitxers locals, fitxers de text, documents de Microsoft Word, documents HTML o PDF,

´ I INDEXACIO ´ D’INFORMACIO ´ CAP´ITOL 3. EXTRACCIO

o qualsevol altre format d’on es pugui extreure informació textual. En aquest sentit, a més a més, es poden indexar i cercar correus electrònics, llistes de correu, conversacions d’aplicacions de missatgeria instantània, etc. En aquesta aplicació, s’ha utilitzat Lucene per indexar la informació extreta dels documents explorats i descarregats mitjan¸cant l’aplicació d’exploració descrita a l’apartat 2 sobre l’exploració web. Al nucli dels motors de cerca existeix el concepte d’indexar. Consisteix en processar la informació original dels documents per generar vistes molt eficients de referències creuades, amb l’objectiu de facilitar la cerca d’informació. Suposem que cal realitzar una cerca sobre un gran nombre de documents, i que volem trobar aquells documents que contenen determinades paraules o frases. Una forma molt convencional seria realitzar una cerca seq¨ uencial sobre cada fitxer per tal de localitzar la paraula o frase desitjada. Aquest sistema presenta molts problemes, ja que per una banda podem tenir molts documents i per l’altra, aquests documents poden ser molt grans. ´ en aquest punt on entra en joc el concepte d’indexar. Per cercar Es grans quantitats de text ràpidament, primer cal indexar el text extret de cada document i convertir-lo en un format que permeti realitzar-hi cerques eficientment, evitant el lent i ineficient procés d’escaneig seq¨ uencial. Aquest procés de conversi´ o s’anomena indexaci´ o i la seva sortida o resultat s’anomena ´ındex. Un ´ındex es pot interpretar com una estructura que permet accessos aleat` oris ràpids a paraules emmagatzemades en aquesta. En el cas de Lucene, un ´ındex és una estructura de dades especialment dissenyada, t´ıpicament emmagatzemada al sistema de fitxers en forma d’un conjunt de fitxers. Entendre el funcionament de l’aplicació d’indexació implica entendre la separació o barrera que hi ha entre l’aplicació desenvolupada i Lucene, aix´ı com les tasques que realitza cadascuna d’aquestes dos parts. Aquesta separació queda reflexada clarament mitjan¸cant la figura 3.2. Es recorren, un a un, els documents de l’exploració que cal indexar. Es tracta de documents descarregats mitjan¸cant l’eina d’exploració, i emmagatzemats a la Intranet del disc. Aquesta tasca es du a terme recorrent les URLs del fitxer d’exploració seleccionat per l’usuari, per a cada URL s’obté la corresponent adre¸ca del fitxer al disc. De cada document s’extreu la seva informació textual aplicant el corresponent filtre en funció de la seva extensió. El text extret és el que s’utilitza per a crear l’´ındex. Les classes de Lucene que cal destacar són les seg¨ uents: IndexWriter és el component central del procés d’indexació. Aquesta classe crea un nou ´ındex i afegeix documents a ´ındexs ja existents. Es pot interpretar

´ I INDEXACIO ´ D’INFORMACIO ´ CAP´ITOL 3. EXTRACCIO

Figura 3.2: Separació entre Lucene i el nivell d’aplicaci´ o la classe IndexWriter com un objecte que ofereix accés d’escriptura a l’´ındex, però no ofereix operacions de lectura ni de cerca. Directory Aquesta classe representa la localització f´ısica d’un ´ındex de Lucene. Podem preferir mantenir un ´ındex en memòria, o bé al disc. Per ´ tracta d’una mantenir un ´ındex al disc hi ha la classe FSDirectory. Es subclasse de la classe Directory que manté una llista de fitxers reals al sistema de fitxers del disc. L’altra implementació de la classe Directory és RAMDirectory. Aquesta proporciona una interf´ıcie idèntica a la de la classe FSDirectory, però en aquest cas l’´ındex s’emmagatzema en memòria. RAMDirectory és u ´til quan cal crear ´ındexs petits que poden ser emmagatzemats completament en memòria i poden ser eliminats al finalitzar l’aplicació. L’´ us d’´ındexs en memòria proporciona una major velocitat d’accés que els ´ındexs emmagatzemats al disc. La tendència natural és utilitzar ´ındexs en memòria i guardar-los a disc quan es supera un tamany o l´ımit concret. Analyzer Abans que el text sigui indexat, aquest passa per objecte de la classe Analyzer. La classe Analyzer extreu tokens de sortida del text que ha de ser indexat. Si el contingut que ha de ser indexat no és text pla, aquest ha de ser filtrat. Document La classe Document representa una colecció de camps. Podem interpretarho com un bloc d’informació, com ara una pàgina web, un missatge de correu electrònic o un fitxer de text. Els camps d’un document rep-

´ I INDEXACIO ´ D’INFORMACIO ´ CAP´ITOL 3. EXTRACCIO

resenten la meta-informació associada a aquest document. L’origen de la informació és completament irrellevant per Lucene. La metainformació com l’autor, el t´ıtol, el resum, la data, entre d’altres, són indexats i emmagatzemats per separat com a camps del document. Field Cada objecte de la classe Document en un ´ındex conté un o més camps, encap¸culats en objectes de la classe Field. Cada camp correspon a una part d’informació que pot ser consultada a través de l’´ındex durant un procés de cerca. Lucene ofereix quatre tipus diferents de camps que poden ser utilitzats. Tots els camps consisteixen en una parella de nom i valor. El tipus de camp que cal usar depèn de l’´ us que se’n vulgui fer. Els tipus de camps difereixen entre ells per les seves caracter´ıstiques. Alguns són analitzats, però d’altres no; alguns són indexats mentre que d’altres són emmagatzemats completament. Els tipus de camps que ofereix Lucene són els que s’expliquen a continuació: Keyword No és analitzat, però és indexat i emmagatzemat literalment a l’´ındex. Aquest tipus s’acostuma a usar en aquells valors que han de ser preservats, aix´ı com URLs, rutes de sistemes de fitxers, dates, noms propis, n´ umeros de telèfon, etc. ´ analitzat i no indexat, però el seu valor és emmagatzemat literalUnIndexed Es ment a l’´ındex. Aquest tipus s’acostuma a usar en aquells valors que han de ser visualitzats al mostrar els resultats de les cerques, com ara URLs o claus prim` aries, però en canvi els seus valors no poden ser cercats directament. No s’ha d’usar per emmagatzemar valors molt grans, ja que poden fer incrementar excesivament el tamany de l’´ındex. ´ el contrari del tipus UnIndexed. Aquest tipus de camp és analitzat i UnStored Es indexat, però no és emmagatzemat a l’´ındex. Aquest tipus s’acostuma a usar per indexar una gran quantitat de text que no necessita ser proporcionada en la seva forma original, aix´ı com el cos de pàgines web, o el cost de qualsevol tipus de document de text. ´ analitzat i indexat. Això implica que els camps d’aquest tipus Text Es poden ser cercats, però cal vigilar amb el seu tamany. Si la informaci´ o a indexar és una cadena de caràcters, aleshores s’emmagatzema, però si la informació prové d’un flux de dades qualsevol, aleshores no s’emmagatzema. A l’´ındex s’han tingut en compte els camps anterioment mencionats: t´ıtol, autor, keywords, resum i cos. Aquests són els camps que contenen meta-informació extreta dels documents web descarregats. A més a més

´ I INDEXACIO ´ D’INFORMACIO ´ CAP´ITOL 3. EXTRACCIO

d’aquests cinc camps, cal tenir en compte tres camps per proporcionar informaci´ o funcional addicional dels documents a indexar: la URL del document, la ruta del document al sistema de fitxers i el tamany del document. En total, cada document que cal indexar contempla vuit camps. Els resultats d’una cerca entreguen la url, el t´ıtol, l’autor, el resum i el tamany dels documents trobats. doc.add(Field.UnStored("cos",filtre.obtenirCos())); doc.add(Field.Keyword("keywords",filtre.obtenirKeywords())); doc.add(Field.UnIndexed("url",url)); doc.add(Field.UnIndexed("autor",filtre.obtenirAutor())); doc.add(Field.UnIndexed("cache",ruta)); doc.add(Field.UnIndexed("tamany",(new Long(tamany)).toString())); doc.add(Field.Text("resum",filtre.obtenirDescripcio())); doc.add(Field.Text("titol",filtre.obtenirTitol())); Després que el text entrant dels documents hagi estat analitzat, aquest està llest per ser afegit a l’´ındex. Lucene emmagatzema les entrades en una estructura de dades coneguda com ´ındex invertit. Aquesta estructura fa un u ´s eficient de l’espai del disc mentre permet realitzar cerques ràpides. El que fa que aquesta estructura sigui invertida és que utilitza els tokens extrets de les entrades dels documents com si fossin claus de cerca, enlloc d’utilitzar els documents com si fossin entitats centrals. En altres paraules, no pretén localitzar quines paraules hi ha en un determinat document, sinó quins documents contenen determinades paraules.

3.3

Esquema general de l’indexador

El funcionament de l’eina d’indexació és for¸ca simple. S’usa una combinació d’´ındexs RAMDirectory i FSDirectory, de manera que es pretén aprofitar els beneficis que aporta cadascun dels dos. Es realitzen m´ ultiples processos d’indexació simultanis mitjan¸cant l’´ us de fils d’execució, d’aquesta manera s’aconsegueix accelerar notablement la velocitat de la indexació total, ja que aix´ı les indexacions fallides no entorpeixen les indexacions exitoses. S’entén per indexaci´ o fallida d’un document, aquella que, per exemple, no s’ha pogut extreure el text pla del document. Els fils d’execuci´ o concurrents treballen u ńicament amb ´ındexs RAMDirectory, és a dir, amb ´ındexs emmagatzemats temporalment en memòria. Quan la indexaci´ o individual d’un document finalitza, aquest ´ındex s’afegeix a l’´ındex final emmagatzemat al disc mitjan¸cant la classe FSDirectory. El fet que cada fil d’execuci´ o treballi amb un ´ındex propi emmagatzemat en memòria evita que hi puguin haver problemes de bloqueig entre fils d’execució diferents en el cas d’usar un ´ındex compartit. A més a més, s’evita

´ I INDEXACIO ´ D’INFORMACIO ´ CAP´ITOL 3. EXTRACCIO

Figura 3.3: Esquema general de l’indexador realitzar accessos continuats al disc, ja que l’´ındex final nom´es s’amplia quan finalitza la indexaci´ o realitzada per alguns dels fils d’execuci´ o. Mirar figura 3.3.

Cap´ıtol 4

Diagrames de classe 4.1

Aplicaci´ o exploradora

A continuació es mostren els diagrames de cada classe implementada a l’aplicaci´ o d’exploració. La seg¨ uent llista detalla cadascuna d’aquestes classes: • AplicacioPrincipal : Constitueix la classe principal de l’aplicació. Carrega el men´ u d’inici ràpid. • AplicacionsDeCerca : S’encarrega de visualitzar el men´ u d’eines de cerca. ´ la classe base del web crawler. Carrega la interf´ıcie • WebCrawler : Es i executa l’aplicació de crawling. ´ la classe que implementa l’aplicació de crawling explicada • Aranya : Es en apartats anteriors. ´ la classe que implementa el gestor de de• GestorDescarregues: Es scàrregues explicat en apartats anteriors. • GestorIntranet: La seva tasca és mantenir i gestionar els fitxers i directoris de la intranet del disc. • GestorArbresWeb: Classe que implementa el manteniment de les estructures de nodes explorats dels hosts. • ArbreWeb: Classe que implementa l’estructura de nodes explorats d’un host. • NodeWeb: Implementa l’estructura node utilitzada per la classe ArbreWeb. • ContenidorDescarregues: Classe abstracta que modela els mètodes de l’estructura de nodes pendents. 51

CAP´ITOL 4. DIAGRAMES DE CLASSE

• ContenidorDescarreguesFIFO: Implementació FIFO de l’estructura de nodes pendents. • ContenidorDescarreguesLIFO: Implementació LIFO de l’estructura de nodes pendents. • ThreadDescarregadorUrl : Implementació del fil d’execució de descàrregues simples via HTTP. • ThreadDescarregadorUrlPost: Implementació del fil d’execució de descàrregues HTTP amb POST previ. • ThreadDescarregadorUrlAmbCookies: Implementació del fil d’execució de descàrregues HTTP amb u ´s de cookies. • Logger : Classe que implementa l’anàlisi d’incidències produ¨ıdes durant les desc` arregues HTTP. • ExtractorFormularisWeb: S’encarrega de descarregar i extreure formularis web de les pàgines web. • FormulariWeb: Classe que emmagatzema informació relativa a un formulari web. • ContenidorFormularisWeb: Classe contenidor que emmagatzema formularis web. • GraficEstadistic: Implementació del gràfic de velocitats de descàrrega. • InterficieGrafica : Implementació de la interf´ıcie d’usuari de l’eina d’exploració. • GeneradorGrafs: Classe que s’encarrega de generar grafs a partir de l’estructura de nodes explorats. • InterficieGraficaMapaNodes: Implementació de la interf´ıcie d’usuari de l’eina visualitzadora de grafs web.

4.2

Aplicaci´ o indexadora

A continuació es mostren els diagrames de cada classe implementada a l’aplicaci´ o d’indexació. La seg¨ uent llista detalla cadascuna d’aquestes classes: ´ la classe que executa l’aplicació d’indexació. • AplicacioIndexadora : Es Permet la interacció entre la interf´ıcie d’usuari i l’indexador. • IndexadorExploracions: Implementa el nucli del procés d’indexació.

CAPÂ´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.1: AplicacioPrincipal.java

Figura 4.2: AplicacionsDeCerca.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.3: WebCrawler.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.4: Aranya.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.5: GestorDescarregues.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.6: GestorIntranet.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.7: GestorArbresWeb.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.8: ArbreWeb.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.9: NodeWeb.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.10: ContenidorDescarregues.java ContenidorDescarreguesFIFO.java ContenidorDescarreguesLIFO.java • EstatIndexadorExploracions: Classe que conté informació relativa a l’estat de l’indexaci´ o en cada moment. • HistogramaFrequenciaParaules: Classe que implementa els procediments per generar i processar histogrames de freq¨ uència de paraules. • GestorHistogramesFrequenciaParaules: Classe contenidor que emmagatzema histogrames de freq¨ uència de paraules. Genera el fitxer de freq¨ uències de paraules. • InterficieGraficaIndexador : Implementació de la interf´ıcie d’usuari de l’eina d’indexació.

4.3

Aplicaci´ o de cerca

A continuació es mostren els diagrames de cada classe implementada a l’aplicaci´ o de cerca. La seg¨ uent llista detalla cadascuna d’aquestes classes: ´ la classe que executa l’aplicació per re• AplicacioCercadora : Es alitzar cerques. Permet la interacció entre la interf´ıcie d’usuari i el cercador.

CAPÂ´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.11: ThreadDescarregadorUrl.java ThreadDescarregadorUrlPost.java ThreadDescarregadorUrlAmbCookies.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.12: Logger.java ´ la classe que executa l’aplicació servi• AplicacioServidorCerques: Es dora de cerques. • Cercador : Implementa el nucli del procés que realitza cerques. • MissatgeCercaRemota : Classe utilitzada per definir els missatges de cerca. • MissatgeRespostaCercaRemota : Classe utilitzada per definir els missatges de resposta de cerca. • CercaRemota : Classe utilitzada per indicar els paràmetres de cerca remota. • ResultatCerca : Classe utilitzada per emmagatzemar els resultats de la cerca. • InterficieGraficaCercador : Implementació de la interf´ıcie d’usuari de l’eina de cerca. • InterficieGraficaServidorCerques: Implementació de la interf´ıcie d’usuari del servidor de cerques.

CAPÂ´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.13: ExtractorFormularisWeb.java

Figura 4.14: ContenidorFormularisWeb.java

CAPÂ´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.15: FormulariWeb.java

Figura 4.16: GraficEstadistic.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.17: InterficieGrafica.java

CAPÂ´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.18: InterficieGraficaMapaNodes.java

Figura 4.19: AplicacioIndexadora.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.20: IndexadorExploracions.java

CAPÂ´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.21: EstatIndexadorExploracions.java

Figura 4.22: HistogramaFrequenciaParaules.java

Figura 4.23: GestorHistogramesFrequenciaParaules.java

CAP´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.24: InterficieGraficaIndexador.java

CAPÂ´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.25: AplicacioCercadora.java

Figura 4.26: AplicacioServidorCerques.java

CAPÂ´ITOL 4. DIAGRAMES DE CLASSE

Figura 4.27: Cercador.java

Figura 4.28: MissatgeCercaRemota.java

Figura 4.29: MissatgeRespostaCercaRemota.java

Cap´ıtol 5

Llibreries utilitzades Per al desenvolupament d’aquest projecte s’han utilitzat llibreries conegudes per a Java. Es tracta de llibreries gratu¨ıtes i de codi obert, que proporcionen classes per a realitzar tasques concretes de filtratge de documents, extracció d’hipervincles, descàrrega de continguts web emprant cookies, indexació de text, creació de grafs, etc. En els pròxims apartats s’expliquen les llibreries utilitzades més destacades d’aquest projecte.

5.1

Lucene

Jakarta Lucene és un motor de cerca implementat en Java. Va ser creat per Doug Cutting al 1997 i distribu¨ıt com a software lliure a l’any 2000. Pot ser utilitzat en qualsevol aplicació que requereixi realitzar cerques de text, des de cerques en pàgines web fins a gestors de correu. L’´ ultima versió ha estat arreglada i aporta millores, com ara un filtre sobre el què es realitzen les cerques o una API més oberta que permet a l’usuari crear el seu propi sistema de puntuació de documents. Per a més informació es recomana consultar l’apartat 3 sobre extracció i indexació d’informació.

5.2

Jung

Jung és una llibreria que ens proporciona un llenguatge com´ u i estés per a la modelació, anàlisi i visualització de dades que poden ser representades en forma de grafs o en forma de xarxa. Jung està desenvolupat en Java. L’arquitectura de Jung està designada per soportar una gran varietat de representacions d’entitats i les seves relacions com els grafs directes i indirectes, els grafs mutimodals, grafs amb camins paral·lels i els hipergrafs. Això proporciona un mecanisme d’anotació de grafs, entitats i relacions amb meta-informació. Això facilita la creació d’eines anal´ıtiques de dades complexes que poden examinar les relacions entre les entitats tan bé com les 73

CAP´ITOL 5. LLIBRERIES UTILITZADES

dades adjuntes per cada entitat i relació. La distribució actual de Jung inclou les implementacions d’un gran nombre d’algorismes de la teoria de grafs, exploraci´ o de dades, anàlisi de la xarxa, com les rutines per al cl´ ustering, la descomposició, l’optimització, la generació de grafs aleatoris, l’anàlisi estad´ıstic, el c` alcul de distàncies entre nodes d’una xarxa, fluxos, i mesures importants (centralitat, PageRank, HITS, etc.). Jung proporciona un framework visual que fa fàcil la tasca de desenvolupar eines per a l’exploraci´ o interactiva d’informació en forma de xarxa. Els usuaris poden usar alguns dels algorismes de representaci´ o proporcionats, o utilitzar el framework per crear les seves pròpies representacions. A més a més, ofereix mecanismes de filtratge que permeten centrar l’atenció, o l’´ us d’algorismes en parts espec´ıfiques dels grafs. Tractant-se d’una llibreria de codi obert, Jung proporciona un framework per a l’anàlisi i visualitzaci´ o de grafs i xarxes. Jung facilita el desenvolupament d’aplicacions que treballen amb informació relacional, ja que permet la reutilització de codi ja existent i evitar aix´ı implementar codi ja existent. Les operacions bàsiques que es poden realitzar sobre els grafs es mostren a continuació: • newInstance(): Retorna un graf del mateix tipus que el graf en el que s’ha invocat el mètode. • addVertex(v): Afegeix el vèrtex v al graf i retorna una referència al vèrtex afegit. • addEdge(e): Afegeix l’aresta e al graf i retorna una referència a l’aresta afegida. • getVertices(): Retorna el conjunt de vèrtexs del graf. • getEdges(): Retorna el conjunt d’arestes del graf. • numVertices(): Retorna el n´ umero de vèrtexs del graf. • numEdges(): Retorna el n´ umero d’arestes del graf. • removeVertex(v): Elimina el vèrtex v del graf. • removeEdge(e): Elimina l’aresta e del graf. • removeVertices(s): Elimina els vèrtexs s del graf. • removeEdges(s): Elimina les arestes s del graf. • removeAllEdges(): Elimina totes les arestes del graf, deixant els vèrtexs intactes.

CAP´ITOL 5. LLIBRERIES UTILITZADES

• removeAllVertices(): Elimina tots els vèrtexs del graf i arestes del graf. • copy(): Realitza una c` opia exacta del graf i de tots els seus continguts. Les operacions bàsiques que es poden realitzar sobre els vèrtexs es mostren a continuació: • getGraph(): Retorna una referència del graf que conté aquest vèrtex. • getNeighbors(): Retorna el conjunt de vèrtexs que estan connectats cap aquest vèrtex. • getIncidentEdges(): Retorna el conjunt d’arestes que incideixen cap aquest vèrtex. • degree(): Retorna el n´ umero d’arestes incidents cap aquest vèrtex. • getEquivalentVertex(g): Retorna el vèrtex del graf g, o qualsevol que sigui equivalent. • isNeighbor(v): Retorna cert si el vèrtex v i aquest vèrtex són incidents en almenys una aresta, retorna fals altrament. • isIncident(e): Retorna cert si l’aresta e i aquest vèrtex són incidents, retorna fals altrament. • removeAllIncidentEdges(): Elimina totes les arestes que són incidents cap aquest vèrtex. • copy(g): Realitza una còpia d’aquest vèrtex en el graf g. Les operacions bàsiques que es poden realitzar sobre les arestes es mostren a continuació: • getGraph(): Retorna una referència del graf que conté aquesta aresta. • getIncidentVertices(): Retorna el conjunt de vèrtexs que són incidents cap aquesta aresta. • getEquivalentEdge(g): Retorna l’aresta del graf g, o qualsevol que sigui aquivalent. • numVertices(): Retorna el n´ umero de vèrtexs que són incidents cap aquesta aresta. • isIncident(v): Retorna cert si el vèrtex v és incident cap aquesta aresta, retorna fals altrament.

CAP´ITOL 5. LLIBRERIES UTILITZADES

• copy(g): Realitza una còpia d’aquesta aresta en el graf g. El paquet de visualitzaci´ o de Jung ofereix mecanismes per renderitzar i superposar grafs. Les implementacions actuals del renderitzador utilitzen l’API Swing de Java per mostrar grafs, però els renderitzadors han de ser implementats utilitzant altres eines. En general, una visualització es complementa amb els seg¨ uents components: • Una capa(Layout) que conté un graf i determina la posició de cada vèrtex que ha de ser pintat. • Un component(Swing) on la informació és renderitzada. Les implementacions actuals utilitzen el component VisualizationViewer, es tracta d’una extensi´ o de la classe JPanel de Swing. • Un renderitzador(Renderer ) que obté la informació proporcionada per la capa que conté el graf i pinta els vèrtexs i arestes sobre el component.

5.3

JTidy

JTidy és l’adaptació per a Java de l’aplicació HTML Tidy, un analitzador sint` actic del llenguatge HTML. JTidy pot ser utilitzat com una eina per corregir documents HTML mal implementats. A més a més, JTidy proporciona una interf´ıcie de tipus DOM per al tractament dels documents HTML, el qual permet permet utilitzar JTidy tal i com si es tractés d’un parser DOM.

5.4

PDFBox

PDFBox és una llibreria per a Java per treballar amb documents PDF. Permet la creació de nous documents PDF, la manipulació de documents existents i la capacitat per extreure contingut dels documents, a més a més, PDFBox també inclou algunes utilitats a trabés de la l´ınia de comandes. • Extracció de text dels documents PDF. • Combinar documents PDF. • Xifratge i desxifratge de documents PDF. • Permet una f` acil integració amb Lucene. • Creació de documents PDF a partir de fitxers de text. • Creació d’imatges a partir de documents PDF.

CAP´ITOL 5. LLIBRERIES UTILITZADES

Una de les principals caracter´ıstiques de PDFBox és la capacitat d’extreure text de grans varietats de documents PDF. Aquesta funció la trobem al paquet org.pdfbox.util.PDFTextStripper i pot ser fàcilment executada amb l’eina org.pdfbox.ExtractText. Els documents PDF poden tenir meta-informació XML associada amb propòsits concrets amb un document PDF. Per exemple, el PD Model té la capacitat per contenir aquesta meta-informació: • PDDocumentCatalog • PDPage • PDXObject • PDICCBased • PDStream Aquesta meta-informació s’emmagatzema en objectes PDF, i compleix les especificacions XML. Actualment no hi ha cap API d’alt nivell que manegui a meta-informació XML, PDFBox utilitza els procediments InputStream / OutputStream de Java per recuperar o emmagatzemar la meta-informació XML. PDFBox també permet afegir fitxers adjunts als documents PDF.

5.5

Jakarta POI

El projecte POI és el projecte principal per al desenvolupament d’adaptacions en Java pur dels formats de fitxer basats en el Format de Document Compost OLE 2 de Microsoft. El format de Documents Compost OLE 2 l’utilitzen els documents d’Office de Microsoft, aix´ı com els programes que utilitzen conjunts de propietats MFC per serialitzar els seus objectes de tipus document. El projecte POI consisteix en APIs per manipular varis formats de fitxer basats en el format de Document Compost OLE 2 de Microsoft, utilitzant Java pur. Concretament, es poden llegir i escriure fitxers Microsoft Excel utilitzant Java. Aviat es podrà llegir i escriure fitxers Word utilitzant Java Word. En qualsevol cas, hi ha una API completa per portar altres formats de Document Compost OLE 2. Entre els fitxers basats en OLE 2 de Microsoft, s’inclouen la major part dels fitxers de Microsoft Office tals com XLS i DOC, aix´ı com formats de fitxer basats en l’API de serialització MFC.

CAP´ITOL 5. LLIBRERIES UTILITZADES

´ l’adaptació POIFS és la part més antiquada i més estable del projecte. Es del Format de Document Compost OLE 2 a Java pur. Suporta funcionalitat de lectura i escriptura. Tots els components es serveixen d’ell per definició. HSSF és l’adaptació del format de fitxer de Microsoft Excel 97(-2002) (BIFF8) a Java pur. Soporta lectura i escriptura. HWPF es l’adaptació del format de fitxer de Microsoft Word 97 a Java pur. Suporta lectura i escriptura. HPSF és l’adaptació del format de conjunt de propietats OLE 2 a Java pur. Els conjunts de propietats s’utilitzen principalment per emmagatzemar les propietats d’un document (t´ıtol, autor, data de l’´ ultima modificació, etc.), però també poden ser utilitzats per a propòsits espec´ıfics d’una aplicació. Actualment HPSF suporta només la funcionalitat de lectura.)

5.6

IR-Webutils

Es tracta d’una llibreria formada per un conjunt de classes per descarregar documents HTML dels servidors web, i extreure els seus hipervincles de sortida. A continuació es mostra un resum de les seves classes: • DirectorySpider : Es tracta d’un web crawler que explora a través dels subdirectoris de l’ordinador. • Graph : Estructura per generar grafs. ´ una representació d’informació sobre una pàgina • HTMLPage: Es web. • HTMLPageRetriever : Permet als clients descarregar pàgines web a partir d’URLs. • HTMLParserMaker : Permet als clients carregar una instància de HTMLEditorKit.Parser. ´ una classe que conté una URL. • Link : Es • LinkExtractor : Extreu els enlla¸cos de sortida d’una pàgina web donada. • Node: Es tracta d’una estructura node per a la generació de grafs. • RobotExclusionSet: Proporciona funcionalitats per complir el protocol d’exclusió Robots Exclusion Protocol. • RobotsMetaTagParser : Extreu meta-informació dels documents HTML.

CAP´ITOL 5. LLIBRERIES UTILITZADES

• SafeHTMLPage: Proporciona informació relativa al contingut que cal indexar, o no, d’un document web. • SafeHTMLPageRetriever : Classe per respectar el protocol d’exclusió. • SiteSpider : Classe simple per a explorar llocs web. • Spider : Framework per elaborar web crawlers. • URLChecker : Classe per validar adreces URL. • WebPage: Classe estàtica que proporciona operacions per descarregar pàgines web. • WebPageViewer : Classe que conté utilitats per descarregar i mostrar pàgines HTML.

5.7

HTTPClient

Aquest paquet proporciona eines per desenvolupar i utilitzar clients HTTP. Implementa el protocol HTTP/1.0 i HTTP/1.1, incloent els mètodes HEAD, GET, POST i PUT. Manega automàticament autoritzacions, redireccions, i cookies. A més a més, inclou còdecs per codificar i decodificar en base 64, manegar formularis web, etc. Totes aquestes funcionalitats són lliures i estan regides per una llicència GNU Lesser General Public License (LGPL). Si un servidor requereix autorització bàsica, el client HTTP mostra una caixa de diàleg demanant la informació desitjada (normalment un nom d’usuari i un password), tal i com ho fan els clients web convencionals. Aquesta informació inserida per l’usuari és emmagatzemada en una caché i utilitzada més endavant de manera automàtica. Si com a programadors coneixem el nom d’usuari i la contrasenya per avan¸cat, podem configurar les aplicacions per tal que utilitzin aquestes dades mitjan¸cant els mètodes addBasicAuthorization() i addDigestAuthorization de la classe HTTPConnection, o mitjan¸cant els corresponents mètodes de la classe AuthorizationInfo. Les redireccions (amb codis de retorn 301, 302, 303, 305 i 307) són manegades automàticament quan s’utilitzen els mètodes GET i HEAD. Les cookies són manegades automàticament. Quan una resposta conté el missatges Set-Cookie o Set-Cookie2 a la cap¸calera, les cookies són filtrades i emmagatzemades; quan una petició és enviada, aquesta és escanejada per comprovar si cal aplicar l’´ us de les cookies.

CAP´ITOL 5. LLIBRERIES UTILITZADES

A causa de q¨ uestions de privacitat amb l’´ us de les cookies, s’utilitza una pol´ıtica de privacitat per permetre a l’usuari acceptar o refusar l’enviament de cookies. Per defecte, quan un servidor solicita una cookie s’obre una caixa de diàleg per preguntar a l’usuari si vol acceptar-la o no. La classe Util ofereix un conjunt de mètodes per manegar els camps de les cap¸caleres HTTP. Això és possible amb l’´ us del mètode parseHeader(), que s’encarrega d’analitzar la sintaxi del protocol. Cal remarcar que aquest analitzador no manega l’autentificació de les cap¸caleres WWW-Authenticate o Proxy-Authenticate.

5.8

JFreeChart

JFreeChart és una llibreria lliure per a Java per generar gràfics de dades, que inclou les seg¨ uents funcionalitats: • Pie Charts (2D i 3D). • Gràfics de barres (regulars i empilats, amb efecte 3D opcional). • Gràfics de l´ınia i d’àrea. • Scatter Plots i gràfics de bombolla. • Sèries de temps i gràfiques Candle Stick. • Gràfiques combinades. • Gràfiques de Pareto. • Diagrames de Gantt. • Gràfics de vent i gràfiques de s´ımbols. • Gràfiques Wafer Map. JFreeChart pot ser utilitzat en aplicacions Java, applets, servlets i JSP.

Bibliografia [1] Otis Gospodnetic i Erik Hatcher. Lucene in action (A guide to the Java search engine). Manning Publications Co. 2005. [2] Vladislav Shkapenyuk i Torsen Suel. Design and Implementation of a High-Performance Distributed Web Crawler. Polytechnic University of Brooklyn, 2001. [3] Dustin Boswell. Distributed High-performance Web Crawlers: A Survey of the State of the Art. 2003. [4] Marc Najork i Janet L. Wiener. Breadth-First Search Crawling Yelds High-Quality Pages. Compaq Systems Research Center, 2001. [5] Joan Gimbert, Ramiro Moreno, Josep Maria RibÂ´o i Magda Valls. Apropament a la teoria de grafs i als seus algorismes. Universitat de Lleida, 1998. [6] HTML 4.01 Specification W3C Recommendation 24 desember 1999. [7] Carlos Castillo i Ricardo Baeza-Yates. Practical Issues of Crawling Large Web Collections. Center for Web Research, University of Chile, 2005. [8] Carlos Castillo. Effective Web Crawling. University of Chile, 2004.

Ap` endix A

Manual d’aplicaci´ o per a l’usuari A.1

Requeriments

L’aplicació ha estat compilada i executada amb èxit utilitzant la versió de Java(TM) 2 JDK1.5.0 01, tot i que amb la versió 1.4 també s’ha pogut provar que funciona correctament. Es pot comprovar la versió de Java del nostre sistema executant la seg¨ uent comanda desde la l´ınia de comandes: java -version La seva execuci´ o hauria de mostrar una cosa com la seg¨ uent: java version "1.5.0_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08) Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode) Els requeriments m´ınims de hardware depenen en gran part de l’´ us que es faci de l’aplicació, tot i que es recomana disposar d’un equip amb processador Pentium 3 800MHz amb 128MBytes de memòria RAM com a m´ınim.

A.2

Instal·laci´ o

El programa disposa d’un sistema d’instal·lació t´ıpic per a Windows, mitjan¸cant el qual s’instal·la automàticament tota l’aplicació a través d’un assistent. L’instal·lador ofereix la possibilitat d’afegir un accés directe a l’escriptori o a la barra d’inici si l’usuari ho desitja, de la mateixa manera també proporciona un sistema de desinstal·lació de tot el conjunt. Un cop instal·lada l’aplicació, tindrem accés a tres opcions: editar el fitxer rutes.cfg, restaurar i recompilar tota l’aplicació, i executar l’aplicaci´ o.

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Tots els fitxers descarregats durant les exploracions s’emmagatzemen en un directori de l’ordinador, per defecte aquest directori és \intranet. De la mateixa manera, tots els ´ındexs generats per l’aplicació d’indexació s’emmagatzemen també en un directori, per defecte aquest directori és \indexs. Aquests dos directoris són creats automàticament al moment d’executar l’aplicació, però hi ha la possibilitat de canviar-los. Per fer-ho, cal editar el fitxer rutes.cfg que es troba al mateix directori de l’aplicació i substitu¨ır les configuracions per les desitjades: ### Fitxer de rutes ### ## Ruta de la Intranet ## c:\\intranet\\ ## Ruta de la carpeta d’indexs ## c:\\indexs\\ Si es desitja, es pot efectuar una instal·lació manual de l’aplicació, ja que per exemple, pot resultar necessari executar l’aplicació en un sistema Linux. En aquest cas, cal utilitzar la distribució que ve empaquetada en un simple fitxer comprimit i descomprimir-ho en un directori de l’ordinador. L’aplicació sempre ve acompanyada de dos fitxers de processament per lots (fitxers .bat). El fitxer build.bat s’encarrega de restaurar i recompilar tot el conjunt deixant l’aplicació en el seu estat inicial, tot i que aquesta operació no és estrictament necess` aria ja que l’aplicació ja es distribueix compilada. El fitxer Toke.bat simplement executa l’aplicació. Per a Linux aquests dos fitxers no serveixen, tot i que de moment, tampoc s’han elaborat els corresponents scripts, per tant cal fer-ho manualment a través d’un intèrpret de comandes o shell. La corresponent compilació es fa seguint el seg¨ uent exemple des de el directori on s’ha descomprimit la distribució simple: "javac.exe" -O -classpath "src\;lib\ir.jar;lib\lucene-1.4.3.jar; lib\Multivalent.jar;lib\commons-collections-3.1.jar;lib\jung-1.6.0.jar; lib\PDFBox-0.7.1.jar;lib\Tidy.jar;lib\jcommon-1.0.0-rc1.jar; lib\jfreechart-1.0.0-rc1.jar;lib\jfreechart-1.0.0-rc1.zip; lib\log4j-1.2.9.jar;lib\xercesImpl.jar;lib\poi-2.5.1-final-20040804.jar; lib\poi-scratchpad-2.5.1-final-20040804.jar;lib\HTTPClient.zip" -d "classes" "src\AplicacioPrincipal.java" Aquest procediment de compilació no s’ha provat en Linux, tanmateix el resultat també hauria de concloure amb èxit. Un cop finalitzada la compilaci´ o, cal crear el contenidor Toke.jar que acompanya l’aplicació i contindrà els fitxers .class generats durant la compilació i un fitxer amb el classpath necessari per executar el conjunt. cd classes jar cmf ..\manifest.txt ..\Toke.jar *.class

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.1: Sel·lecció de l’eina d’exploració Arribats a aquest punt, tindrem l’aplicació recompilada i llesta per executar, però és important remarcar que totes les distribucions de l’aplicació ja venen compilades i preparades per funcionar. L’execuci´ o manual de l’aplicaci´ o es fa seguint el seg¨ uent exemple, des de el directori on s’ha descomprimit la distribuci´ o simple (si seguim l’exemple anterior, caldria fer cd .. per tornar al directori inicial): java -jar Toke.jar Amb això és suficient per executar-ho, però els qui siguin més puristes també poden executar l’aplicació de la seg¨ uent manera, encara que no es la manera més elegant: "java.exe" -classpath "classes\;lib\ir.jar;lib\lucene-1.4.3.jar; lib\Multivalent.jar;lib\commons-collections-3.1.jar;lib\jung-1.6.0.jar; lib\PDFBox-0.7.1.jar;lib\Tidy.jar;lib\jcommon-1.0.0-rc1.jar; lib\jfreechart-1.0.0-rc1.jar;lib\jfreechart-1.0.0-rc1.zip; lib\log4j-1.2.9.jar;lib\xercesImpl.jar;lib\poi-2.5.1-final-20040804.jar; lib\poi-scratchpad-2.5.1-final-20040804.jar;lib\HTTPClient.zip" AplicacioPrincipal

A.3

Explorar

L’execució del web crawler o eina d’exploració es fa clicant sobre el botó Explorar del men´ u d’inici ràpid. Aquesta eina ens ofereix un ampli ventall de funcionalitats per explorar grans quantitats de documents web, emmagatzemarlos al disc, realtizar estad´ıstiques, visualitar pàgines web en forma de graf, ´ important mencionar que es tracta d’una eina desenvolupada exetc. Es clusivament per a l’exploraci´ o de nodes i per al seu posterior tractament i indexaci´ o.

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.2: Interf´ıcie gr`afica de l’eina d’exploraci´o

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.3: Panells de control

A.3.1

Panells de control

L’eina d’exploració disposa d’una barra de control a la part superior de la pantalla. En aquesta barra podrem realitzar les seg¨ uents tasques: crear una nova exploraci´ o, carregar una exploració emmagatzemada, desar l’exploració actual, iniciar l’exploraci´ o, pausar l’exploració, aturar l’exploració i sortir de l’aplicació. Els fitxers d’exploració s’emmagatzemen automàticament al directori de la intranet, i tenen extensi´ o .exp. Es tracta de fitxers amb contingut ASCII de manera que poden ser editats amb qualsevol editor de text convencional. Per recuperar una exploraci´ o, cal clicar sobre el botó Obrir, el qual mostra tots els fitxers d’exploració generats en anteriors ocasions. Finalment cal clicar sobre el fitxer .exp desitjat. Per iniciar una exploraci´ o, prèviament caldrà configurar-la mitjan¸cant el panell de configuraci´ o, i després cal clicar al botó Iniciar. Aquesta operació té un comportament diferent amb les exploracions que s’han recuperat des de el disc, ja que en aquests casos l’exploració continuar` a des de l’´ ultim punt on es va deixar, a no ser que ja hagués finalitzat. Per pausar o aturar una exploraci´ o caldrà clicar sobre els botons Pausar i Aturar respectivament. El bot´ o Tancar tanca i surt l’aplicació. L’eina d’exploració proporciona sis panells amb diferents funcionalitats, des de panells de configuració fins a panells de monitorització i generació d’estad´ıstiques: Panell de configuraci´ o de l’exploraci´ o Es tracta d’un panell per configurar les exploracions. En aquest s’especifiquen aspectes tan importants com el nom de l’exploraci´ o, la URL inicial, la profunditat màxima d’ex-

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.4: Indicadors d’estat d’exploració ploració, el nombre de descàrregues simultànies, nombre de descàrregues simultànies per host, l’estratègia d’exploració, etc. Panell de resultats Aquest panell conté un subconjunt de panells dedicats a monitoritzar dades generades durant l’exploració en temps real. Per exemple, velocitats de descàrrega de cada fil d’execució, tamanys de fitxer més freq¨ uents, errors de descàrrega, tipus de fitxers més freq¨ uents, etc. Panell de l’arbre de nodes Mostra tots els fitxers descarregats realitzant una representaci´ o exacta del sistema de fitxers de cada host explorat. Amb aquesta eina es pot obtenir informació immediata de cada document web explorat o pendent de ser explorat, navegant a través de l’arbre de fitxers. Panell de la cua de pendents Mostra totes les URLs pendents d’explorar. La visualitzaci´ o es fa mostrant en una banda les URLs prioritàries i en l’altra les secundàries. Panell de graf d’enlla¸ cos Es tracta d’una eina per generar, visualitzar i tractar el graf composat pels hipervincles dels nodes explorats. Permet visualitzar només els nodes que satisfan determinades condicions, per exemple, visualitzar els nodes d’un determinat host o d’un determinat tipus. Panell d’Auto-LogIn Ofereix una eina per a obtenir i completar formularis web d’autentificació que ofereixen accés a zones restringides. Els formularis són emmagatzemats a disc i poden ser usats més endavant per a realitzar exploracions. A la part inferior de l’aplicació d’exploració es troben els indicadors d’estat d’exploració. Es tracta d’un conjunt d’indicadors que s’actualitzen cada 500ms durant el transcurs d’una exploració, mostren informació en temps real de l’exploraci´ o, aix´ı com el nombre de threads actius (descàrregues actives), pàgines web explorades (nombre de documents web descarregats i tractats exitosament), tamany total descarregat (tamany en bytes dels documents web descarregats exitosament), descàrregues fallides (nombre d’intents de descàrrega fallits), elements a la cua (nombre total d’URLs pendents de descarregar), hosts trobats (nombre de hosts descoverts fins al moment),

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.5: Panell de configuració ample de banda actual (l’ample de banda en kilobytes per segon usat en aquell instant), l’ample de banda màxim(màxim ample de banda assolit desde l’inici de l’exploraci´ o en kilobytes per segon) i l’´ ultim node explorat (´ ultima URL descarregada exitosament quan s’ha realitzat l’´ ultima comprovaci´ o).

A.3.2

Configuraci´ o de par` ametres d’exploraci´ o

El panell de configuraci´ o permet establir els paràmetres inicial d’exploració. El panell es divideix en quatre àrees: web inicial, configuració exploració, dominis i extensions. A l’` area de web inicial, cal sel·leccionar el tipus d’exploració que es vol fer. Si s’escull explorar una àrea p´ ublica, cal indicar la URL inicial a la part de la dreta. Si s’escull explorar una àrea restringida cal indicar quin formulari usar. Els formularis es creen mitjan¸cant l’eina d’Auto-LogIn. A l’` area de configuraci´ o d’exploració cal indicar tots aquells paràmetres que afecten al comportament de l’exploració. Primerament cal posar un nom a l’exploraci´ o. Aquest serà el nom que tindrà el fitxer d’exploració que s’emmagatzemarà al disc i també serà el nom del directori on s’emmagatzemaran els fitxers descarregats a la Intranet. A continuació, cal indicar el nombre màxim de documents a descarregar, el nombre màxim de descàrregues si-

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

multànies, el nombre de descàrregues simultànies per host (que ha de ser menor o igual que el nombre màxim de descàrregues simultànies) i la profunditat màxima d’exploració (el nombre màxim d’enlla¸cos que hi pot haver entre el node inicial i qualsevol altre node a explorar). Després, cal indicar els aspectes que afecten a l’estratègia d’exploració. En aquest sentit, cal indicar si volem realitzar una exploració en amplada o una en profunditat. Caldr` a decidir si volem explorar els enlla¸cos externs o no. En cas afirmatiu, haurem d’indicar si volem donar prioritat a les descàrregues de fitxers que pertanyen al host inicial; en l’altre cas, haurem de decidir si volem explorar subdominis del mateix host inicial o no. De totes maneres, s’ha de decidir si sempre s’haurà de provar de descarregar el seg¨ uent node disponible o no. Per a més informació cal consultar l’apartat 2.4. Hi ha la possibilitat d’actualitzar i visualitzar els gràfics estad´ıstics en temps real, simplement activant l’opció Actualitzaci´ o autom` atica d’estad´ıstiques. També existeix la possibilitat de realitzar operacions d’auto-guardar exploracions de manera automàtica. Això es du a terme amb l’opció de Desar dades peri` odicament, on cal indicar-ne la periodicitat en minuts. Aquesta funcionalitat resulta especialment u ´til quan cal realitzar grans exploracions de llarga durada. Cal destacar finalment, la possibilitat d’utilitzar llistes de URLs prohibides, és a dir, URLs que no seran explorades. Aquestes llistes s’han de guardar al directori on hi ha la Intranet en format .txt. Aquests fitxers es poden composar amb qualsevol editor de text, de manera que cada l´ınia del fitxer ha de contenir una adre¸ca url. Prohibir l’exploració d’URLs pot resultar u ´til, per exemple, per evitar explorar pàgines web amb continguts que no ens interessen. A l’` area de dominis s’escullen els dominis que volem que s’explorin. En aquest sentit, s’exploren u ńicament aquelles URLs tals que el seu domini base no pertany al grup de dominis no seleccionats. El mateix passa a l’àrea d’extensions, on només s’exploren aquelles URLs tals que la seva extensió no pertany al grup d’extensions no seleccionades.

A.3.3

Panells de monitoritzaci´ o i estad´ıstiques

Els panells de monitorització tenen per objectiu mostrar gràficament les estad´ıstiques acumulades de l’exploració. Es divideixen en sis panells diferents. Si hi ha activada l’opci´ o d’actualitzar automàticament les estad´ıstiques, aleshores les visualitzacions de les gràfiques s’actualitzen cada 500ms, altrament caldrà clicar sobre el botó Actualitzar de cada panell per a actualitzar

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.6: Indicadors gràfics de les velocitats de descàrrega els gràfics. Threads Mostra els fitxers que descarreguen cada thread. De cada thread es visualitza gràficament la seva velocitat de descàrrega, la URL del fitxer que està descarregat i la icona associada a l’extensió del fitxer que descarrega. Tamanys Mostra un histograma de tamanys. Es tracta d’un histograma creat a partir dels tamanys dels documents web descarregats amb èxit. Incid` encies Mostra un gràfic de roda indicant els percentatges de cada tipus d’error detectat. El percentatge es basa sobre tots aquells fitxers que han fallat al descarregar-los. A la taula de la dreta, es mostra el nombre exacte de fallides de cada tipus, la suma de tots els valors és igual al nombre de descàrregues fallides. Dominis Mostra un gràfica de roda indicant els percentatges de presència de fitxers de cada domini. El percentatge es basa sobre tots aquells fitxers que han estat descarregats amb èxit. A la taula de la dreta, es mostra el nombre exacte de fitxers explorats de cada domini. La suma de tots els valors és igual al nombre de descàrregues exitoses. Extensions Mostra una gràfica de roda indicant els percentatges de presència de fitxers de cada tipus d’extensió. El percentatge es basa sobre tots aquells fitxers que han estat descarregats amb èxit. A la taula de la dreta, es mostra

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.7: Histograma de tamanys

Figura A.8: Gr`afic d’incid`encies

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.9: Gràfic de dominis el nombre exacte de fitxers explorats de cada tipus d’extensió. La suma de tots els valors és igual al nombre de descàrregues exitoses. Resum Mostra un resum de tots els gràfics en un u ńic panell. Això permet veure l’evolució en temps real de tots ells en una sola vista.

A.3.4

Exploraci´ o - Operacions b` asiques

En aquest apartat s’expliquen els passos bàsics que cal fer per realitzar l’exploraci´ o d’un lloc web p´ ublic. Per a fer-ho, seguirem un exemple en el qual es pretèn explorar els nodes web del host www.etse.urv.es i tots els seus subdominis. Per tant, primer cal executar l’aplicaci´ o i esperar a que es carregui el men´ u d’inici ràpid. Escollir l’operaci´ o explorar El men´ u d’inici ràpid ens ofereix accés a les tres operacions principals del programa: explorar, indexar i cercar. Escollirem la primera opci´ o, explorar, tal i com es mostra a la figura A.1. Comen¸ car una nova exploraci´ o Un cop carregada l’eina d’exploració, caldrà comen¸car una nova exploració. Per fer-ho cal clicar sobre el botó Nova exploraci´ o del men´ u superior, mitjan¸cant el qual apareixeran tots els panells de control. A partir d’aquest punt caldrà comen¸car a configurar l’exploraci´ o.

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.10: Gr`afic d’extensions

Figura A.11: Resum de tots els panells de resultats

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.12: Exploració p´ ublica del lloc web www.etse.urv.es Configurar l’exploraci´ o La configuració de l’exploració es fa mitjan¸cant el panell de configuraci´ o. L’accés a cadascun dels panells de control es fa clicant sobre les corresponents solapes de la part esquerra de la pantalla. Inicialment ja es visualitza el panell de configuració, per tant, no caldrà recòrrer a l’´ us de la solapa de configuració. Realitzarem una exploració p´ ublica sobre el host www.etse.urv.es tal i com s’ha dit al principi, per tant, cal aplicar els seg¨ uents passos: Indicar la web inicial Indicarem primer que volem realitzar una Exploraci´ o d’una a `rea p´ ublica, i inserirem l’adre¸ca URL del lloc web www.etse.urv.es ´ important l’elecció que fem de la URL d’inici, a l’` area de text de la dreta. Es ja que cal posar sempre l’adre¸ca del node arrel del lloc web que pretenguem explorar. Mirar la figura A.12. Posar un nom a l’exploraci´ o Ara cal ajustar els paràmetres de l’exploració. Primer de tot, cal posar un nom a l’exploració, que hauria d’anar d’acord amb el t´ıtol o tema del lloc web a explorar. En aquest cas ETSE ´ important usar noms amb lletres exclusivament seria un nom raonable. Es alfanumèriques, és a dir, paraules de l’alfabet o nombres sencers, ja que alguns s´ımbols tipogràfics poden no ser admesos pel sistema de fitxers del sistema operatiu. Ajustar els par` ametres d’exploraci´ o A continuació, cal especificar els paràmetres tècnics que afecten indirectament al comportament de l’estratègia d’exploració. El valor del nombre total de pàgines a descarregar es pot deixar intacte, a no ser que ens interessi explorar un nombre concret de documents. El nombre de descàrregues simultànies per defecte és cinc, encara que si disposem d’una connexió amb un ample de banda considerable podem posar el valor a deu, o fins i tot a quinze si el host a explorar es troba a la mateixa LAN. El nombre de descàrregues simultànies per host és dos per defecte. Decidir aquest valor no és fàcil, ja que depèn del host a explorar, tanmateix usar valors entre dos i quatre pot ser acceptable. La profunditat d’exploració dependrà de si volem fer una petita exploració o bé una exploraci´ o a gran escala. En el primer cas una profunditat entre tres i cinc és suficient, en el segon cal usar profunditats majors o iguals a set.

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.13: ` area de configuraci´o d’exploraci´o

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

´ important recordar que normalment els nodes més profunds acostumen Es a ser els que menys ens interessen. Mirar la figura A.13. Ajustar els par` ametres estrat` egics A continuació, cal especificar els paràmetres tècnics que afecten directament al comportament de l’estratègia d’exploració. La funcionalitat dels seg¨ uents paràmetres, s’explica detalladament a l’apartat 2.4 referent als paràmetres i configuracions de l’exploraci´ o web. La casella Explorar enlla¸cos externs la desmarquem, ja que ens interessar` a explorar u ńicament aquells documents que pertanyen al host www.etse.urv.es. Aix´ı doncs, deixarem marcada la casella Explorar hosts del domini ja que també volem explorar documents que pertanyen a subdominis del host inicial, com ara, www.subdomini.etse.urv.es o www.subsubdomini.subdomini.etse.urv.es. Deixarem també marcada la casella Sempre explorar el seg¨ uent disponible. Finalment, escollirem l’estratègia d’exploració basada en la Cerca Depth-First. Mirar la figura A.13. Ajustar els par` ametres funcionals Si marquem la casella Actualitzaci´ o autom` atica d’estad´ıstiques, ens estalviarem haver de clicar sobre els botons d’actualitzar dels panells de monitorització i estad´ıstiques durant l’exploraci´ o, ja que aleshores s’actualitzarien automàticament cada 500ms. Ens pot resultar interessant per veure l’evolució dels resultats en temps re´ important remarcar que l’actualització al, però la deixarem desactivada. Es automàtica suposa un cost addicional important de l’´ us de CPU en màquines lentes. El que si que activarem serà l’opció de desar automàticament l’exploració, d’aquesta manera l’aplicació anirà desant al disc l’estat actual de l’exploraci´ o en cada moment. En exploracions llargues cal posar una periodicitat alta superior a quinze o vint minuts, mentre que amb exploracions de curta durada es poden posar periodicitats d’entre dos i cinc minuts. Per acabar, podem decidir usar una llista amb URLs prohibides, tanmateix en aquest exemple no n’usarem cap. Mirar la figura A.13. Escollir els dominis i les extensions Ara cal seleccionar els dominis i extensions dels fitxers que volem que s’explorin, de manera que els que no s’escullin no seran explorats. Mirar la figura A.14. Iniciar l’exploraci´ o En aquests moments ja podem iniciar l’exploració. Cal clicar sobre el bot´ o Iniciar del men´ u superior; una caixa de missatge ens avisar` a que l’exploraci´ o comen¸carà. En aquest moment l’exploració es posarà en marxa i podrem observar com tots els documents descarregats s’emmagatzemen a la carpeta \intranet\ETSE de l’ordinador. En qualsevol moment podem pausar o aturar l’exploració fent u ´s del men´ u superior. L’exploració finalitza sense avisar, de manera que sabrem que aquesta ha acabat

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.14: `arees de dominis i extensions

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

quan els indicadors de la part inferior de la pantalla indiquin que hi ha zero threads actius. Visualitzar l’arbre d’exploraci´ o L’arbre d’exploració permet visualitzar tots els nodes explorats en forma d’arbre, simulant el sistema de fitxers de cada host explorat. Consta d’una llista de hosts a la part esquerra i un arbre de directoris i fitxers a la part dreta. Per poder disposar en qualsevol moment dels u ´ltims estats dels arbres, caldrà clicar sobre el botó Actualitzar llista de la part inferior del panell. Un cop hi haguem clicat tindrem la llista actualitzada i llesta per usar, aix´ı doncs, clicant sobre algun dels hosts d’aquesta, es visualitzarà a la dreta el corresponent arbre. Podem desplegar directoris de l’arbre per poder veure’n els seus continguts, de la mateixa manera, clicant sobre cada node de l’arbre obtindrem informació d’aquests als indicadors inferiors. Mitjan¸cant els filtres de la part superior del panell podrem visualitzar tots els nodes, els nodes que han fallat, els nodes explorats o els nodes pendents de descarregar respectivament. Quan s’escull un filtre cal tornar a escollir el host de la llista de l’esquerra. Mirar la figura A.15. Visualitzar la cua de pendents La cua de pendents permet visualitzar les URLs que resten pendents de ser explorades. A la banda esquerra es mostren les URLs priorit` aries, mentre que a la banda dreta es mostren les URLs secundàries o no prioritàries.

A.3.5

Explorar una ` area restringida

Les exploracions en ` arees restringides difereixen de les p´ ubliques, en el fet que cal completar un formulari previ d’autentificació i enviar-lo abans de descarregar la URL d’acció. Per a la tasca d’obtenció i completació del formulari s’ha d’utilitzar l’eina d’Auto-LogIn que inclou el programa. L’accés a aquesta eina es fa clicant sobre la solapa Auto-LogIn. En aquest cas, provarem d’explorar un compte de correu d’usuari a través del servei de webmail que ofereix el lloc web www.queenzone.com. Indicar la URL del formulari d’identificaci´ o Primer cal inserir la URL on hi ha el formulari d’identificació. Cal estar segur que la URL inserida és realment la URL que conté el formulari, ja que és habitual trobar pàgines web autoredireccionades cap a altres URLs, i per tant, es fàcil pensar que la URL que conté el formulari és la que es apareix a la barra de direcció dels clients web. Un cop inserida la url, caldrà clicar sobre el botó Extreure formularis. Seleccionar el formulari Després de clicar sobre el botó d’extracció de formularis, l’aplicació descarregarà la pàgina web i després extreurà tots els

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.15: Arbre d’exploracions

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

100

formularis que pugui contenir. Un cop finalitzi l’extracci´ o, apareixeran els noms de tots els formularis extrets a la llista de la part esquerra. A la part inferior de la llista apareix el nombre de formularis trobats. No existeix una forma concreta de saber quin és el formulari que cal utilitzar, per tant, cal clicar sobre dels formularis per poder veure els seus continguts a la taula de la part central. Inserir el login i la contrasenya Saber quin és el formulari que cal omplir no és trivial, a no ser que només hi hagi un sol formulari. Al clicar a sobre del formulari desitjat de la llista, podrem veure’n el seu contingut a la taula central de l’aplicació. En aquesta tindrem a la columna de l’esquerra els noms dels camps, mentre que a la columna de la dreta tindrem els corresponents valors. Els noms dels camps els assignen els desenvolupadors de pàgines web, de manera que el camp del login i de la contrasenya haurien de tenir noms abreviats relacionats. Hi poden haver camps que ja portin un valor, en aquests casos no s’ha de modificar el valor ja que es pot tractar d’identificadors de sessi´ o. Ja que l’aplicació no té manera d’averiguar quin és el camp de la contrasenya, l’usuari escriurà aquesta sabent que pot ser visualitzada a través del monitor al moment d’inserir-la. Posar un nom al formulari i desar-lo Un cop s’han omplert els camps, cal posar un nom al formulari a l’àrea de text Nom per al formulari. Cal posar un nom adequat, en aquest exemple Compte de correu Queenzone seria el més adient. Un cop fets tots els passos anteriors, caldrà desar el formulari al disc clicant sobre el botó Desar formulari. Si tot ha anat bé, ens apareixerà una caixa de missatge indicant-ho. Configurar i iniciar l’exploraci´ o En aquest punt és moment de configurar i iniciar l’exploraci´ o. Caldrà accedir al panell de la pestanya de configuració. A l’` area Web inicial haurem d’indicar que volem realitzar una exploraci´ o en una ` area restringida. Aleshores, haurem de seleccionar el formulari d’accés que hem composat amb l’eina d’Auto-LogIn. Com que podrem composar varis formularis, haurem d’escollir el que té el nom Compte de correu Queenzone. La resta de passos de configuració seran exactament els mateixos que cal realitzar amb l’exemple de l’exploració p´ ublica anterior. Un cop s’hagin definit tots els paràmetres de configuració, iniciarem l’exploraci´ o clicant sobre el botó Iniciar. Acceptar les Cookies Els llocs web que disposen de zones d’accés restringit, acostumen a requerir l’´ us de les cookies, ja sigui per emmagatzemar i recollir informació de sessi´ o o d’altre tipus. El seu u ´s ha d’estar autoritzat per l’usuari, exactament tal i com passa amb la resta de clients web. Es per això que durant la fase inicial de l’exploració poden aparèixer q¨ uestionaris

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

101

preguntant a l’usuari si vol acceptar o refusar l’acc´es a les cookies. Per anar b´e, cal acceptar totes les solicituts que apareguin. Una mostra seria la que apareix a la figura .

A.3.6

Visualitzaci´ o de grafs

Una de les principals funcionalitats de l’aplicació es la composició i visualitzaci´ o de les exploracions en forma de graf. Consisteix en generar un graf a partir dels nodes web descoberts i els hipervincles que hi ha entre ells. ´ important remarcar que es tracta d’una eina per a la visualització de Es grafs de petita escala, ja que pel tractament de grafs de grans dimensions fa falta disposar d’un ordinador amb una elevada velocitat de processament. Seguint amb l’exemple de l’exploració del lloc web www.etse.urv.es, podrem generar i visualitzar el graf accedint al panell de la pestanya Graf enlla¸cos i clicant sobre el botó Mapa de nodes. Actualitzaci´ o, visualitzaci´ o i renderitzaci´ o del graf Al clicar sobre el bot´ o Mapa de nodes, s’obrirà una nova finestra on podrem treballar amb el graf, de manera que podem obrir tantes finestres de grafs com convingui. Inicialment, caldrà obtenir i carregar el graf. Això es fa clicant sobre el bot´ o Actualitzar graf. Aquest procés obté les u ´ltimes dades necessàries per composar el graf i visualitzar-lo a l’àrea de visualització central. L’actualització del graf es pot fer m´ ultiples vegades durant el transcurs d’una exploraci´ o, de manera que sempre podrem treballar amb els u ´ltims nodes descoberts. La visualitzaci´ o i estabilització del graf és una tasca molt lenta i costosa, a més a més, és fàcil deduir-ho ja que el consum de CPU es dispara. Aquesta tasca no finalitza mai, és per això que l’usuari ha de decidir quan vol aturar la renderització del graf per alliberar el consum continu de CPU, clicant sobre el bot´ o Aturar. Si no agrada com ha quedat posicionat el graf, podem saccejarlo de nou, ja sigui recarregant-lo clicant sobre el botó Actualitzar graf o bé clicant sobre el bot´ o Repintar graf que és lleugerament més ràpid. Informaci´ o dels nodes i significat dels colors Cada node té un color en funció del host al qual pertany, de manera que per a cada host hi ha assignat un color a l’atzar. Els nodes amb ratlles verdes són nodes pendents d’explorar, és a dir, encara estan a la cua de nodes pendents. Una peculiaritat d’aquests nodes és que no tenen arestes de sortida. Els nodes amb ratlles vermelles són nodes que han fallat alhora de descarregar-los.

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

102

Podem obtenir informació inmediata d’un node simplement, posicionant el cursor del ratol´ı sobre d’ell. Fent això apareixerà un missatge flotant al costat del node, on s’hi mostra la URL, l’estat, els enlla¸cos sortints i entrants, i el tipus del node en q¨ uestió. A més a més, podem veure la URL sencera del node a la part inferior de la finestra. Al costat de l’indicador d’URL, tenim a disposició dos indicadors numèrics que ens indiquen el nombre de nodes que hi ha al graf i el nombre d’arestes que té, tot i que és important remarcar que el contingut d’aquests indicadors fan referència al graf sencer original i no varien encara que apliquem filtres visuals sobre el graf. Llista de hosts A la part superior dreta de la pantalla, hi ha a disposició de l’usuari una llista amb tots els hosts descoberts. Es tracta de la mateixa llista que apareix al panell d’arbre de nodes, però en aquesta llista el primer element, anomenat [ Tots ], sempre fa referència a tots els hosts. Clicant sobre un host estem aplicant un filtre visual sobre tot el graf, de manera que només es visualitzen els nodes del host seleccionat. Efectes visuals La pestanya Visual de la part dreta permet accedir al panell d’efectes visuals. Amb aquest panell podem aplicar efectes visuals sobre el graf. Marcant la casella Mostrar URLs es visualitzen les URLs de cada node del graf al costat d’aquests, resulta u ´til quan el graf té pocs nodes. La casella Mostrar pesos dels enlla¸cos permet visualitzar el pes de cada aresta del graf. El pes d’una aresta és la profunditat d’aquesta respecte el node inicial. Mitjan¸cant el subpanell Forma de les arestes podrem canviar la forma de les arestes, ja sigui en forma linial, corba simple, doble linial i doble corba. Amb el subpanell Zoom, podem ampliar i redu¨ır la visualització del graf. Aquesta funcionalitat també es pot realitzar amb la rodeta del ratol´ı. De manera similar, amb el ratol´ı podem despla¸car la posició del graf arrastrantlo, és a dir, clicant sobre una part del graf no ocupada per nodes ni arestes i movent alhora el cursor de ratol´ı. Filtres URL Els filtres URL són filtres visuals per visualitzar només aquells nodes tals que la seva URL satisf` a unes condicions. Per accedir a aquests filtres, caldrà clicar sobre la pestanya Filtre URL. En aquesta panell tenim accés quatre filtres diferents. Els filtres es poden usar de forma combinada, de manera que, per exemple, podrem filtrar els nodes en funció dels seus hosts i extensions alhora. Per usar un filtre, cal marcar la seva corresponent casella i

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

103

deprés omplir l’` area de text de la seva dreta. El filtre de hosts permet visualitzar només aquells nodes tals que el seu host es troba a l` area de text. Podem inserir tans elements a les àrees de text com volguem, però han d’anar separats per espais. Per exemple, si volem visualitzar només els nodes que pertanyen als hosts www.gnu.org, www.etse.urv.es i www.domini.etse.urv.es, primer caldrà marcar la casella dels hosts i després inserir els hosts a la corresponent àrea de text separats per espais. El procediment és idèntic amb els filtres de ruta, fitxer i extensió. El filtre de ruta permet visualitzar els nodes tals que el seu fitxer es troba dins d’una ruta concreta del seu host, per exemple, /a/b/c/. El filtre de fitxer funciona igual que l’anterior però cal indicar un o varis fitxers, per exemple, index.html o login.php. El filtre d’extensió és similar, en aquest cas cal indicar les extensions que volem que tinguin els nodes que volem visualitzar, per exemple, .pdf o .txt.

A.4

Indexar

L’accés a l’eina d’indexació es fa clicant sobre la icona Indexar del men´ u d’inici ràpid, tal i com es mostra a la figura A.20. Aquesta part de l’aplicació s’encarrega de generar ´ındexs seguint els procediments explicats a l’apartat 3 referent a l’extracci´ o i indexació d’informació.

A.4.1

Configuraci´ o dels par` ametres d’indexaci´ o

L’eina d’indexació es divideix en quatre àrees. A l’àrea d’exploracions hi ha llistades totes les exploracions emmagatzemades a la Intranet del disc, és a dir, a la ruta d’Intranet definida al fitxer rutes.cfg. A l’àrea de configuració és on cal configurar prèviament l’indexació i cal definir el nom de l’´ındex a crear, el nombre de fils d’execució simultanis, seleccionar les exploracions que volem que quedin indexades, indicar si volem crear un fitxer de freq¨ uències de paraules, indicar si volem utilitzar un fitxer d’StopWords, i finalment cal indicar les extensions de fitxers que volem que s’indexin. A l’` area d’´ındexs actuals hi trobarem la llista d’´ındexs que s’han creat fins al moment, i que es troben emmagatzemats al directori d’´ındexs definit al fitxer rutes.cfg. Mitjan¸cant el botó Eliminar ´ındex podrem eliminar l’´ındex que nosaltres marquem, sense previ av´ıs de confirmació. Finalment, a l’` area d’estat de la indexaci´ o s’hi troben els indicadors. Aquests indicadors mostren informació relativa al transcurs de la indexació, aix´ı com el nombre de fils d’indexació actius, el nombre de documents indexats, la quantitat indexada, etc.

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.16: www.etse.urv.es

104

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.17: www.cnn.com

105

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.18: www.udl.es

106

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.19: surf.de.uu.net

107

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

108

Figura A.20: Selecció de l’eina d’indexació La barra de progrés de l’` area d’estat és la que es troba a la part inferior de la finestra. Mostra visualment l’evolució de la indexació i reflexa la proporció de documents indexats i la proporció de documents que resten. Durant una indexaci´ o, la barra de progrés es reinicia a zero en funció del nombre d’exploracions que s’indexin, és a dir, si estem creant un ´ındex a partir de tres exploracions que hem seleccionat, la barra es reiniciarà tres vegades, i per a cada exploració la barra incrementarà del zero al cent per cent. Això es pot observar mitjan¸cant els indicadors numèrics que conté a la seva part central.

A.4.2

Indexar - Operacions b` asiques

En les pròximes l´ınies, es seguirà amb el mateix exemple de l’apartat A.3.4, en el que s’explica detalladament els procediments que cal seguir per explorar el lloc web www.etse.urv.es. Ara s’indicaran els passos per a realitzar-ne el corresponent ´ındex, tenint en compte que voldrem generar, a més a més, un fitxer de freq¨ uències de paraules amb les vint paraules més freq¨ uents a tot el conjunt de documents que conformen l’exploració o exploracions escollides. Crear un nou ´ındex Per comen¸car a configurar un nou ´ındex cal clicar sobre el bot´ o Nou ´ındex del panell de botons de la part superior de la finestra. Un cop fet això ja podem comen¸car a configurar-ho. Anomenar l’´ındex i escollir les exploracions Primer de tot cal posar un nom al nou ´ındex, caldrà inserir el nom a l’àrea de text indicada per Nom ´ındex. El nom d’un ´ındex ha de contenir text alfanumèric, és a dir, només lletres i n´ umeros, ja que es crearà al directori d’´ındexs un subdirectori amb el nom que posem, i per tant, cal utilitzar caràcters suportats pel sistema de fitxers del sistema operatiu. En aquest exemple podem posar ETSE com

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.21: Interf´ıcie gr`afica de l’eina d’indexaci´o

109

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

110

biblioteca urv servei document recursos documents informacio revistes cap fons 0 0 0 0 0 0 0 0 0 0 www.etse.urv.es 0 0 0 0 0 0 1 0 0 0 www.etse.urv.es/InfoEscola/InfoGeneral/general.htm 1 21 0 0 1 0 1 0 0 0 www.etse.urv.es/InfoEscola/Directori/directoriVell.htm 0 1 0 0 0 0 1 0 0 0 www.etse.urv.es/InfoEscola/InfoAcademica/general.htm 0 1 0 0 0 0 0 0 0 0 www.etse.urv.es/InfoEscola/recerca/recerca.htm 2 2 1 36 2 0 3 2 0 2 www.etse.urv.es/bibweb 2 1 1 0 0 0 2 0 0 0 www.etse.urv.es/bibweb/pages/informacio_general/ig_3.php 3 1 1 0 0 0 2 0 0 0 www.etse.urv.es/bibweb/pages/informacio_general/ig_1.php 3 2 1 0 0 0 2 0 0 0 www.etse.urv.es/bibweb/pages/informacio_general/ig_2.php 5 17 1 0 0 0 2 0 6 0 www.etse.urv.es/bibweb/pages/informacio_general/ig_5.php 7 3 3 0 0 0 3 0 0 0 www.etse.urv.es/bibweb/pages/informacio_general/ig_8.php 191 85 106 22 4 78 7 2 70 34 www.etse.urv.es/bibweb/pages/informacio_general/ig_6.php 9 2 0 0 2 0 2 2 0 0 www.etse.urv.es/bibweb/pages/informacio_general/hist_engiweb/historia.html 1 0 0 0 4 0 3 2 0 2 www.etse.urv.es/bibweb/pages/recursos_informacio.php 2 1 1 0 4 0 2 3 0 2 www.etse.urv.es/bibweb/pages/recursos_informacio/ri_2.php 1 0 0 0 3 0 2 2 0 2 www.etse.urv.es/bibweb/pages/recursos_informacio/ri_7.php 2 0 0 0 3 0 2 2 0 6 www.etse.urv.es/bibweb/pages/recursos_informacio/fons_antic.php 2 0 0 0 3 0 2 2 0 4 www.etse.urv.es/bibweb/pages/recursos_informacio/fons_infantil.php 2 0 0 0 3 0 3 2 0 2 www.etse.urv.es/bibweb/pages/recursos_informacio/llibres_text.php 1 1 0 0 3 0 2 2 0 2 www.etse.urv.es/bibweb/pages/recursos_informacio/ri_5.php 3 0 0 0 4 0 2 2 0 2 www.etse.urv.es/bibweb/pages/recursos_informacio/ri_6.php 5 1 0 0 3 0 2 2 0 2 www.etse.urv.es/bibweb/pages/recursos_informacio/ri_9.php 1 0 0 0 3 0 2 2 0 2 www.etse.urv.es/bibweb/pages/recursos_informacio/ri_4.php 1 0 0 0 3 0 2 8 0 2 www.etse.urv.es/bibweb/pages/recursos_informacio/ri_3.php 5 4 0 0 3 0 2 18 0 3 www.etse.urv.es/bibweb/pages/recursos_informacio/ri_8.php 1 0 0 0 0 0 0 0 0 0 www.etse.urv.es/bibweb/pages/assignatures.php 2 1 1 0 0 0 3 0 0 0 www.etse.urv.es/bibweb/pages/informacio_general.php 1 0 0 0 0 0 1 0 0 0 www.etse.urv.es/bibweb/pages/utilitats.php 12 3 1 2 3 3 3 7 0 0 www.etse.urv.es/bibweb/pages/utilitats/ut_3.php 3 0 1 3 0 1 2 0 0 0 www.etse.urv.es/bibweb/pages/utilitats/ut_2.php 1 0 0 0 0 0 0 0 0 0 www.etse.urv.es/bibweb/pages/serveis.php 1 0 0 0 0 2 0 0 0 0 www.etse.urv.es/bibweb/pages/serveis/se_1.php 2 2 2 1 0 3 0 0 1 1 www.etse.urv.es/bibweb/pages/serveis/se_2.php 2 0 0 0 0 0 1 3 0 0 www.etse.urv.es/bibweb/pages/serveis/se_6.php 3 0 0 0 0 0 1 0 1 0 www.etse.urv.es/bibweb/pages/serveis/se_8.php 3 0 0 0 0 0 0 0 0 0 www.etse.urv.es/bibweb/pages/serveis/se_5.php 8 4 1 1 0 0 2 0 0 2 www.etse.urv.es/bibweb/pages/garriga_mata/Fundaci%F3_Garriga_de_Mata.php 2 2 1 36 2 0 3 2 0 2 www.etse.urv.es/bibweb/index.php 1 0 0 0 3 0 2 2 0 2 www.etse.urv.es/bibweb/Psicologia/tests.php 6 1 3 0 31 3 8 16 0 0 www.etse.urv.es/bibweb/Psicologia/recursos_temes.htm 0 0 0 0 0 0 9 0 0 0 www.etse.urv.es/avinterna/general.htm 0 0 0 0 6 0 0 0 0 0 www.etse.urv.es/eleccions/calendari_electoral_2005.htm 1 0 3 0 0 0 0 0 0 0 www.etse.urv.es/guia_docent

Figura A.22: Fitxer de freq¨ u`encies de paraules (www.etse.urv.es)

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

111

a nom. A continuació cal escollir les exploracions de la llista de l’esquerra a la llista d’exploracions escollides de la dreta. Cal clicar sobre l’exploració ETSE que hem realitzat anteriorment, i a continuació cal clicar sobre el bot´ o Afegir. Seguint aquest u ´ltim procediment vàries vegades podrem afegir m´ ultiples exploracions. Configurar Ara s’ha d’indicar el nombre de fils d’indexació simultanis que s’utilitzaran. Per defecte n’hi ha quatre, tot i que se’n poden posar més. Com que volem crear un fitxers de freq¨ uències, marcarem la casella Generar fitxers de freq¨ uències de paraules i indicarem que volem que analitzi les vint paraules més freq¨ uents en tot el conjunt d’exploracions escollides. El fitxer que es crear` a tindr` a el mateix nom que hem indicat i extenció .txt. A continuació marcarem la casella Usar llista de StopWords ja que el contingut de l’exploraci´ o està en catal` a i volem que descarti els StopWords. Un cop fet això, cal escollir el fitxer clicant sobre el botó Obrir. Podrem veure totes les llistes d’StopWords disponibles que ja venen amb l’aplicació, les quals es troben al subdirectori stopwords del directori de l’aplicació. Finalment, caldrà indicar les extensions que volem que s’indexin. En aquest cas volem que s’indexin tots els documents i per tant ho deixarem emmarcat tal i com està. Iniciar la indexaci´ o En aquest moment l’aplicació ja està configurada. Clicarem sobre el bot´ o Indexar del panell de botons de control de la part superior de la finestra. Si tot està bé, una caixa de missatge ens indicarà que el procés comen¸carà. Quan finalitzi el procés, una nova caixa de missatge ens ho farà saber. Observarem que el nou ´ındex apareixerà a la llista d’´ındexs actuals de la dreta de la finestra.

A.5

Cercar

L’accés a les eines de cerca es fa clicant sobre la icona Cercar del men´ u d’inici ràpid, tal i com es mostra a la figura A.23. Això obrirà el men´ u d’aplicacions de cerca, mitjan¸cant el qual podem escollir dos operacions: Realitzar cerques locals o remotes, o iniciar el servidor de cerques.

A.5.1

Cercar en un ´ındex local

Seguint amb l’exemple de l’exploració del host www.etse.urv.es i el seu corresponent ´ındex, realitzarem ara una cerca de continguts. Ha de quedar clar que les cerques es realitzen sobre els ´ındexs creats, i no sobre els fitxers d’exploració. Primerament cal escollir l’operació Cerca local o remota del men´ u d’aplicacions de cerca, tal i com es mostra a la figura A.24. En aquest exemple, provarem de cercar aquells documents que contenen les paraules software i lliure a l’´ındex ETSE.

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.23: Selecci´o de l’eina de cerca

Figura A.24: Selecci´o de l’eina de cerca local o remota

112

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

113

Marcar els ´ındexs Cal marcar els ´ındexs locals sobre els quals es realitzarà la cerca. Per a marcar m´ ultiples ´ındexs cal mantenir la tecla Ctrl. apretada i amb el ratol´ı cal marcar els ´ındexs desitjats. En aquest cas només es marcarà l’´ındex ETSE. Inserir les paraules i realitzar la cerca Cal accedir al panell de cerca clicant sobre la pestanya Cerca. A continuació, s’insereixen les paraules software i lliure, separades per un espai, a l’area de text i finalment cal clicar sobre el bot´ o Cercar. Interpretaci´ o i visualitzaci´ o dels resultats Si s’han trobat documents, aleshores a la part inferior esquerra de la pantalla, un indicador ens dirà el nombre de documents que s’han trobat i les URLs aquest es llistaran a la llista de resultats. Podem veure informació relativa de cada document simplement clicant sobre la seva URL a la llista i finalment clicant sobre el bot´ o Mostrar de la part inferior. De cada document trobat es visualitza la seva URL, el t´ıtol, l’autor, la seva descripció, el tamany en bytes, i el seu cos o text en pla extret.

A.5.2

Cercar en un ´ındex remot

Les cerques remotes són cerques que es realitzen sobre servidors de cerca remots. A part d’aquest aspecte, tota la resta d’operacions es realitzen exactament igual que si es tractés d’una cerca local. En aquest sentit, cal conèixer l’adre¸ca IP o nom del host on hi ha actiu el servidor i realitzar passos que s’expliquen a continuació. Connectar-se i obtenir la llista d’´ındexs remots Al panell d’´ındexs de l’eina de cerca, cal marcar l’opció Usar ´ındexs remots i inserir l’adre¸ca IP o nom del host del servidor de cerques. Finalment, caldrà clicar sobre el bot´ o de la dreta per a establir la connexió. Si la connexió conclou amb èxit, aleshores s’obtindr` a la llista d’´ındexs que ofereix el servidor. En aquest punt, cal realitzar els mateixos procediments que s’apliquen per realitzar cerques sobre ´ındexs locals.

A.5.3

Montar un servidor de cerques

L’accés al servidor de cerques es fa clicant sobre la icona Servidor de cerques del men´ u d’aplicacions de cerca, tal i com es mostra a la figura A.26. Abans d’arrencar el servidor cal escollir els ´ındexs que volem que serveixi, d’aquesta manera, els clients només poden veure i realitzar cerques en els ´ındexs escollits al servidor. El funcionament és for¸ca simple, el servidor o bé s’arrenca, o bé s’atura.

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.25: Interf´ıcie gr`afica de l’eina de cerca

114

` ´ PER A L’USUARI APENDIX A. MANUAL D’APLICACIO

Figura A.26: Selecci´o del servidor de cerques

Figura A.27: Interf´ıcie gr`afica del servidor de cerques

115

Ap` endix B

Conclusi´ o i propostes per al futur Per concloure aquest treball, explicaré breument els motius que m’han condu¨ıt a desenvolupar un projecte d’aquestes caracter´ıstiques. Donaré també el meu punt de vista sobre els diferents aspectes relacionats amb tot el que he fet, i com ho he fet. La idea de desenvolupar un conjunt d’eines per explorar, indexar i cercar continguts web, havia sorgit inicialment com una proposta de treball plantejada pel tutor. Aquest projecte m’ha ofert la possibilitat d’aprendre nous coneixements que fins ara desconeixia, aix´ı com descobrir i utilitzar eines de desenvolupament de codi obert que no he tingut oportunitat d’utilitzar al llarg de la carrera. Des del meu punt de vista, valoro molt positivament els resultats que s’han obtingut amb aquest projecte, principalment perquè hi ha hagut una l´ınia de treball constant des de l’inici del cicle de desenvolupament fins al final. La primera fase, l’he dedicada completament a l’anàlisi i disseny de l’aplicació, era molt important definir el funcionament del web crawler, aix´ı com les seves estructures de dades i la interacció entre les diferents classes a implementar. Totes les decisions de disseny s’han près després de passar per un per´ıode de recolecció d’informació i documentació sobre el tema que calia treballar, aix´ı com de l’aprenentatge de totes les llibreries que calia utilitzar i que han estat explicades en apartats anteriors. La segona fase, ha estat dedicada exclusivament a la implementació de tot el codi font i a la realització de jocs de proves exhaustius per verificar el correcte funcionament de tot el conjunt desenvolupat.

116

` ´ I PROPOSTES PER AL FUTUR APENDIX B. CONCLUSIO

117

L’objectiu inicial s’ha assolit, i crec que s’han creat un conjunt d’eines u ´tils, que poden ser utilitzades per informàtics, administradors i desenvolupadors de llocs web, i en general per aquelles persones que tinguin especial interès o necessitat en indexar grans quantitats de documents web i real´ important remarcar la necessitat que tenen itzar cerques sobre aquests. Es algunes empreses o entitats en mantenir indexada la informació, ja que actualment generen grans quantitats de documents i hi ha una forta demanda en realitzar cerques i obtenir resultats ràpidament. A continuació, es deriven un seguit de propostes per a possibles futures versions del programa. • Permetre l’exploraci´ o d’àrees d’accés restringit mitjan¸cant l’´ us de connexions segures a través del protocol HTTPS. • Desenvolupar un sistema d’indexació distribu¨ıt, de manera que es puguin crear ´ındexs a partir d’exploracions realitzades en diferents màquines d’una xarxa. • Modificar la forma amb què es realitzen les exploracions, de manera que es reexplorin aquells documents tals que el seu contingut ha caducat o s’ha actualitzat dins d’un per´ıode de temps determinat. • Desenvolupar una llibreria o servlet que permeti realitzar consultes sobre els ´ındexs a través d’interf´ıcies web. • Dotar l’eina d’exploració de noves estratègies d’exploració. Les propostes anteriorment mencionades, obren les portes a futures l´ınies de treball, les quals no han estat desenvolupades en aquest projecte ja que des del principi no formaven part dels plans inicial establerts en aquest. Finalment queda dir que tot el material creat s’ha realitzat mitjan¸cant els seg¨ uents recursos i eines d’edició i desenvolupament: • Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08) • JCreator Pro v3.10.008 • JFormDesigner v2.0 • MiKTeX-e-TEX 2.4.1700 (2.2) (TEX Version 3.141592) • Adobe Photoshop v5.0 • Connexió telef` onica amb ADSL 512Kbps i mòdem 56kbps. • Equip Intel Pentium3(R) 796MHz 64MB de RAM (Windows XP) • Equip Intel Pentium4(R) 1,5GHz 128MB de RAM (Windows XP) • Equip Intel Pentium4(R) 3GHz 512MB de RAM (Windows XP)

Ap` endix C

Preguntes m´ es freq¨ uents Aquesta aplicaci´ o´ es software lliure. Aix` o que significa? Significa que aquesta aplicació és lliure en el sentit que amb total llibertat es pot executar, copiar, distribuir, estudiar, modificar i millorar. El mapa de nodes consumeix molta CPU. Aix` o ´ es normal? S´ı, és normal. La renderitzaci´ o i estabilització del graf és un procés que no finalitza mai, però és l’usuari qui decideix quan cal aturar la renderització, i per tant, poder alliberar l’´ us de CPU. Per a fer-ho cal clicar sobre el botó Aturar. Puc visualitzar qualsevol graf amb el mapa de nodes? Tot i que depèn principalment de les prestacions que tingui l’equip on s’executi l’aplicaci´ o, la resposta és no. Cal tenir en compte que quants més nodes i arestes tingui el graf, més lenta anirà l’aplicació, fins a cert punt que en alguns casos és pràcticament impossible poder treballar amb el graf. A efectes pr` actics, quina estrat` egia d’exploraci´ o´ es la millor? L’´ us d’aquesta aplicació hauria de ser per a realitzar exploracions de petita escala, en aquests casos resulta més adequat utilitzar l’estratègia Depth-First ja que consumeix menys recursos i el que interessa és explorar tots els nodes sense tenir en compte l’ordre en que es faci. L’estratègia Breadth-First és la més adequada quan cal realitzar exploracions de mitjana-gran escala, ja que en aquests casos no es pot determinar quan finalitzarà l’exploració i és important descarregar primer els nodes més interessants (els més propers al node inicial). Les exploracions a ` arees restringides conclouen sempre amb ` exit? ´ dif´ıcil assegurar si una exploració en una àrea privada conclourà amb èxit Es o no, entre d’altres coses, perquè tot i que l’enviament del formulari es pot haver realitzat correctament, no es pot determinar si el servidor ha donat per vàlides les dades enviades. En aquest cas els servidors no responen amb 118

` ´ FREQUENTS ¨ APENDIX C. PREGUNTES MES

119

un codi de retorn que ho indiqui espec´ıficament. El sistema d’exploració restringida ha estat provat exitosament amb servidors din` amics que corren usant PHP i Perl. Mentre exploro una ` area restringida, arriba un moment en que l’exploraci´ o finalitza, quan en realitat hi ha p` agines que crec que ´ normal ´ normal? Es s’haurien d’haver explorat i no s’ha fet. Es i acostuma a tenir solució. Algunes pàgines web dinàmiques utilitzen una adre¸ca URL per finalitzar la sessió que s’ha establert en el moment d’enviar el formulari. Això es coneix com el procés de logout, en el qual perdem o deixem de tenir accés a les pàgines d’accés restringit. Això és habitual en pàgines amb continguts dinàmics generats amb PHP. Solucionar això és tasca de l’usuari, ja que aquest ha de saber quina és la URL del servidor que realitza el logout. Normalment s’utilitzen URLs amb noms de fitxer com logout.html o logout.php. Per solucionar això, cal posar aquestes URL al fitxer d’URLs prohibides i marcar l’opció d’utilitzar un fitxer d’adreces prohibides abans d’iniciar l’exploració. Alguns servidors em deneguen la connexi´ o. Com ho puc evitar? Alguns servidors, com ara Google, acostumen a refusar les descàrregues de pàgines web quan hi realitzem conexions massives. En aquests casos l’exploraci´ o en surt perjudicada ja que no s’han configurat adientment els paràmetres de l’exploraci´ o. Cal limitar el nombre de descàrregues simultànies per host, ja que alguns servidors són molt restrictius en aquest aspecte. Estic explorant un lloc web i n’estic segur que hi ha p` agines que no s’han explorat. Falla alguna cosa? En realitat no es que falli res, però hi ha molts motius pels quals poden haver-hi hipervincles que s’ignorin. Tot i que sembli extrany, Internet està ple de pàgines web amb hipervincles mal formats, encara que alguns clients web utilitzen mètodes for¸ca sofisticats per corregir aquests vincles. Aquesta aplicació descarta qualsevol hipervincle que es consideri mal format, això es fa per accelerar el procés d’exploració. Estic explorant un lloc web amb un elevat contingut de codi Javascript. Per qu` e no s’exploren tots els hipervincles? El procés d’extracció d’hipervincles no té en compte els hipervincles continguts dins de codi Javascript, ja que només analitza codi estrictament HTML. Aquesta és una tasca pendent de cara al futur. Puc explorar llocs web amb seguretat, ´ es a dir, utilitzant el protocol https? De moment no. Les exploracions es realitzen sense utilitzar Secure Socket Layer. Alguns servidors admeten ambdós tipus de connexió, per tant, es recomana inserir la URL d’inici afegint el prefix http://.

` ´ FREQUENTS ¨ APENDIX C. PREGUNTES MES

120

Hi ha disponible una distribuci´ o per a Windows. Existeix una distribuci´ o preparada per al sistema Linux? No s’ha desenvolupat encara una distribuci´ o preparada per a Linux, encara que en el manual d’usuari d’aquesta documentaci´ o es descriuen detalladament els procediments que cal seguir per compilar i executar l’aplicació en qualsevol sistema operatiu on es pugui compilar o executar programes en Java. ´ normal L’aplicaci´ o indexadora no indexa alguns documents. Es aix` o? Hi ha casos en els què no es pot extreure el text d’alguns documents. ´ habitual Acostuma a passar amb els documents amb format PDF i DOC. Es trobar documents PDF mal formats per Internet, mentre que dels documents de Microsoft Word no sempre se’n poden extreure text ja que es tracta d’un format propietari. Amb els documents HTML també s’acostuma a trobar gran quantitat de documents mal formats, i que per tant són descartats durant el procés d’indexació. Els fitxers es descarreguen, per defecte, al directori /intranet del disc. Puc canviar-ho? S´ı, es pot canviar. Cal editar el fitxer rutes.cfg que hi ha al directori de l’aplicació. Es tracta d’un fitxer de text que conté les rutes on s’emmagatzemen els fitxers descarregats i els ´ındexs generats amb l’aplicació indexadora. Hi ha determinades URLs que no vull que s’explorin. Com ho indico? Cal editar un fitxer de text indicant a cada l´ınia d’aquest les URLs que no volem explorar. El fitxer s’ha de guardar en format .txt al directori on tinguem definida la intranet al fitxer rutes.cfg. Posteriorment, caldrà marcar l’opci´ o de no explorar URLs prohibides i seleccionar el fitxer creat. Amb l’eina per realitzar ´ındexs, puc crear un ´ındex a partir de m´ ultiples exploracions? S´ı, es pot. Cal anar afegint de la llista d’exploracions totes aquelles exploracions que volguem a la llista de la dreta, és a dir, a la llista d’exploracions escollides. El procés d’indexació crearà un u ńic ´ındex a partir de les exploracions escollides. Amb l’eina per realitzar cerques puc realitzar una cerca sobre un conjunt d’´ındexs? S´ı, es pot. Per a fer-ho cal seleccionar varis dels ´ındexs disponibles de la llista. La selecció es fa mantenint apretada la tecla Ctrl. i clicant a sobre dels ´ındexs amb el cursor del ratol´ı. Els resultats de les cerques contindran resultats obtinguts a partir dels ´ındexs marcats. On puc trobar distribucions, actualitzacions i millores del programa? Les distribucions, actualitzacions, millores, documentació i altres

` ´ FREQUENTS ¨ APENDIX C. PREGUNTES MES

121

temes relacionats amb aquest conjunt d’eines d’exploraci´ o, indexaci´o i cerca ho trobar`as a la web del programa http://toke.sourceforge.net o a la web del seu autor http://www.telefonica.net/web2/albertng