S2WC2, un Framework pour la Segmentation de Sessions Web Coté Client

S2WC2, un Framework pour la Segmentation de Sessions Web Coté Client

Chapitre 4 – S2WC2, un Framework pour la Segmentation de Sessions Web Coté Client

4.1 Introduction

Après avoir exploré les sujets de l’extraction de connaissances et de la fouille du web et présenté l’état de l’art sur le web usage mining, nous décrivons dans ce chapitre notre approche pour la construction d’un framework de segmentation de sessions web de coté des utilisateurs. Nous y présentons l’architecture proposée, les différents choix que nous avons été amené à adopter, ainsi que les modules implémentés.

4.2 Architecture

L’environnement conçu est constitué, de manière similaire à tout projet de fouille de données, de trois parties relativement distinctes les unes des autres : un collecteur de traces de navigation, une application de prétraitement de données, et un module d’extraction de connaissances. Cette architecture est illustrée dans la figure ci-après.

La collecte de traces de navigation est assurée par un module léger développé pour Internet Explorer de Microsoft, le navigateur le plus répandu. Cet outil, détaillé dans le point suivant, fournit des logs à ramasser sur les postes des utilisateurs ayant répondu favorablement à notre sollicitation et accepté de participer à l’étude.

La deuxième partie inclut plusieurs algorithmes que nous avons écrit afin de préparer les logs bruts des utilisateurs générés par l’outil de collecte de traces. Elle a consisté globalement, après la fusion des logs ramassés, à les nettoyer, d’en reconstituer les sessions, et d’opérer certaines sortes de formatage final. La dernière partie quant à elle, est une application directe d’une technique célèbre d’ECD : la segmentation par les cartes topologiques auto-organisatrices de Kohonen (SOM : Self Organizing Maps en anglais).

Architecture de S2WC2

Figure 10. Architecture de S2WC2

4.3 Collecteur de traces de navigation

Les logs serveurs et ceux issus des postes client constituent, comme déjà évoqué dans le chapitre précédent, les deux principales sources de données en WUM. Et du fait que la quasi-totalité des travaux ont pris comme matière d’étude les logs serveurs, nous avons choisi d’étudier le deuxième type de logs, car ils restent encore relativement récents, et peu sondés d’une part, et des choix technologiques qu’ils impliquent d’autre part.

La piste initialement tracée prévoit l’utilisation d’un outil client existant pour la collecte de traces de navigation. Ce choix, en dépit de la pléthore et la diversité des outils disponibles sur Internet, n’était pas pour nous facile et fructueux. L’exploration que nous avons menée sur un certain nombre d’outils nous a permis d’en séparer deux grandes classes.

La première famille est un ensemble d’outils de l’ordre de logiciels offerts sous licence par des sociétés spécialisées, qui nécessitent l’installation explicite de l’utilisateur. Cette catégorie d’outils, dont AAAnalyser1 fait partie, a été écartée en raison de l’exploitation lourde qu’elle implique, de l’altération importante de l’environnement du client qu’elle provoque, et du format de données difficilement accessible.

La deuxième catégorie est représentée par plusieurs outils moins encombrants que ceux de la première classe. Ces outils, à l’instar de Web-R (Kant et al., 2003), offrent de plus en sortie sous forme de fichiers lisibles (tables de base de données, feuilles Excel, fichiers textes…etc) des données riches et intéressantes sur l’activité de l’utilisateur. Malgré ces atouts, aucun de ces outils n’a été retenu, car ils présentent l’inconvénient d’être seulement des prototypes et des versions de test limitées en nombre de pages ou en temps de navigation permis.

La question de la collecte de traces de navigation était pour notre étude une problématique capitale. En effet, l’outil qui sera utilisé (acquis ou construit) offre la matière première au projet que nous menons, pour lequel la réussite est fortement liée à plusieurs de ses aspects tels que la simplicité et la facilité d’exploitation, et à la nature des données qu’il nous permet de disposer. De plus, les différentes phases suivantes du projet en s’appuient de manière significative et directe.

1 Activity and Authentication Analyzer, disponible sur : http://www.filetransit.com/view.php?id=14683

4.3.1 Approche

