Remote Update Protocol

[ Home ] [ Sources ] [ FAQ ] [ Notes / Rapport ] [ Architecture ] [ Installer RUP ]

Preparatifs

Librairies



• 10 Avril 2001
  Un module pour analyser le fichier rupinfo.txt (qui peut etre vu comme un fichier de configuration du serveur RUP).
  Au demarrage le serveur RUP parse ce fichier et construit un objet de type host_pref.
  Cet objet host_pref contient donc les informations relatives au protocole RUP que supporte l'hote.
  On utilisera ces informations pour valider une commande emise par un client.
  
  
  
• 10 Avril 2001
  Un module pour analyser une chaine de caracteres contenant un objet rup_pref.
  Ainsi on peut analyser le fichier ruprobot.txt (chaque ligne est un objet rup_pref).
  On peut aussi analyser (ie: construire un objet rup_pref) une commande rup Register/Unregister provenant d'un robot-client.
  
  
  
• 15 Avril 2001
  On choisi HTTP comme protocole de communication entre un robot-client et un robot-serveur.
  Le client prepare une commande rup ( cf - fichier rup_op.ml ) et l'envoie au serveur.
  Le serveur est un CGI, le client s'y connecte et effectue une commande POST, ( pourquoi pas GET et un formulaire HTML).
  Le serveur traite la commande rup recue, dans certains cas il ajoute une entree au fichier ruprobot.txt.
  
  
  
