PROJET APPROFONDISSEMENT D’INFORMATIQUE – CARTE BANCAIRE
E3 ANTON RAVEENDRAN Joyston BELIN Théo
Encadré par M.COUSTY
Sommaire :
I- Introduction : ……… 3
II- Mode d’emploi : ……… 4
III- Manuel technique : ………... 5
a. Les questions préliminaires au projet : ………. 5
b. Version 1 : Programmes individuels : ………... 7
c. Version 2 : Tubes et processus : ………. 8
d. Version 3 : Implémentation des threads : ………. 9
e. Version 4 : Ajout de l’annuaire : ………. 10
f. Version 5 : Création d’un serveur interbancaire : ………. 11
g. Gestion d’Interblocage : ………12
IV- Conclusion : ………. 13
I- Introduction :
Ce projet a pour but de créer de simuler les échanges entre banques permettant à un particulier de payer ses achats avec sa carte bancaire via un terminal de paiement. Notre système devra fonctionner avec tous les types de cartes bancaires que ce soit de la même banque ou d’une banque différentes.
Pour ce faire, le système de paiement par carte bancaire comporte plusieurs acteurs : - Le client qui utilise sa carte bancaire pour effectuer un achat
- Le commerçant qui utilise son terminal de paiement pour effectuer la transaction de la vente.
- La banque du commerçant, qui crédite la somme de la transaction sur son compte.
- La banque du client, qui débite la somme de l’achat.
Comment fonctionne une transaction ?
Au niveau de la banque, nous avons plusieurs infrastructures qui permettent d’effectuer une transaction entre un client et un marchand.
Tout d’abord, lorsque le client insère son carte bancaire dans le terminal, il y a une demande qui est créé et envoyé via la ligne téléphonique au serveur d’acquisition de la banque du commerçant. Ensuite, il y aura une vérification du compte du client afin de savoir s’il appartient à la même banque que le commerçant.
Si oui, la demande de transaction du client est transmise au serveur d’autorisation qui vérifiera si le compte est provisionné ou pas et retournera un message d’acceptation ou de refus de la transaction au serveur d’acquisition, qui fera de même vers le terminal.
Si non, la demande de transaction du client est transmise au serveur interbancaire qui route vers le serveur d’acquisition de la banque du client, qui enverra la demande de transaction vers le serveur d’autorisation qui vérifiera s’il y a assez d’argent ou pas et retournera un message d’acceptation ou de refus de la transaction au serveur d’acquisition, qui fera de même vers le terminal.
Par conséquent, notre projet sera simulé par un exécutable qui enverra le numéro de la carte bancaire parmi une liste ainsi que le montant de transaction. La carte bancaire comportera 16 chiffres.
II- Mode d’emploi :
Notre projet fonctionne parfaitement avec une seule banque, soit un serveur d’autorisation, un serveur d’acquisition et avec 𝑛 terminaux.
Pour lancer la simulation, il faut d’abord qu’on récupère tous les fichiers qui sont dans le dossier « Système_Bancaire_1Banque », puis on compile l’ensemble des fichiers via la commande « make » sur un terminal Linux. Après avoir compilé le programme, nous avons plusieurs exécutable qui s’y sont créés. Si on désire lancer la simulation de façon automatisé, nous pouvons rentrer sur le terminal « ./acq ».
En revanche, si on désire tester le terminal de paiement, nous pouvons rentrer :
« ./term 1 0 »
Le terminal de paiement nous demande la réponse en affichant la demande :
|0000966310640705|Demande|35|
De ce fait, si nous rentrons |0000966310640705|Reponse|1|, cela va retourner que le paiement a été accepté. En revanche, si nous rentrons |0000966310640705|Reponse|0|, cela veut signifier que le paiement est refusé.
D’autre part, si on désire tester le serveur d’autorisation, nous pouvons rentrer sur le terminal « ./auto 1 0 ».
Pour vérifier le bon fonctionnement du serveur d’autorisation, nous devons rentrer une demande, par exemple, |0000255536376848|Demande|694|.
De ce fait, le serveur d’autorisation vérifie si le compte est provisionné et retourne une réponse :
|0000255536376848|Reponse|1| ; ce qui veut dire que le compte est provisionné.
|0000255536376848|Reponse|0| ; ce qui veut dire que le compte n’est pas provisionné.
Enfin, si on désire arrêter l’un des exécutables, nous devons le faire manuellement via la commande « Ctrl+C ».
Si on désire générer un nouvel annuaire, nous le pouvons en écrivant sur le terminal la commande suivante :
« ./annuaire nb_banque nb_carte » avec nb_banque et nb_carte des variables à remplir.
Dans un second temps, notre programme comportant plusieurs banques avec un serveur interbancaire, fonctionne « à moitié », c’est-à-dire qu’il plante lors de la transmission de la demande vers le serveur interbancaire.
Cependant, si on désire le tester, il faut d’abord qu’on récupère tous les fichiers qui sont dans le dossier « Système_Interbancaire_2Banque », puis on compile l’ensemble des fichiers via la commande « make » sur un terminal Linux. Après avoir compilé le programme, nous avons plusieurs exécutable qui s’y sont créés. Si on désire lancer la simulation de façon automatisé, nous pouvons rentrer sur le terminal « ./SI ».
III- Manuel technique :
a. Les questions préliminaires au projet :
Pour réaliser ce projet, nous avons tous d’abord répondu à des questions prépondérantes pour la suite du projet :
1/ Combien de processus seront créés dans le projet ?
Dans ce projet, nous avons au minimum 3 processus (un terminal, un serveur d’acquisition, un serveur d’autorisation), si nous avons qu’une seule banque et un terminal.
Dans notre exemple avec 2 banques et un terminal, nous avons 6 processus au minimum (un terminal, 2 serveurs d’acquisition, 2 serveurs d’autorisation, un serveur interbancaire).
De ce fait, dans le cas général, nous avons n banques, et m terminaux.
Donc, nous aurons (2𝑛 + 𝑚 + 1) processus : - 𝑛 serveurs d’acquisition
- 𝑛 serveurs d’autorisation - 1 serveur interbancaire - 𝑚 terminaux
2/ Combien d'exécutables allez-vous programmer ? Est-ce que un seul exécutable est acceptable ?
Nous allons programmer 4 exécutables : - Les terminaux
- Le serveur d’acquisition - Le serveur d’autorisation - Le serveur Interbancaire
Un seul programme n’est pas réellement concevable du fait que s’il y a des erreurs de compilation ou d’exécution, nous aurons une plus grande difficulté à résoudre le problème. Or, si nous faisons les programmes séparément, nous les testons aussi séparément et ensuite, on les assemble uniquement s’il fonctionne séparément. Cela nous nous permettra de régler les erreurs s’il y en a !
3/ Qui (quel processus) est créé par qui ?
Le programme Serveur Interbancaire crée le processus d’Acquisition de chaque banque. Ensuite, les processus Acquisition créera les processus terminaux et le processus d’Autorisation de la banque en question.
4/ Dessinez l'arbre des processus du projet.
Autorisation Bénépé Acquisition
Bénépé
Terminal
Serveur Interbancaire
Acquisition C.C.
Autorisation
C.C. Terminal
5/ Combien de tubes sont nécessaires pour le projet ? Nous avons 𝑛 banques et 𝑚 terminaux, donc nous avons :
- 2𝑛 tubes du réseau interbancaire vers l’acquisition - 2𝑛 tubes de l’acquisition vers l’autorisation - 2𝑚. 𝑛 tubes des terminaux vers l’acquisition Par conséquent, nous avons 4𝑛 + 2𝑚. 𝑛 tubes.
6/ Quels types de tubes allez-vous utiliser ?
Nous allons utiliser des tubes non nommées, nous n’avons pas besoins de les nommer car nous les transmettons directement dans les paramètres.
7/ Qui (quel processus) crée quels tubes
De la même manière que les processus, le processus Serveur Interbancaire crée les tubes d’Acquisition de chaque banque. Ensuite, le processus Acquisition créera les tubes des terminaux et le tube d’Acquisition de la banque en question.
Il faut savoir, que les tubes dans notre projet, il y a une en réception et une en envoie.
8/ Dessinez vos processus et vos tubes.
Autorisation Bénépé
Acquisition Bénépé
Terminal
Serveur
Interbancaire Acquisition C.C.
Autorisation C.C.
b. Version 1 : Programmes individuels
Dans cette partie, nous avons mis en place de façon indépendante les différents programmes qui permettront de créer un réseau bancaire.
Tout d’abord, nous avons un programme qui exécute la demande de transaction du client, il s’agit du Terminal. Ensuite, nous avons le programme Acquisition qui récupère la demande et envoie au serveur d’autorisation la demande de transaction. Enfin, nous avons le programme Autorisation qui vérifie que le compte soit approvisionné et renvoie le message d’acceptation ou de refus.
Dans cette première partie, tout est codé en dure et testé séparément !
C’est pourquoi, comme nous pouvons le voir sur les captures d’écran ci-après, à chaque fois, nous rentrons une demande avec un numéro de carte bancaire, nous avons directement la réponse.
Ici, il n’y a en aucun cas une communication entre le Terminal, l’Acquisition et l’Autorisation ; il s’agit de tester la compréhension de la demande et donc la réponse est écrite en dure dans chaque programme.
Par conséquent, nous venons de voir grâce à ces programmes basiques que l’affichage d’une réponse lors d’une demande est fonctionnel.
Dans la partie suivante, nous allons mettre en place des tubes afin que la demande de transaction effectuée par le Terminal transite par l’Acquisition et arrive à l’Autorisation et effectue le chemin inverse pour donner une réponse soit d’acceptation ou de refus du paiement.
Terminal :
Acquisition :
Autorisation :
c. Version 2 : Tubes et processus
Dans la version précédente, nous n’avions pas de communication entre les différents acteurs d’une transaction. De ce fait, dans cette partie nous allons mettre en place une communication via des tubes, pour que la demande de transaction effectuée par le Terminal transite par l’Acquisition et arrive à l’Autorisation et effectue le chemin inverse pour donner une réponse soit d’acception, soit de refus du paiement.
Tout d’abord, le Terminal comporte deux tubes, l’un pour envoyer la demande de transaction et l’autre pour lire la réponse en provenance du serveur d’acquisition.
Ensuite, l’Autorisation, quant à lui, comporte deux tubes comme pour le Terminal, l’un pour recevoir la demande que le serveur d'acquisition a transmis et l'autre pour envoyer la réponse toujours au serveur d'acquisition.
Enfin, le serveur d’acquisition crée les tubes précédemment cités, c’est-à-dire ceux qui sont reliés au Terminal et au serveur d’Autorisation. Pour les tubes liés au Terminal, ils sont multipliés par le nombre de terminaux.
Pour avoir plusieurs terminaux, le serveur d'acquisition créé plusieurs processus. Les tubes nécessaires pour ces processus seront donc stockés dans un tableau à taille dynamique.
En revanche, cette version du programme n’est pas réellement satisfaisante. En effet, pour que le terminal n°2 puisse payer il faut que le terminal n°1 fasse obligatoirement une transaction.
Ceci n’est bien sûr pas acceptable.
Autorisation Bénépé
Acquisition Bénépé
Terminal
Serveur
Interbancaire Acquisition C.C.
Autorisation C.C.
Terminal
d. Version 3 : Implémentation des threads
Il faudrait donc implémenter des threads pour pouvoir effectuer une écoute des tubes.
Comme le montre le schéma ci-dessus, les threads exécuteront une fonction différente en fonction de s’ils sont en charge d’écouter un terminal, du serveur d’autorisation ou encore du serveur interbancaire.
Tout d’abord, nous avons mis en place une table de routage. Cette table permet de conserver le numéro de carte bancaire et le tube par lequel renvoyer la réponse. Ce sera la fonction lié au terminal et au serveur interbancaire qui remplira cette table. Afin d’éviter d’éventuelle problème de suppression de donnée utile, l’accès à la table se fait que part un seul thread à la fois grâce à un sémaphore.
Le thread lié au terminal marche de la sorte. Après avoir reçu un message provenant du terminal, la fonction va accéder (s’il le peut, sinon attendre jusqu’à ce qu’il puisse) à la table de routage pour y renseigner le numéro de carte bancaire et l’identifient du tube où la réponse devra est envoyé. Ensuite, le thread comparera les 4 premiers chiffres de la carte bancaire au numéro de la banque à laquelle il est lié. Ce numéro sera passé en paramètre lors de la création du thread. Si les numéros correspondent alors le thread redirigera le message vers le serveur d’autorisation sinon il sera redirigé vers le serveur interbancaire.
Le thread lié au serveur d’autorisation, quant à lui, après avoir reçu un message accédera à la table de routage (s’il le peut, sinon attendre jusqu’à ce qu’il puisse) pour pouvoir rediriger la réponse via le tube correspondant au numéro de carte bancaire de la réponse. Après avoir trouvé dans la table le bon numéro de carte et enregistré dans une variable temporaire l’identifient du tube, le thread met la valeur NULL dans les 2 cases du tableau. Pour finir, ce thread redirigera la réponse.
Terminal Acquisition
Autorisation
Serveur Interbancaire Thread
Thread
Table de routage
Thread
Thread
Le serveur interbancaire n’étant encore créé, cette partie était en commentaire afin de pouvoir tester si, déjà, le programme marchait avec seulement 2 terminaux et 1 banque. Ce thread devra, après réception du message, vérifier s’il s’agit d’une demande ou d’une réponse.
Si le message correspond à une demande alors le thread accédera à la table de routage et enregistrera le numéro de carte et l’identifient du tube de réponse (en écriture). Le message sera ensuite redirigé vers le serveur d’autorisation. S’il s’agit d’une réponse alors le thread regardera dans la table de routage pour récupérer l’identifient du tube correspondant au numéro de carte de la réponse puis mettra ses cases la valeur NULL.
Les identifiants des tubes par lesquelles les threads redirigeront le message seront, comme pour le numéro de banque, passé en paramètre lors de la création du thread. Afin de tester le bon fonctionnement, nous avons limité le nombre de demande que les terminaux font et afficher les messages rediriger.
e. Version 4 : Ajout de l’annuaire
Dans nos précédentes versions, nous avons créé des transactions à partir des numéros de cartes bancaires écrites en dure dans le Terminal pour effectuer les demandes de transactions.
D’autre part, nous avons aussi ces numéros de cartes bancaires dans Autorisation, afin de vérifier si le compte est provisionné mais aussi si la carte bancaire existe.
Le problème de l’implémentation en dure des numéros de cartes bancaires est qu’on est limité à quelques cartes bancaires, dans notre cas, nous en avons mis trois.
Nous pouvons bien sûr, rentrer beaucoup de numéro de carte bancaire à la main mais cela prendrai beaucoup de temps.
Pour résoudre ce problème, nous avons utilisé la bibliothèque d’annuaire fournie par M.COUSTY. Ce dernier permet de créer des numéros de carte bancaire de façon aléatoire, en lui affectant aussi un solde.
Pour cela, nous créons l’annuaire via la fonction qui lui est dédié dans la bibliothèque.
Cette fonction met en place une structure avec des tableaux. De ce fait, lorsqu’une demande de transaction, le programme Terminal récupère un numéro de carte bancaire au hasard dans le tableau de carte bancaire.
Enfin, nous avons le même schéma de fonctionnement dans Autorisation, qui lit l’annuaire qui a été créée, puis vérifie si le numéro de carte bancaire existe ou pas dans l’annuaire et vérifie si le compte est provisionné.
f. Version 5 : Création d’un serveur interbancaire
La version 5 ajoute le serveur interbancaire à l’ensemble du programme. Les fonctions effectuées par le serveur interbancaire ressemblent à ceux du serveur acquisition. En effet, tous deux vont avoir à écouter en parallèle plusieurs tubes et à rediriger un message au bon endroit.
Pour cela, ils utilisent les threads pour une écoute en parallèle des tubes et une table de routage pour effectuer la redirection des messages au bon endroit.
Tout d’abord, le serveur interbancaire réservera de la mémoire pour les identifiants des tubes entre serveur interbancaire et les différents serveurs d’acquisition. Le nombre de tube sera X*2, X étant le nombre de banques souhaitées et donc de serveurs d’acquisition qui sera indiquée en paramètre de la fonction. Une table de routage des demandes est initialisée avec NULL dans toutes ses cases. La table de routage de demande sert pour qu’une fois la demande traitée et retourné au serveur d’acquisition, le thread renvoie la réponse au bon serveur d’acquisition.
Une fois les tubes créés, la table de routage des banques peut d’ores et déjà être remplie.
Contrairement à la table de routage des banques contenue dans les serveurs d’acquisition, la table de routage des banques du serveur interbancaire est en “statique” dans le sens où elle a besoin d’être rempli une seule fois puis les valeurs qu’elle contient ne changeront plus.
Le serveur interbancaire doit ensuite créer X processus qui rempliront la tâche de serveur d’acquisition. Les identifiants de tubes permettant la communication entre le serveur interbancaire et le serveur d’acquisition seront donnés en paramètre lors de l’”excve”.
Remarquons que c’est le même procédé que lorsqu’un serveur d’acquisition crée le serveur d’autorisation de sa banque par exemple. Le numéro de banque des serveurs d’acquisition est aussi passé en paramètre.
Pour chaque processus créé nous lui avons passé en paramètre un identifient de tube d’écriture d’une demande et un identifient du tube de lecture pour attendre une réponse du serveur interbancaire. Le tube d’écriture est utilisé par les threads d’écoute du terminal et d’autorisation qui, s’il constate que les 4 premiers chiffres de la carte bancaire ne correspondent pas à leur banque, permettront au serveur interbancaire de remplir son rôle de liaison entre les banques. Le tube de lecture est quant à lui utilisé par une fonction d’écoute d’une réponse qui redirigera le message sois vers le serveur d’autorisation si le message est du type “Demande”
ou vers le terminal à l’origine de la demande si le message est du type “Reponse”.
Pour finir, serveur interbancaire créera des threads permettant l’écoute en parallèle des serveurs d’acquisition. La fonction d’écoute fera simplement de la redirection de message vers le bon serveur d’acquisition.
Le serveur interbancaire aura donc à créer 𝑋 thread. La fonction d’écoute permettra de rediriger le message vers le bon serveur d’acquisition et, si le message est une demande, rajouter à la table de routage de demande le numéro de carte bancaire et le tube où la réponse devra être renvoyée.
g. Gestion d’Interblocage :
Au niveau de notre programme, il ne peut y avoir d’interblocage car nous avons utilisé des sémaphores. En effet, nous devions empêcher tout souci de suppression d'une demande qui n'aurait pas été traitée bloquant ainsi un terminal indéfiniment. Le sémaphore permet donc l'accès à la table de routage à un seul thread à la fois.
En revanche, si nous avons beaucoup de terminal, le programme plantera. Cela est dû uniquement au fait que nous avons fixé une petite taille. Néanmoins, cela est changeable, donc ce souci peut être réglé via un changement de valeur.
IV- Conclusion :
En conclusion, ce projet d’approfondissement en informatique, plus particulièrement en Système d’exploitation, nous a permis d’approfondir nos connaissances sur le fonctionnement de transmission de données via des tubes, la gestion des processus et même des threads.
Ce projet de simulation d’un système bancaire met bien en avant tous les aspects de transmission de données. Cela est dû au fait qu’un client lambda qui achète un article via sa carte bancaire dans un magasin, va l’insérer sur un terminal de paiement. Puis, à partir de ce moment-là, il y une multitude de traitements qui se passe afin que client soit informé si son paiement est accepté ou non. Le terminal de paiement récupère le numéro de carte bancaire ainsi que le montant de la transaction et émet un message via un tube vers le serveur d’acquisition de la banque du commerçant. Ce dernier vérifie si la carte bancaire appartient à la même banque. Si c’est le cas, alors elle transmet, via un tube, la demande de transaction au serveur d’autorisation qui vérifiera si le compte a assez de fond. Si ce n’est pas le cas, le message est transmis via un tube vers le serveur interbancaire qui s’en chargera de le transmettre à la bonne banque. Lorsque le bon serveur d’autorisation aura fait ses vérifications, la réponse fera le chemin inverse via de nouveaux tubes jusqu’au terminal, pour qu’elle soit affichée.
Toutes ces instructions sont effectuées en parallèle à l’aide de processus et de threads, afin de traiter plusieurs demandes et que la réponse soit transmise le rapidement possible au client.