Tracer l’activité de l’utilisateur d’un PC a fait l’objet de plusieurs travaux ayant des origines diverses. Qu’il s’agisse de sujets ayant traité à la sécurité des systèmes, ou à l’amélioration des interfaces des applications, ou tout simplement de simulations d’usages de logiciels, chacun opte pour une méthode qui permet en final de récupérer sous différents formats les actions horodatées effectuées par l’usager sur son poste. Les approches, selon le niveau fixé de la sonde de collecte de traces (réseau, application…etc.), se distinguent alors en volume, détail, portée, et qualité de données recueillies.

Pour notre étude, nous avons estimé qu’il est de bon aloi l’utilisation d’un outil qu’il soit léger, d’exploitation simple, et n’affectant pas l’environnement de l’utilisateur. Ces traits caractéristiques sont recherchés afin de rassurer l’usager et minimiser l’influence sur son comportement que pourrait provoquer l’installation de la sonde de collecte de ses traces de navigation.

Les caractéristiques de l’outil arrêtées, nous avons opté pour la technique des Browser Helper Object (BHO) de Microsoft. Cette technique a été préférée sur les deux autres alternatives, qui sont les packet-sniffers et les agents distants pour les raisons suivantes : les packet-sniffers sont des outils s’opérant sur la couche réseau en interceptant les paquets échangés, un niveau d’implémentation non visé au départ, car nous préférons rester sur le niveau applicatif, ils exigent aussi la connaissance de la structure détaillée des paquets, et ne peuvent en plus tracer les navigations offlines.

Les solutions basées sur les agents distants java, quant à elles, sont en principe liées à un site donné (dont la structure et le contenu sont connues), ce qui nous a paru inapproprié, étant donné que nous nous ciblons pas un site particulier.

4.3.2 Avantages & inconvénients

Un browser helper object est un dll (Dynamic Link Library) chargé automatiquement avec chaque instance d’Internet Explorer (IE) active. S’exécutant en tâche de fond et dans le même espace de processus, il permet en utilisant le modèle COM (Component Object Model) de contrôler l’exécution de l’instance d’IE et d’intercepter l’ensemble des évènements qu’elle déclenche. C’est un procédé utilisé à partir de la version 4 d’IE afin de réaliser des versions personnalisées ou étendues du navigateur de Microsoft (Roberts, 1999), (Espositi, 1999).

Notre outil de recueil de traces de navigation a été développé en utilisant le langage Object Pascal sous l’environnement DELPHI 5, il est caractérisé et possède les propriétés positives suivantes :

  • 1.
    Très léger : l’outil a été bien pensé pour être moins encombrant. En effet son occupation mémoire est insignifiante (sa taille est seulement de l’ordre de 90 ko), et les instructions qu’il exécute sont aussi optimisées et minimisées au strict nécessaire (Cf. annexe 3).
  • 2. Exploitation très simple : l’installation et l’usage de la solution n’éprouvent aucune difficulté. Une fois installée par une simple commande d’inscription dans le registre de windows, le recueil se fait automatiquement sans intervention aucune.
  • 3. Portée illimitée : théoriquement tous les sites visités par l’utilisateur peuvent être tracés.
  • 4. Altération quasi-nulle de l’environnement du client : la solution proposée peut être utilisée coté utilisateur sans aucune modification apparente de son système. De plus, elle ne nécessite pas des changement coté serveur aussi si elle sera exploitée dans un projet de MUM centré serveur. Cette propriété est intéressante du fait qu’elle offre un confort suffisant à l’utilisateur, lorsque il voit son système inchangé.
  • 5. Identification des utilisateurs résolue : si cette question reste insoluble dans le recueil coté serveur, avec cet outil exploitant l’adresse MAC et le login système ce problème est solutionné de manière sûre.
  • 6. Traçage à granularité fine, et précision haute : l’outil offre pour chaque page visitée un logging au niveau évènements. La page est suivie lorsqu’elle est demandée, complètement téléchargée et, en adoptant certaines règles, quand elle est terminée. Ces événements sont enregistrés dans le log généré avec leurs instants aux millisecondes.
  • 7. Logging offline possible : si l’utilisateur utilise IE en mode déconnecté les pages visitées sont tracées, contrairement aux autres solutions qui ne peuvent effectuer le traçage en l’absence de connexion.
  • 8. Sessionisation relativement aisée : avec un logging des évènements par utilisateur, contigus par ordre chronologique, la reconstruction des sessions des utilisateurs est moyennement simplifiée.
  • 9.

    Capture des données de contenu : dans la version actuelle l’outil permet d’enregistrer certaines données liées aux contenus visités comme le titre de la page. Dans les versions futures d’autres attributs tels que les mots clés, ou le code source intégral peuvent aussi être tracés.