• 18 Avril 2001
  Un module de gestion du fichier ruprobot.txt.
  Une entree de ce fichier est un objet rup_pref ; par exemple
  tcp(7777):SendIndex:*.html, *.gif:4-day:2
  La specification RUP ne mentionne pas l'identifiant du robot ?
  En fait il n'y a pas d'indications sur le stockage des bot_id, pourquoi pas alors
  etendre l'objet rup_pref en y incluant un champ bot_id ?
  On souhaite disposer des operations suivantes :
  - ajouter une entree
  - suprimmer une entree
  - charger le contenu du fichier. ie: obtenir une liste de rup_pref.
  Dans un premier temps on va implementer ce minimum 'a la main' avec OCaml.
  Mais il faut essayer un SGBD, par exemple MySQL ( y'a un module MySQL/OCaml ).
  Utiliser Xml peut aussi etre tres bien, surtout si on l'utilise deja pour gerer l'index
  Tres important : le fichier ruprobot.txt = acces concurents...
  Tous les robots-serveurs (par exemple un sur tcp(7777), un sur http(www.truc.domain/bidule), et un autre sur smtp(7775) ),
  y accedent en lecture/ecriture, et le serveur rup doit le parcourir pour savoir a qui envoyer l'index ( un objet rup_info ).
  
  
  
• 21 Avril 2001
  Resumons un peu !
  nous avons des objets rup (implementes suivant les specifications du protocole)
  des modules pour manipuler ces objets
  un client capable de construire des commandes RUP
  un serveur capable d'executer ces commandes.
  En fait il y deux remarques a faire :
  1 - les objets evoluent tres peu (specifications intelligente), par contre les choix d'implementation sont larges...protocoles sous jacents, bd, xml, rapidite, fiabilite, accessibilite, extensibilite, il va falloir se decider. 2- et l'index dans tout ca ?
  l'objet rup_refe (la veritable information vehiculee par rup, le service rup en soi), n'a jusqu'ici pas ete utilise, je pense que c'est tres important comme remarque dans le sens ou on separe le mechanisme de communication du service, d'ailleur nous n'avons pas encore implemente la commande GetIndex...
  
  
  
• 22 Avril 2001
  Abordons le cas de l'index, nous avons une flopee de programmes pour generer un index (shell, perl, c...), mais quelles informations reporter dans l'index ?, et sous quel(s) format(s).
  Commencons plutot par ecrire un module pour gerer des objets rup_refe, les construire a partir d'un index.
  
  
  
• 27 Avril 2001
  Il nous faut obtenir TROIS informations a partir d'un index
  les listes des fichiers :
  - nouveaux
  - modifies
  - supprimes (on doit donc conserver les index...)
  Nous avons defini une dtd pour representer un index, cf rup.dtd
  En utilisant les modules Pxp, on peut parser un index.xml qui respecte cette dtd.
  Tout les MinimumLatency on va generer un index a l'aide de statxml (un programme C qui prend en argument une liste de fichiers ou/et repertoires et produit un document xml valide et conforme a la dtd definie dans rup.dtd)
  Ensuite on va le comparer avec le precedent index, et extraire une liste de rup_refe.
  Cette liste sera ensuite confrontee au fichier ruprobots.txt pour envoyer les informations demandees (un objet rupinfo) aux robots concernes (ie: dont le champ Latency correspond).
  Algo pour comparer deux indexes et en extraire une liste de rup_refe.
  Soit N_index (le nouvel index) et E_index (l'ex index),
  au temps t=n faire
  Si X aparait dans N_index et pas dans E_index alors : Newz(X)
  Si X aparait dans E_index et pas dans N_index alors : Del(X)
  Si X aparait dans N_index et dans E_index alors,
  si N_index[Mtime](X) > E_index[Mtime](X) alors : Updt(X)
  On sauvegarde la liste de rup_refe, et on remplace E_index par N_index.
  a t=n+1 faire
  la meme chose, et on dispose maintenant de deux objets rupinfo (ie: liste de rup_refe), qui ne contiennent pas les meme informations, et qui reunis forment le message a envoyer au robots-clients ayant indique un Latency de 2 fois le MinimumLatency.
  En iterant cette operation on realise l'extraction desiree tout en minimisant les operations de creation d'index et de comparaisons d'index.
  
  
  
• 28 Avril 2001
  Il nous faut choisir un format pour les indexes, vu qu'il vont etres parcourus regulierement il faut qqch de rapide.
  Le package Pxp offre des fonctions pour travailler sur un documents Xml a partir duquel un arbre est construit. Mais il s'avere delicat de comparer deux documents (arbres) Xml.
  En plus nous avons peu de temps pour realiser ce projet donc il nous faut choisir la solution la plus directe.
  En l'occurence SQL/MySQL, l'index est une table : comparer 2 indexes revient a faire une jointure.
  Du coup le fichier ruprobot.txt (du moins sont equivalent interne au programme) sera aussi une table.
  Nous allons ecrire un programme qui genere non plus un index au format XML mais une suite de commandes SQL.
  Une fois ces commande executes par le SGBD(en l'occurence MySQL, mais tout autre SGBD ferait tres bien l'affaire), nous avons une table contenant l'index.
  
  
• 1 Mai 2001
  Probleme...Le module OCamlSQL ne permet pas d'envoyer des commandes SQL au SGBD.
  Nous allons donc utiliser un module de base de donnees tres simple.
  Il nous servira pour les indexes et pour le fichier ruprobots.txt.
  Ce module se base sur les bibliotheques standard de OCaml, ainsi nous gagnons en portabilite.
  Il nous faut donc modifier le programme stat pour qu'il genere un fichier au format requis :
  Num|Nom|Ctime|Mtime
  0:/base/truc.bidule:12345678:21345678
  1:/base/truc2.bidule2:12354678:21354678
  etc
  A partir de ca nous pouvons implementer l'algo d'extraction des objets rup_refe puis faire la mise a jour de l'index.
  
  Rappelons que le but est un processus qui :
  toutes les MinimumLatency compare deux indexes et produit un objet rup_refe qui est sauvegarde.
  
  
  
• 12 Mai 2001
  - le programme statr ( en C) produit un fichier de ce format.
  - un test d'extraction d'informations portant sur une base de 16.000 entrees ( env. 1M ) = OK
  - il faut cependant repenser l'algo d'extraction de rup_refe a partir de cette base.
  De plus nous allons exploiter ce module pour gerer le fichier robotinfo.txt.
  
  
  
• 12 Mai 2001
  - le temps d'extraction ( et d'affichage ) des champs satisfaisant une contrainte
  par exemple : sortir touts les fichiers modifies il y a moins de x temps
  REM : si l'on supprime l'affichage ( > /dev/null ) on divise ces temps par environ 1,5.
  - pour un fichier de 900Ko ( = 13900 lignes ) on obtient 2,2Sec.
  - pour un fichier de 950Ko ( = 14800 lignes ) on obtient 2,35Sec.
  - pour un fichier de 980Ko ( = 15200 lignes ) on obtient 2,8Sec.
  - pour un fichier de 1.5Mo ( = 22900 lignes ) on obtient 3,5Sec.
  - pour un fichier de 3Mo ( = 40600 lignes ) on obtient Stack_overflow
  - il nous faut determiner quelle est la limite de taille, au dela de laquelle on recoit un Stack_overflow
  En tout cas on sait que ca marche (tres bien) pour un index de 1.5Mo
  
  
  
• 13 Mai 2001
  Un autre solution est a envisager : le programme stat genere automatiquement 3 fichiers old, updt, new contenant les objets rup_refe correspondants.
  
  
  
• 14 Mai 2001
  Mettre en place un mecanisme pour qu'un robot trouve l'information necessaire sur le serveur en consultant le fichier rupinfo.txt (qui doit se trouver a la racine du serveur).
  - Le robot effectue une requete GET / HTTP path_to/rupinfo.txt et parse le fichier obtenu ( sinon on considere que le service RUP n'est pas diponible sur le serveur) avec le module parse_rupinfo.
  A ce moment le robot 'sait' sur quel(s) port(s) et avec quel(s) protocole(s) communiquer avec le serveur pour passer des commandes RUP. (la premiere sera surement Version(), histoire de voir si ca marche...)
  - Ensuite le robot doit 'choisir' (avec l'aide de l'utilisateur ?) une de ces methodes.
  - Le robot doit construire une commande.
  - Le robot l'expedie au serveur.
  - le robot traite la reponse du serveur (erreur, ok , indexes).
  
  
  
• 15 Mai 2001
  - on considere que l'information (tant desiree, a savoir les objets rup_refe) est fournie par un processus (cf rupstat) independant.
  rupd va etre charge de consulter le(s) fichier ruprobots.txt, et d'envoyer les objets rup_refe correspondants.
  nous avons deja un module pour parser le fichier ruprobots.txt, ...cool
  il nous manque cruellement un module de manipulation du format latency; ceci fait on va s'occuper de preparer les objets_refe a l'envoi...
  bien sur apres ca serait bien de les envoyer :)
  
  On choisi d'implementer un robot-client avec les fonctionalites suivantes :
  - support du protocole HTTP
  - auto-configuration
  Et un robot-serveur supportant le protocole HTTP, pour simplifier on utilise apache/cgi mais rien n'exclue un robot-serveur HTTP 'stand-alone' (cf - wserver.ml)
  
  C'est un service sans etats.
  Le client prend en option un nom de commande rup et un fichier contenant la commande (si besoin), il l'execute reporte le resultat (fichier de log ?) et termine.
  Questions !!! : de quoi doit se 'souvenir' le client pour fonctionner a long terme.
  comment gerer l'inscription a plusieurs serveur ???
  Comme on l'a deja vu a propos du client web/cgi on peut tres bien imaginer un 'menu' de construction de la commande, ca serait utile...(ou/et une interface graphique pour construire le(s) commande(s)...)
  
  
  
• 15 Mai 2001
  On profite de l'effort pour ecrire un module de traitement des commandes rup, avec l'aide du module Mimestring.
  On veut une fonction qui prend en arguments : un type mime/rup , et une (liste de ) chaines (eventuellement vide) contenant le corps de la commande.
  Cette fonction doit verifier que la commande correspond bien au sous-type mime.
  Une autre fonction sera chargee de verifier la validite de la commande (par rapport aux preferences du serveur. ie : fichier rupinfo.txt).
  
  30 Mai 2001
  A faire dans l'urgence :
  client : prise en charge complete des identifiants
  serveur : idem
  C'est ma fois tout ce qui reste pour avoir un couple client/serveur RUP HTTP fonctionnel.
  

  Ensuite il faut terminer le rupd...
  

  1 Juin 2001
  Ok...la prise en charge des identfiants est faite.
  

  Il reste
  • la commande getinfo
  • le processus rupd
  • la commande getindex
  • nettoyer les sources
  • regler le Makefile
  • boucler la doc et le rapport