Discussion:IMA4 2021/2022 EC5 : Différence entre versions
(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 | + | * 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
danslibcom
récupérée d'un autre projet ; - fonction
trouve_mx
danslibSMTP
qui appelle la fonction ci-dessus.
Mise à jour du 29 août :
- du code mort dans
libSMTP
; - la fonction
GetMXRecord
est retirée delibcom
; - fonction de connexion à un serveur TCP ajoutée dans
libcom
; - fonction
resoud_mx
remplaçantGetMXRecord
mise danslibSMTP
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
danslibSMTP
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 ennomVersAdresse
(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 localehost
alors que la fonctionconnexionServeur
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
.
- répertoire pratiquement vide, appel, pour chaque client, d'une fonction
- 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 fonctionsgestionSmtp_ext
etgestionSmtp_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
etrecv
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.
- même problème concernant la fonction
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.