En dépit de ces nombreux avantages, nous avouons que cette solution n’est pas parfaite et que nous mentionnons dores et déjà les deux points négatifs suivants :

  1. 1. La dépendance à l’environnement du client : cette propriété constitue incontestablement l’inconvénient majeur. En effet, la forte dépendance à IE signifie que la solution ne peut être utilisée qu’exclusivement pour le système d’exploitation Windows de Microsoft et avec les navigateurs supportant IE à partir de la version 4. Mais, ce problème peut être atténué, si nous savons que IE reste encore l’un des navigateurs les plus répandus.
  2. 2. Désinstallation permise : les utilisateurs avertis ont la possibilité de supprimer l’outil et d’arrêter l’opération de recueil. Une solution envisageable pourrait être de désactiver la modification des paramètres du système notamment le registre.

4.3.3 Schéma du fichier log

L’outil de recueil de traces produit un fichier log au format textuel, nommé IE_Traces.log, où sont consignées des données se rapportant à l’identification de l’utilisateur, aux attributs temporels des actions qu’il a effectuées et aux informations relatives aux pages visitées.

Le couple adresse MAC et le login du système d’exploitation est utilisé afin d’identifier l’utilisateur. Contrairement aux solutions centrées serveur exploitants les adresses IP comme identifiant de l’usager qui sont rappelons-le inefficaces, cette approche, grâce à l’adresse MAC, permet de distinguer d’une part et cela de manière sure1 les postes participant à l’étude, et d’autre les utilisateurs exploitant la même machine, comme c’est le cas dans beaucoup de situation de partage de PC telles que dans les réseaux d’entreprises, les cyberspaces, et dans de nombreux foyers.

Mentionnons en plus, que pour des raisons de confidentialité le login de l’utilisateur, qui peut être claire et expressif dans plusieurs cas, est consigné crypté dans le log.

Les autres informations recueillies sont la date et l’instant de la requête précise aux millisecondes, le numéro de la fenêtre d’IE active servant à différencier entre plusieurs fenêtres ouvertes simultanément, le type d’événement déclenché par le navigateur, l’url de la page demandée, son titre, ainsi que le nombre de frames (cadres) qu’ils la composent si présents.

La liste des évènements que pourrait déclencher le navigateur inclut une vingtaine (Cf. annexes 2), c’est pourquoi nous nous somme limité seulement aux trois évènements décrits ci-dessous que nous avons jugés les plus intéressants :

  1. 1. BeforeNavigate2 : comme l’indique son nom, cet évènement est déclenché juste avant la navigation vers une url (saisie ou sélectionnée), il est codé 01 dans notre outil.
  2. 2. DocumentComplete : il est déclenché quand l’objet document de la page en cours est complètement téléchargé, codé 02.
  3. 3. OnQuit : se produit lorsque l’utilisateur quitte IE, codé 03.

1 En principe les adresses MAC sont, pour chaque adaptateur réseau, uniques et fixées à la construction. Elles constituent un bon identifiant de la machine, même c’est actuellement certains outils peuvent les modifiées.

Les deux figures suivantes schématisent respectivement la structure du fichier log, et un extrait d’un exemple de celui-ci pris à titre d’illustration.

LOG (

Mac : Char (20), Login : Char (30), Journée : Date (10),

Heure : Temps(12),// HH :MM :SS :mmm, ou mmm: Millisecondes

Id_Fenêtre : Numérique (10,0),

Evènement : Char (2), // 01, 02, ou 03

Longueur_Url : Nummérique (4,0)

Url : Char (Longueur_url), Longueur_Titre: Numérique (4,0)

Titre : Char (Longueur_Titre),

Nombre_Frames : Numérique (2,0)

)

Figure 11. Structure du fichier log textuel

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:19:57:026 262478 01 027 http://avunet.info.free.fr/00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:20:43:203 262478 02 027 http://avunet.info.free.fr/ 029 le projet de recherche

