Discussion:IMA4 2021/2022 EC5 : Différence entre versions

De Wiki d'activités IMA
 
(2 révisions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
 
Mise à jour du 25 août :
 
Mise à jour du 25 août :
  
* ajout de problèmes de syntaxe mediawiki
+
* ajout de problèmes de syntaxe mediawiki ;
 
* état du code :
 
* état du code :
 
** <code>libcom</code> : juste serveur TCP, un prototype de résolution DNS mais pas la fonction elle-même ;
 
** <code>libcom</code> : juste serveur TCP, un prototype de résolution DNS mais pas la fonction elle-même ;
Ligne 31 : Ligne 31 :
 
* du code mort dans <code>libcom</code>, pas de modification ;
 
* du code mort dans <code>libcom</code>, pas de modification ;
 
* fonction <code>envoi_mail</code> dans <code>libSMTP</code> avec une ouverture de fichier non demandé dans le sujet (probablement pour lire les MX qui devraient être trouvés par DNS) et une connexion sur le port SMTPS (SMTP demandé dans le sujet) ;
 
* fonction <code>envoi_mail</code> dans <code>libSMTP</code> avec une ouverture de fichier non demandé dans le sujet (probablement pour lire les MX qui devraient être trouvés par DNS) et une connexion sur le port SMTPS (SMTP demandé dans le sujet) ;
* la fonction <code>resoud_mx</code> a été renommée en <code>nomVersAdresse</code> (confusion avec un nom de fonction présentée en cours), la fonction stocke les MX dans une variable locale, les noms sont résolus avec la commande locale <code>host</code> alors que la fonction <code>connexionServeur</code> effectue déjà cette résolution, les adresses IP sont stockés dans un fichier.
+
* la fonction <code>resoud_mx</code> a été renommée en <code>nomVersAdresse</code> (confusion avec un nom de fonction présentée en cours), la fonction stocke les MX dans une variable locale, les noms sont résolus avec la commande locale <code>host</code> alors que la fonction <code>connexionServeur</code> effectue déjà cette résolution, les adresses IP sont stockées dans un fichier.
  
 
Cette mise à jour est probablement un travail personnel de l'élève et montre son manque total de maitrise de la programmation C et au delà de la programmation réseau en C.
 
Cette mise à jour est probablement un travail personnel de l'élève et montre son manque total de maitrise de la programmation C et au delà de la programmation réseau en C.
 +
 +
Analyse finale (code v7) :
 +
* ne compile pas (erreur fatale dans la bibliothèque SMTP), erreur corrigée, reste un avertissement sur <code>mktemp</code> ;
 +
* il reste toujours un fichier parasite <code>Client.c</code> sous la racine du projet ;
 +
* bibliothèque Communication : n'a pas pu récupérer le bon code dans le cours, a pris deux fonctions obsolètes (l'explication a été donnée en cours, les fonctions n'y sont plus qu'à titre historique) au lieu d'une unique fonction plus moderne et plus adaptée ;
 +
* exécutable MTAext :
 +
** répertoire pratiquement vide, appel, pour chaque client, d'une fonction <code>gestionSmtp_ext</code> se trouvant dans la bibliothèque SMTP, y compris le code de traitement du message ;
 +
** le code de traitement du message n'a aucun rapport avec le protocole SMTP, il s'agit de gestion de répertoires et de fichiers, il fallait une bibliothèque adaptée ou, au pire, mettre le code dans le répertoire de l'exécutable, la notion de bibliothèque n'a pas été comprise ;
 +
** la sauvegarde du message dans le système de fichiers ne respecte absolument pas le sujet (format de stockage non conforme Maildir, pas de nom de fichier unique, pas de sémaphores) ;
 +
** l'élève ne sait pas correctement utiliser la programmation système C de base (création de répertoire, manipulation de fichier), il réalise les opérations en shell via la commande système la plus inefficace qui soit : <code>system</code>.
 +
* exécutable MTAin :
 +
** même problème concernant la fonction <code>gestionSmtp_in</code>, soit dit en passant l'élève ne maîtrise même pas la factorisation de code basique : les fonctions <code>gestionSmtp_ext</code> et <code>gestionSmtp_in</code> ont une majorité de code en commun et donc dupliqué ;
 +
** la fonction de résolution DNS est incluse dans la bibliothèque SMTP et pas Communication comme cela était évident, toujours pas de maîtrise de la notion de bibliothèque ;
 +
** là encore l'élève ne respecte pas le sujet, uniquement le premier MX est testé (une simple boucle aurait suffit) et rien n'est prévu en cas d'absence de MX ;
 +
** un code pour la transmission du courriel au serveur de destination mais écrit avec les primitives de bas niveau <code>send</code> et <code>recv</code> alors que l'élève avait sous les yeux un exemple d'utilisation des f-fonctions (son propre code théoriquement) pour la réception des courriels, les codes de retour du serveur de destination ne sont même pas testés.
 +
 +
Une absence totale de maîtrise du rendu via la syntaxe mediawiki : les images ne sont pas incluses mais sous la forme de liens. D'ailleurs pourquoi mettre des images de terminal de commandes ? Un simple texte aurait suffit et aurait été plus lisible.
 +
 +
