Rapport de synthese UNIX TP

Ceci est le résultat d’un travail scolaire. Rapport original.

Rapport de synthèse UNIX TP

Banque : TP Unix – Janvier 2002 (c) 2002 Lai Yuk Ngan, Rémi Peyronnet
Choix techniques
Autres difficultés
Améliorations
Commentaires personnels
RFC
Le code

I) Les choix techniques

I.a) UDP : conseillé dans le sujet

I.b) Informations en mémoire

Nous avons décidé de stocker les informations sur les comptes et les chèques dans un tableau en mémoire pour les raisons suivantes :

  • Ecrire nos structures sur le disque revient en fait à gérer une mini base de données, ce n’est pas le but du TP.
  • Cela est beaucoup plus simple dans une première approche,
  • Nous avons cherché à éviter les listes chaînées,
  • Le système adopté (fichier de log réanalysé) répond parfaitement aux besoins.

I.c) Le problème d’attente : La solution d’une Banque “stateless”

Problème :

On a surtout connu beaucoup de problèmes dans la conception des transactions qui exigent l’attente des réponses. Par exemple, lorsqu’un serveur de ventes demande l’encaissement d’un chèque émis par Banque B auprès de Banque A, Banque A est obligée d’attendre un message de confirmation de la part de Banque B avant de créditer le serveur de ventes. En attendant pendant une longue durée, ses activités risquent d’être paralysées.

Solution :

Lorsque l’on a besoin d’une réponse, on a éludé le problème en se plaçant dans un fonctionnement “stateless”, et donc en n’ayant pas besoin de retenir quelle réponse On attend : tous les éléments nécessaires seront contenus dans la réponse. Dans le cas contraire, il aurait fallu définir une liste chainée de réponses en attente, ou définir un thread différent (avec éventuellement une connexion TCP avec l’autre banque),…

Pour résoudre le problème de traitement des chèques :

Si le chèque n’est pas dans notre banque, nous envoyons un message à l’autre banque, puis nous continuons comme si de rien n’était. La banque se contente donc de recevoir des messages, d’y apporter une réponse immédiate, et de continuer.

II) Autres difficultés rencontrées

II.a) SOCKETS

Au début, nous avons eu du mal à comprendre comment utiliser les fonctions de création de sockets qui sont définies dans le poly, pages 34 et 35, surtout avec les fonctions strtok( ) et gethostbyname(). Au début, ce manque de familiarité avec certaines fonctions, les types des paramètres, et l’omission de certaines bibliothèques ont entraîné beaucoup d’erreurs de compilation.

II.b) CONCEPTION

Nous avons mis beaucoup de temps dans la conception des transactions qui exigent l’attente des réponses (notamment pour les fonctions de virement et d’encaissement des chèques) .

Exemple : on a besoin pour les chèques / virements hors de notre banque d’interroger l’autre banque et d’attendre la réponse. Solution “stateless”(voir ci-dessus).

Envoi du relevé R# au client : on a besoin de stocker l’adresse du client, ce qui nous a posé des problèmes car le client n’a plus de connexion directe avec la banque lorsque le cheque est encaissé.Solution : garder en mémoire la dernière adresse connue du client.

II.c) VERIFICATION : Gestion d’erreurs dans la fonction « Virement »

On aurait pu élaborer la fonction « virement » en exigeant une confirmation d’un virement réussi (que lenuméro de compte à créditer est valable) de la part de l’autre banque avant de débiter le compte émetteur.Faute de temps, nous avons décidé de faire la supposition que les banques pourraient éventuellement garder un « log » de toutes les transactions, qui permettrait la rectification de toutes erreurs. La vérification sera une amélioration importante.

II.d) SECURITE

Comment vérifier si toutes les banques sur le port 3000 sont en fait des banques « légitimes » ? Il y a évidemment un problème de sécurité (une banque fictive, par exemple), et ce sera une amélioration d’implémenter une procédure de vérification des banques.

III) Les améliorations

  • Faire une petite fonction pour compacter le fichier de log. : C’est en fait très simple : il suffit d’analyser le fichier de log, puis de “dumper” le contenu des tables. Le contenu des tables remplace alors intégralement tous les logs précédents.
  • Inscription dynamique de banques.
  • Vérifications lors des virements.
  • Plus de sécurité

IV) Commentaires personnels

Le TP est très long pour le nombre de séances qu’on a eu, et le TP exige d’aborder beaucoup de problèmes de conception (ex. La gestion des listes de données) qui ne sont pas directement lies à la compréhension du fonctionnement des sockets/des communications. Un TP plus court et focalisé sera apprécié.

Plus d’explication sur l’utilisation de nouvelles fonctions de sockets pendant le cours sera apprécié.

Il est possible de réaliser le TP sans passer par la création de processus, ni de communication interprocessus.

V) RFC Utilisée

 

 

Le code

server.c : Le code du serveur
client.c : Un client pour envoyer des infos DEBUG
Makefile : Le Makefile
Fichiers d’exemple
Quelques scripts utiles

Server.c

client.c

Makefile

Exemples

peyronnet.in

shinji.in

test.in

overflow.in

Quelques scripts utiles

restore.sh

start_server.sh

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Fermer le menu