AVUNET 00

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:23:08:712 262478 01 021 http://www.google.com

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:23:13:609 262478 02 021 http://www.google.com 006 Google 00

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:23:47:137 262478 01 104

http://www.google.com/search?hl=fr&q=site+page+frames+document+complete+event+internet+explorer+&lr=00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:23:47:888 262478 02 104

http://www.google.com/search?hl=fr&q=site+page+frames+document+complete+event+internet+explorer+&lr= 081 site page frames document complete event internet explorer – Recherche Google 00

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:23:58:143 262478 01 038 http://support.microsoft.com/kb/180366

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:24:11:382 262478 01 052 http://support.microsoft.com/common/surveysubmit.asp

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:24:18:813 262478 02 052 http://support.microsoft.com/common/surveysubmit.asp

080 Déterminait comment quand une page est faite charger dans le contrôle WebBrowser 01 00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:24:18:843 262478 02 038 http://support.microsoft.com/kb/180366 080 Déterminait comment quand une page est faite charger dans le contrôle WebBrowser 01

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:24:18:973 262478 01 011 about:blank

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:24:19:093 262478 02 011 about:blank 080 Déterminait comment quand une page est faite charger dans le contrôle WebBrowser 02

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:25:49:123 262478 01 104 http://www.google.com/search?hl=fr&q=site+page+frames+document+complete+event+internet+explorer+&lr=

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:25:49:673 262478 02 104 http://www.google.com/search?hl=fr&q=site+page+frames+document+complete+event+internet+explorer+&lr= 081 site page frames document complete event internet explorer – Recherche Google 00

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:25:51:927 262478 01 044 http://www.redfoxcenter.org/HTML/frames.html

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:26:03:413 262478 02 044 http://www.redfoxcenter.org/HTML/frames.html 017 HTML

: Les frames 00

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:28:00:401 393618 01 066 http://www.redfoxcenter.org/Docs/W3C/W3C_rec/WD-frames-970331.html

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:28:00:421 393618 02 066 http://www.redfoxcenter.org/Docs/W3C/W3C_rec/WD- frames-970331.html 000 0000-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:28:01:663 393618 02 079 http://ftp.redfoxcenter.org/pub/Documentation/W3C/W3C_rec/WD-frames-970331.html 017 Objet non trouvé! 0000-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:28:03:265 262478 01 104

http://www.google.com/search?hl=fr&q=site+page+frames+document+complete+event+internet+explorer+&lr=00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:28:03:846 262478 02 104

http://www.google.com/search?hl=fr&q=site+page+frames+document+complete+event+internet+explorer+&lr= 081 site page frames document complete event internet explorer – Recherche Google 00

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:28:07:201 262478 01 047 http://www.w3schools.com/jsref/jsref_events.asp

00-0A-CD-01-C6-69 Dül¥¢g 05/05/2008 22:28:14:201 393618 03

Figure 12. Extrait d’un fichier log

4.4 Prétraitement

L’expérience et l’exploration que nous avons menées, par des examens manuels, mais aussi avec les algorithmes écrits sur les logs collectés nous ont montrés que ces derniers nécessitent une série d’opérations sérieuses de préparation, et le fait de choisir une approche de collecte de traces coté client n’élimine pas cette phase primordiale.

image012 1

Figure 13. L’interface de l’application de prétraitement

Si la question de l’identification des usagers est résolue, et la précision dans le traçage des actions est assurée dans l’approche adoptée, d’autres anomalies ont été relevées pour lesquelles nous avons pu identifier les sources et avons tenté d’apporter des solutions définitives pour la majorité d’entre elles, mais que partielles pour d’autres. A cet effet, une application de prétraitement a été conçue intégrant un ensemble de modules permettant de résoudre et d’adapter les logs bruts recueillis. Les différentes étapes de préparation sont décrites dans les points suivants.

4.4.1 Nettoyage

Le nettoyage à pour but de réduire la taille du log à fouiller en éliminant les items estimés inutiles. Ci-dessous les différentes opérations effectuées.

4.4.1.1 Fusion et export vers une base de données

Afin de faciliter les différentes opérations de manipulation des logs bruts, ces derniers sont d’abord fusionnés puis exportés vers une table de base de données ayant la même structure décrite dans 4.3.3.