En conclusion, du coté positif un code a été écrit pour donner l'illusion d'un travail finalisé. Malheureusement ce code ne respecte pas le sujet, est de mauvaise qualité et montre de graves lacunes dans les compétences de l'élève dans les domaines de la programmation en C, de la structuration d'un code et de la programmation système et réseau.

Version actuelle datée du 6 septembre 2022 à 22:22

Mise à jour du 25 août :

  • ajout de problèmes de syntaxe mediawiki ;
  • état du code :
    • libcom : juste serveur TCP, un prototype de résolution DNS mais pas la fonction elle-même ;
    • libthreads : juste un lancement d'un thread, rien sur les sémaphores ;
    • libsmtp : juste les commandes SMTP pour serveur, stockage dans une structure ;
    • MTA de stockage : rien ;
    • MTA d'envoi : partie serveur, rien de prévu pour la remise des courriels.

Code dans l'état en fin de PSR, aucun ajout.

Mise à jour du 26 août :

  • un fichier C en dehors des répertoires ;
  • fonction GetMXRecord dans libcom récupérée d'un autre projet ;
  • fonction trouve_mx dans libSMTP qui appelle la fonction ci-dessus.

Mise à jour du 29 août :

  • du code mort dans libSMTP ;
  • la fonction GetMXRecord est retirée de libcom ;
  • fonction de connexion à un serveur TCP ajoutée dans libcom ;
  • fonction resoud_mx remplaçant GetMXRecord mise dans libSMTP donc très mal placée ;
  • la "nouvelle" fonction de comparaison du qsort est moins bien écrite, l'ancienne est déclarée non fonctionnelle sans justification.

Les mises à jours des 26 et 29 août montrent des tentatives de récupération de code des autres binômes.

Mise à jour du 30 août :

  • du code mort dans libcom, pas de modification ;
  • fonction envoi_mail dans libSMTP avec une ouverture de fichier non demandé dans le sujet (probablement pour lire les MX qui devraient être trouvés par DNS) et une connexion sur le port SMTPS (SMTP demandé dans le sujet) ;
  • la fonction resoud_mx a été renommée en nomVersAdresse (confusion avec un nom de fonction présentée en cours), la fonction stocke les MX dans une variable locale, les noms sont résolus avec la commande locale host alors que la fonction connexionServeur effectue déjà cette résolution, les adresses IP sont stockées dans un fichier.

Cette mise à jour est probablement un travail personnel de l'élève et montre son manque total de maitrise de la programmation C et au delà de la programmation réseau en C.

Analyse finale (code v7) :

  • ne compile pas (erreur fatale dans la bibliothèque SMTP), erreur corrigée, reste un avertissement sur mktemp ;
  • il reste toujours un fichier parasite Client.c sous la racine du projet ;
  • bibliothèque Communication : n'a pas pu récupérer le bon code dans le cours, a pris deux fonctions obsolètes (l'explication a été donnée en cours, les fonctions n'y sont plus qu'à titre historique) au lieu d'une unique fonction plus moderne et plus adaptée ;
  • exécutable MTAext :
    • répertoire pratiquement vide, appel, pour chaque client, d'une fonction gestionSmtp_ext se trouvant dans la bibliothèque SMTP, y compris le code de traitement du message ;
    • le code de traitement du message n'a aucun rapport avec le protocole SMTP, il s'agit de gestion de répertoires et de fichiers, il fallait une bibliothèque adaptée ou, au pire, mettre le code dans le répertoire de l'exécutable, la notion de bibliothèque n'a pas été comprise ;
    • la sauvegarde du message dans le système de fichiers ne respecte absolument pas le sujet (format de stockage non conforme Maildir, pas de nom de fichier unique, pas de sémaphores) ;
    • l'élève ne sait pas correctement utiliser la programmation système C de base (création de répertoire, manipulation de fichier), il réalise les opérations en shell via la commande système la plus inefficace qui soit : system.
  • exécutable MTAin :
    • même problème concernant la fonction gestionSmtp_in, soit dit en passant l'élève ne maîtrise même pas la factorisation de code basique : les fonctions gestionSmtp_ext et gestionSmtp_in ont une majorité de code en commun et donc dupliqué ;
    • la fonction de résolution DNS est incluse dans la bibliothèque SMTP et pas Communication comme cela était évident, toujours pas de maîtrise de la notion de bibliothèque ;
    • là encore l'élève ne respecte pas le sujet, uniquement le premier MX est testé (une simple boucle aurait suffit) et rien n'est prévu en cas d'absence de MX ;
    • un code pour la transmission du courriel au serveur de destination mais écrit avec les primitives de bas niveau send et recv alors que l'élève avait sous les yeux un exemple d'utilisation des f-fonctions (son propre code théoriquement) pour la réception des courriels, les codes de retour du serveur de destination ne sont même pas testés.

Une absence totale de maîtrise du rendu via la syntaxe mediawiki : les images ne sont pas incluses mais sous la forme de liens. D'ailleurs pourquoi mettre des images de terminal de commandes ? Un simple texte aurait suffit et aurait été plus lisible.

En conclusion, du coté positif un code a été écrit pour donner l'illusion d'un travail finalisé. Malheureusement ce code ne respecte pas le sujet, est de mauvaise qualité et montre de graves lacunes dans les compétences de l'élève dans les domaines de la programmation en C, de la structuration d'un code et de la programmation système et réseau.