Dans la version actuelle, nous nous sommes contenté d’un ramassage manuel des logs issues des différents utilisateurs, ceci peut constituer un inconvénient, cependant une solution plus intéressante qui n’a pas été implémentée, faute de temps et de support sur le web, sera proposée en perspectives, elle est basée sur l’utilisation de la connexion Internet dans le transfert des logs vers un serveur dédié.

Etant donné que l’objectif de la phase de préparation est d’obtenir, à partir des logs bruts, des informations plus significatives, un ensemble de tables sont donc dérivées de ces logs au moment du chargement, puis lors de la phase de sessionisation. Le schéma de la base de données dérivée est illustré dans la figure suivante. Ils y sont montrés que les rubriques de bases.

Modèle de la base de données utilisée dans S2WC2

Figure 14. Modèle de la base de données utilisée dans S2WC2

L’algorithme de cette l’étape de fusion et de chargement en table de base de données est le suivant.

Entée : logs bruts des différents utilisateurs

Sortie : logs fusionnés et transcrits en table de base de données

debut

Initialiser toutes les Tables ;

Pour chaque fichier log nommé FLogi Faire Exporter_Log(FLogi) ;

//—————————————————————-

Procédure Exporter_Log ; Entree : log textuel

Sortie : log en table de base de données

Tant que Non Fin_de_fichier (Flog) faire

Lire_Ligne(FLog,Line) ; MAC(Line,_MAC) ; // retourne l’@ MAC LOGIN(Line,_LOGIN) ; // retourne le Login

…. // extraire la suite des rubriques

Si le Couple (_MAC, _LOGIN) inexistant dans la Table_Users alors

Déclarer_NEW_Utilisateur ;

Si _URL inexistante dans la table_URLS alors Déclarer_NEW_URL ; Inserer la ligne dans la table LOG ;

Fin Tant que

Fin de Exporter_Log ;

9. Fusion et export vers une table de BDD

4.4.1.2 Traitement des urls

L’URL (Uniforme Ressource Locator) est un format de nommage universel pour désigner une ressource sur Internet proposé par Tim Berners-Lee. C’est une chaîne de caractères ayant la syntaxe suivante :

protocole : //[user]@hote [: port]/chemin/fichier ?[arguments]#[section] Où :

  • * protocole : est le protocole à appliquer tel que http, ftp, file…
  • * user : très rarement renseigné, il désigne le nom d’un utilisateur, et son mot de passe
  • * hote : est le nom ou l’adresse IP de la machine ou le serveur cible
  • * port : numéro de port, optionnel (80 par défaut)
  • * chemin : chemin du fichier à acquérir, si c’est un répertoire le serveur ira chercher un fichier nommé index.html ou un de ses corrélats
  • * fichier : un nom de fichier précis dans le répertoire, il peut être statique, ou invoquant l’exécution d’une ou de plusieurs procédures sur le serveur
  • * arguments : la présence de cet élément permet de passer des paramètres aux programmes exécutés sur le serveur. La série d’argument est de la forme d’affectations ‘variable=valeur’ séparées par le caractère ‘&’
  • * section : référence, ou fragment est une ancre nominale qui identifier une section particulière dans un document HTML

Dans la version actuelle de l’application de prétraitement, la prise en charge des URLs se limite, en plus bien entendu de connaître leurs constituants et certaines formes d’équivalence d’url, à séparer pour les pages dynamiques les paramètres du reste de l’url. Cela permettrait de pister les usagers visitant les mêmes pages dans des domaines similaires quelque soit les données spécifiques échangées.

Mise à part les requêtes de recherche d’information, dont les paramètres représentent les mots clés du sujet visé, conjugués ou non avec des opérateurs du langage de requêtes utilisé, ce choix trouve sa justification pour les autres formes d’urls dont la signification des paramètres, souvent numériques, n’a de sens que pour le concepteur du site.

Ceci dit, l’ensemble des urls visités, auxquelles les paramètres sont retranchés et stockés d’une table a part, sont consignées avec une codification numérique dans la table des URL. Notons que le module implémenté prend exclusivement les urls avec paramètres signalés par le caractère ‘ ?’ seulement.

procedure Formatter_URL(url:string; var protocole,domaine,niv1,niv2,param1,param2,param3,param4,extension: String);

10. Signature de la procédure de formatage des urls

4.4.1.3 Filtrage des items inutiles

Pour des contraintes qui nous échappent, liées à la coopération et les relations humaines et aussi à la disponibilité et bien que le nombre d’utilisateurs ayant accepté de participer à l’expérimentation, qui n’a durée que quelques jours, est faible, le nombre d’entrées du fichier log a atteint un chiffre énorme, ceci compliquerait les algorithmes prévus à leur traitement.

De plus, nous avons constaté qu’une grande partie de ces entrées ne se rapportent pas forcement à des actions explicites des utilisateurs, ou sont le résultat d’une situation d’incohérence dans le fonctionnement du système de l’usager. A cet effet, des modules ont été écrits afin d’identifier, puis d’éliminer ces entrées. Les principales sources d’incohérences, à notre point de vue, sont ci-dessous expliquées :

  1. 1. les adresses MAC invalides : dans la fonction de détection d’adresses MAC, une constante matérialisée par la valeur ’00-00-00-00-00-00′ est retournée en cas d’absence de connexion, ou si des erreurs de communications, avec la carte réseau, sont renvoyées.
  2. Une partie non négligeable d’entrées du log ont été trouvé avec la constante d’erreur ci-dessus. Ces entrées correspondent donc aux usagers continuant à surfer en la présence de cette situation d’erreur qu’ils l’ont ignoré par méconnaissance.
  3. 2. les urls non ciblées : pour fins de réduction de données et simplification de l’étude, un choix a été fixé au départ consistant a ne tracer que les requêtes pour le protocole http ou sa version sécurisée https, et le protocole ftp. Nous filtrons donc toute entrée dont l’url ne respecte pas ces deux protocoles.
  4. 3. les requêtes provenant des frames : les pages avec frames sont l’une des sources d’incohérence les plus difficile à résoudre. Cette question sera discutée dans le point suivant.
  5. 4. les requêtes vers les ressources locales : l’une des caractéristiques des BHO est leur capacité de tracer non seulement les évènements d’IE, mais aussi ceux liés à l’explorateur windows (Roberts, 1999). Un premier niveau de filtrage des évènements de l’explorateur de windows est assuré donc dans l’outil de collecte de traces lui-même, en n’autorisant le recueil de traces que si l’application cliente du BHO est le navigateur (nom de l’exécutable iexplore.exe). Par ailleurs, notre objectif est l’étude de l’usage du web, les navigations effectuées offline, ou vers des pages stockées sur le disque local ne sont pas prise en considération.
  6. 5. les items à jeux de caractères non latins : dans le fichier log textuel, les pages des sites à jeux de caractères non latin sont consignées dans le format texte standard avec des caractères illisibles, c’est le cas par exemple des sites en arabes, en chinois…etc. Ces items ont été malgré cela conservés dans le log et exploités en termes de pages visitées et la temporalité de cet usage.
  7. 6. les items orphelins : les items orphelins sont des entrées du fichier log qui avant ou après les différentes opérations de nettoyage se trouvent isolées. Il peut s’agir de requêtes seules pour une des fenêtres d’une navigation, d’évènements de fermeture (code 03) de fenêtre délaissés, ou d’évènements quelconques (de type 01,02 ou 03) relatifs à des fenêtres terminées ou inexistantes lors d’une session.

L’algorithme suivant permet de supprimer les entrées ayant des adresses MAC invalides, des urls inutiles, ou les requêtes vers les pages locales. Les items pour frames et orphelins seront traités dans les algorithmes suivants.

Procedure nettoyage Entrée : log brut Sortie : log nettoyé debut

Ouvrir la table Log ;

Tant que non Log.EOF faire

Debut

Log.Lire (item) ;

Si MAC(item)=MAC_Invalide ou URL(item) est locale ou

Protocole(item) non dans (http,https,ftp) alors

Marquer_Item_Pour_Effacement fsi ;

Fin Tant que ; Fin de nettoyage

11. Suppression d’items inutiles

4.4.1.4 Question des pages avec frames

Une page à frames est une page (dite frameset) constituée de plusieurs autres pages ou cadres (qui peuvent à leurs tours contenir récursivement des frames) affichées par le navigateur quand cette page est demandée. Ce mécanisme est une autre source qui est à l’origine du bruit introduit sur les données collectées. Si la page contient n frames, alors à une requête (évènement 01) vers l’url de cette page, le navigateur émet n+1 autre requête, une pour chaque sous-page, et une dernière pour le top page.

De plus, et selon la documentation de Microsoft (Roberts, 1999), l’évènement DocumentComplete est déclenché une seule fois, si la page ne contient pas de frames. En revanche, il est déclenché plusieurs fois en cas de pages incluant des frames. Plus compliqué encore, ce dernier événement n’est pas déclenché par chaque frame, mais il est lancé par tout frame entraînant auparavant un évènement DownloadBegin (Cf. annexe 2). Il est enfin, déclenché toujours par la top page, une fois toutes les sous pages concernées l’ont déclenché.

Ce problème constitue un vrai casse-tête et demeure à l’heure actuelle posé. (Beauvisage, 2004) constatait en page 68 : « ce problème est à ce jour quasiment impossible à régler de manière satisfaisante sur la base de donnes de trafic : ni l’exploitation du champ Referer dans les entêtes http, qui renseigne l’url à l’origine des requêtes, ni la détection des rafales de requêtes ne permettent de distinguer systématiquement si les requêtes correspondent à des pages ou des composants de pages».

A titre de contribution, et afin d’apporter une solution a ce problème, nous avons d’abord prévu de détecter dans l’outil d’acquisition de traces les pages avec frames, et de récupérer en outre le nombre de frames pour chaque page de ce type. Ceci a été réalisé par l’accès à la propriété frames de l’objet Document de la page une fois celle-ci est complètement téléchargée.

//——— extrait de la méthode invoke du BHO ——————

Entrée : évènements d’IE, avec autres paramètres

Sortie : log brut, avec pour les page à frames le nombre de frames

// lorsque la page est complètement téléchargée on la trace et on

// récupère le titre et le nombre de frames s’il y on a

….

DISPID_DOCUMENTCOMPLETE: begin url:=TDispParams(Params).rgvarg[0].pvarVal^; Doc:=FWebBrowser.document;

Titre:=Doc.title; // le titre de la page

Frames:=Doc.frames.length; // nombre de frames s’ils existent

12. Récupération du nombre de frames pour un frameset

En prenant en compte les mécanismes de chargement des framesets, l’algorithme suivant est proposé afin de supprimer tous les évènements (de type 01, et 02) se rapportant aux frames.

Procedure nettoyage_évènements_frames

Entrée : log brut ;

Sortie : log sans évènements pour frames

debut

Ouvrir la table LOG ;

Pour chaque utilisateur Ui(Maci,Logini) faire

Trier LOG par id_fenetre, puis par ordre chronologique inverse ; Appliquer un filtre à LOG pour les entrées de Ui ;

Tant que non LOG.BOF faire

Item entrée courante ;

//Récupérer le type d’évènement,l’id de la fenetre,l’url,et le

//nbre de frames resp. dans les variables e1,f1,u1, et j ;

e1 Evènement(Item) ; f1 Id_Fenetre(Item) ; u1 Url(Item) ;

j Nbre_Frames(Item) ;

si e1=2 et j>0 alors // cas d’1 frameset

Répéter

Item LOG.précédent ;

//Récupérer le type d’évènement, l’id de la fenetre, et l’url

//respectivement dans les variables e2,f2, et u2 ;

e2 Evènement (Item) ; f2 Id_Fenetre(Item) ; u2 Url(Item) ;

Marquer l’entrée_pour_effacement ;

Si e2=1 alors j– ;

Jusquà ((e2=1) et (u2=u1)) ou (j=0) ou (f2<>f1) ou Log.Bof; Item LOG.précédent ;

Fin tant que ;

Annuler le filtre à LOG ;

Continuer pour le reste des utilisateurs ; Fin de nettoyage_évènements_frames

13. Suppression des évènements dus aux frames.

Pour citer ce mémoire (mémoire de master, thèse, PFE,...) :
Université 🏫: Université Kasdi Merbah de Ouargla - Option : Informatique et Communication Electronique - Mémoire du diplôme de Magister
Auteur·trice·s 🎓:
Slimane OULAD NAOUI

Slimane OULAD NAOUI
Année de soutenance 📅:
Rechercher
Télécharger ce mémoire en ligne PDF (gratuit)

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Scroll to Top