Vous êtes sur la page 1sur 20

Simulation dun systme de paiement par carte bancaire

Mini projet IN301/IN3ST01 - 2006-2007 Daprs un projet de Jrome Gueydan pour lENSTA

15 novembre 2006

Table des matires


1 Introduction 1.1 Le principe du paiement par carte bancaire . . . . . . . . . . . . . . . 1.2 La demande dautorisation . . . . . . . . . . . . . . . . . . . . . . . 1.3 Le routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Cahier des charges 2.1 Cahier des charges fonctionnelles . . . 2.1.1 Architecture fonctionnelle . . . 2.1.2 Le terminal . . . . . . . . . . . 2.1.3 Le serveur dacquisition . . . . 2.1.4 Le serveur dautorisation . . . . 2.1.5 Le rseau interbancaire . . . . . 2.2 Cahier des charges techniques . . . . . 2.2.1 Contraintes gnrales . . . . . . 2.2.2 Nombre de processus . . . . . . 2.2.3 Paramtres . . . . . . . . . . . 2.2.4 Gestion des changes par tuyaux 2.3 Comment tester sans sy perdre ? . . . . 2.4 Livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 5 6 6 7 7 8 8 9 9 9 9 9 9 10 10 10 11 11 11 11 12 12 12

3 Conduite du projet 3.1 Introduction . . . . . . . . . . . . . . . . . . . . 3.1.1 Un projet en plusieurs tapes . . . . . . . 3.1.2 Mthode diviser pour rgner . . . . . . 3.2 Etape 1 : les fonctions de communication . . . . 3.3 Etape 2 : ralisation de programmes indpendants 3.3.1 Processus : Autorisation . . . . . . . . .

3.4

3.5

3.3.2 Processus : Acquisition . . . . . . . . . . . . 3.3.3 Processus : Terminal . . . . . . . . . . . . . Etape 3 : cration du rseau bancaire . . . . . . . . . 3.4.1 Prparation de la communication par tuyaux . 3.4.2 Raccordement . . . . . . . . . . . . . . . . Etape 4 : cration du rseau interbancaire . . . . . . 3.5.1 Processus : Interbancaire . . . . . . . . . . . 3.5.2 Raccordement . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

12 13 13 13 13 14 14 14 14 14 15 15 15 15 16 16 17 17 18 18 18

4 volutions complmentaires et optionnelles 4.1 Cumul des transactions . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Dlai dannulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Utilisation de socket . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Annexes 5.1 De lintrt des standards pour assurer une meilleure interoprabilit 5.2 Spcications de protocoles de communication . . . . . . . . . . . 5.2.1 Un format de message unique . . . . . . . . . . . . . . . . 5.2.2 Protocole du terminal . . . . . . . . . . . . . . . . . . . . . 5.2.3 Protocole du rseau interbancaire . . . . . . . . . . . . . . 5.2.4 Le serveur dautorisation . . . . . . . . . . . . . . . . . . . 5.3 Gnrateur alatoire . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Redirection des entres et des sorties . . . . . . . . . . . . . . . . . . . . . . . . .

Avertissement
Le projet suivant est faire par groupe de deux tudiants (en une sance de TD de 2h, deux sances de TP de 3h, 15h de projet encadr, plus un petit travail personnel si ncessaire), et rendre pour janvier 2007, une date qui sera prcise ultrieurement. Pour faire court, sachez que tous les projets semblables auront une note de zro, et que les auteurs seront convoqus en conseil de discipline. Ceux qui arriveront faire la preuve quils ont crit le projet duquel les autres se sont inspirs nauront aucune pnalit supplmentaire par rapport la note de zro. Si vous faites le projet plus de deux, un coefcient de rduction proportionnel sera appliqu. Par exemple, si vous faites le projet trois, la note sera rduite dun tiers. Aucun bonus ne sera donn pour un tudiant travaillant seul.

Plagiat
Le plagiat est lutilisation, sans citation approprie, du travail intellectuel dune autre personne dans un travail soumis valuation. Ce qui suit est trs fortement inspir et traduit de la page http ://www.csd.abdn.ac.uk/teaching/handbook/both/info.php?lename=cheating.txt.

Quand vous crivez un rapport ou du code qui contient des parties ou qui paraphrase le travail dautres personnes, vous devez clairement le signaler. En particulier, les citations doivent tre donnes entre guillemets, avec les rfrences appropries. 1. Le code soumis pour valuation doit clairement tre annot avec le nom de ltudiant qui a soumis lexercice, avec la date de rdaction. 2. Quand un exercice contient du code qui na pas t crit par ltudiant qui soumet le travail, ou contient du code crit par ltudiant lui-mme un autre moment, le code en question doit tre clairement identi et annot avec le nom de lauteur, le copyright (si diffrent), la date dachvement ou de publication, et une rfrence la source (par exemple une URL ou une rfrence bibliographique). 3. En principe, la discussion avec dautres tudiants du contenu du cours et des exercises non-valus est encourage, car une telle discussion amne gnralement une meilleure comprhension du sujet. Cependant, les discussions doivent rester un niveau gnral, et ne doivent pas descendre un niveau dtaill de conception ou de codage. Le travail soumis pour valuation doit tre un travail individuel. Si vous soummettez un travail produit conjointement avec une autre personne, ou qui inclus le travail de quelquun dautre, ceci doit tre clairement indiqu, et le code en question doit tre clairement identi. Lvaluation du travail se fera sur la base de la valeur ajoute par ltudiant. 4. De manire identique, bien que nous encouragions la r-utilisation de logiciel existant comme une bonne pratique dIngnirie Logicielle, les origines dune telle r-utilisation doivent tre clairement indiques, et le code identi. Lvaluation du travail se fera sur la base de la valeur ajoute par ltudiant. 5. Quand le travail est raliser en groupe de deux tudiants, le rapport crit ou le travail doit clairement identier et distinguer ce qui a t ralis par un des tudiants, ou ce qui a t fait par le groupe en entier.

Consignes
Vous devez menvoyer avant janvier 2007 dernier dlai (la date effective sera prcise ultrieurement) une archive comprime en tar.gz, contenant le code, le makele, et les rapports du projet sous format electronique. Les rapports papiers doit tre dposs le mme jour au secrtariat A2SI. Un barme de moins deux points par jour de retard sera appliqu. Une archive qui ne sera ni du tar.gz ni du .zip ne sera pas corrige. Le projet devra se compiler en excutant la commande make sur une machine tournant Linux. Un projet qui ne respectera pas cette consigne ne pourra pas tre corrig. Le rapport du projet dcrira les diverses solutions aux diffrents problmes encontrs, et justiera la solution choisie. Votre note dpendra de la qualit du rapport, et de la qualit du code. Le barme prend en compte pour une part la rdaction de la rponse, et galement lcriture du code correspondant aux choix que vous aurez fait. Vous pourrez donc avoir des points si vous navez pas programm vos propositions, mais vous

naurez pas forcment tous les points si le code que vous aurez crit nest pas proprement justi. Les consignes de remises du projet seront prcises sur la page web du cours. Dautres lments, comme le barme dvaluation, y seront galement nots.

Remarque
Lnonc peut sembler pais de prime abord. Ce nest pas le cas : il se rsume aux pages 4 10. Le reste du document a pour objectif de vous aider dans la ralisation du projet, en indiquant des lments de solutions, en attirant lattention sur les points essentiels, et en donnant une dmarche saine de progression. Ce projet est repris de celui propos par Jrome Gueydan http ://www.ensta.fr/ gueydan/IMG/pdf/IN201_projet_2008.pdf Les deux projets ne sont cependant pas strictement identiques.

1 Introduction
Lobjectif du projet est de simuler les changes entre banques permettant un particulier de payer ses achats avec sa carte bancaire (dite carte bleue), mme si celle-ci nest pas mise par la mme banque que celle du vendeur. Avant de prsenter le sujet, examinons le fonctionnement du paiement par carte bancaire.

1.1 Le principe du paiement par carte bancaire


Le paiement par carte bancaire met en relation plusieurs acteurs : le client, qui souhaite rgler un achat avec la carte bancaire quil possde et qui lui a t fournie par sa banque (le Crdit Chaton) ; le commerant, qui est quip dun terminal de paiement fourni par sa propre banque (la Bnp) ; la banque du commerant (la Bnp) laquelle est connecte le terminal de paiement ; la banque du client (le Crdit Chaton) qui va dire si la transaction est autorise (donc si le compte de son client est sufsamment provisionn ou non). Le terminal du commerant est reli la banque Bnp grce une simple ligne tlphonique. La banque Bnp est connecte toutes les autres banques installes en France, et notamment au Crdit Chaton, grce un rseau ddi : le rseau interbancaire (voir g. 1). Supposons maintenant que le client lambda se rend chez son revendeur de logiciels prfr pour acheter la toute dernire version du systme dexploitation FENETRES. Au moment de passer en caisse, il dgaine sa carte bancaire, le caissier linsre dans son terminal de paiement et le client doit, aprs avoir regard au passage la somme quil sapprte dbourser, saisir son code condentiel.

Terminal commerant

Rseau tlphonique

Banque Bnp

Rseau Interbancaire

Banque Crdit Chaton

Fig. 1 Principe de communication des tlphones et du central Ce code est directement vri par la carte (plus exactement par la puce contenue dans la carte). Si le code est erron, la transaction sarrte l. Si le code est bon, en revanche, les oprations suivantes ont lieu : 1. Le terminal se connecte (via le rseau tlphonique) au serveur de la banque Bnp et envoie le numro de la carte bancaire ainsi que le montant de la transaction. 2. Le serveur de la banque Bnp regarde le numro de la carte et, se rendant compte quil ne sagit pas dune des cartes quil a mises, envoie le numro de carte avec le montant de la transaction au serveur de la banque Crdit Chaton, via le rseau interbancaire permettant de relier les diffrentes banques. 3. Le serveur de la banque Crdit Chaton prend connaissance du numro de la carte bancaire et vrie que le compte correspondant ce numro dispose dun solde sufsant pour honorer la transaction. 4. Si cest le cas, il rpond la banque Bnp (toujours via le rseau interbancaire) que le paiement est autoris. Si ce nest pas le cas, il rpond le contraire. 5. Enn, le serveur de la banque Bnp transmet la rponse au terminal du commerant. 6. La transaction est valide (paiement autoris) ou refus (paiement non autoris).

1.2 La demande dautorisation


La suite des oprations dcrites ci-dessus se nomme la demande dautorisation et a essentiellement pour but de vrier que le compte client est bien provisionn (ou 5

quil a une autorisation de dcouvert). Cette demande dautorisation nest pas systmatique et dpend du terminal1, lequel prend par exemple en compte le montant de la transaction. La demande dautorisation transite via deux serveurs diffrents : Le serveur dacquisition - Il sagit du serveur de la banque du commerant auquel se connecte le terminal via le rseau tlphonique. Une fois connect, le terminal envoie au serveur dacquisition toutes les informations concernant la transaction, notamment le montant, le numro de carte et des donnes permettant dassurer la scurit de la transaction. Le serveur dautorisation - Il sagit du serveur de la banque du client auquel le serveur dacquisition transmet lautorisation de paiement mise par le terminal. La rponse la demande suit le chemin inverse, savoir serveur dautorisation de la banque du client serveur dacquisition de la banque du commerant terminal du commerant.

1.3 Le routage
Pour effectuer le routage des demandes dautorisation, cest--dire pour dterminer quelle banque chaque demande dautorisation dot tre transmise, le serveur dacquisition utilise les premiers numros de chaque carte bancaire concerne : ceux-ci indiquent la banque ayant mis cette carte. Dans ce projet, nous partirons des principes suivants : un numro de carte est constitu de seize chiffres dcimaux ; les quatres premiers correspondent un code spcique chaque banque ; les serveurs dacquisition des banques sont directement relis au rseau interbancaire. Chaque serveur dacquistion analyse donc le numro de la carte qui gure dans la demande dautorisation quil reoit, puis : si le client est dans la mme banque que le commerant (et que le serveur dacquisition), il envoie la demande directement au serveur dacquisition de cette banque ; si le client est dans une autre banque, le serveur dacquisition envoie la demande sur le rseau interbancaire, sans se proccuper de la suite du transit. Le rseau interbancaire nest donc pas un simple rseau physique : il doit aussi effectuer le routage des demandes dautorisation, cest--dire analyser les demandes qui lui sont fournies, envoyer chaque demande vers le serveur dautorisation de la banque correspondante et, enn, prendre en charge la transmission de la rponse lorsquelle lui revient.

2 Cahier des charges


Lobjectif de ce projet est de simuler les mcanismes dcrits ci-dessus, cest--dire : le terminal envoyant une demande dautorisation au serveur dacquisition de sa banque ;
1 et

bientt aussi des cartes bancaires.

le serveur dacquisition effectuant le routage de la transaction vers le bon serveur dautorisation et effectuant le routage des rponses quil reoit en retour des terminaux ; le rseau interbancaire auquel sont connects les diffrents serveurs dacquisition, capable deffectuer le routage des demandes et des rponses relayes par les serveurs dacquisition ; le serveur dautorisation fournissant la rponse la demande dautorisation ; le tout permettant un maximum de paralllisme. Remarque : cet exercice est avant tout acadmique, mais nest pas dnu dintrt ; en effet, des socits commercialisent toutes sortes de simulateurs pour tester le fonctionnement des nouveaux composants des systmes montiques, an de valider leur fonctionnement avant leur mise en production. Le cahier des charges fonctionnelles prcise larchitecture gnrale, les fonctionnalits devant tre programmes ainsi que les contraintes fonctionnelles respecter. Le cahier des charges techniques fournit les restrictions concernant la mise en uvre.

2.1 Cahier des charges fonctionnelles


2.1.1 Architecture fonctionnelle Le schma 2 prcise celui qui a t prsent plus haut et retranscrit la description que nous avons fournie ci-dessus.

Terminal (1)

Serveur dAcquisition (2)

Serveur dAutorisation

Banque du commerant

(3)

Rseau Interbancaire

Rseau Interbancaire

(3)

Serveur dAcquisition (2)

Serveur dAutorisation

Banque du client

Fig. 2 Architecture fonctionnelle du projet Le terminal est reli via le rseau tlphonique (1) au serveur dacquisition de la

banque du commerant. Celui-ci est connect au sein de la banque (2) au serveur dautorisation de cette mme banque. Le rseau interbancaire relie (3,3) les serveurs dacquisition des diffrentes banques. Toutes les autres banques de la place sont galement relies au rseau interbancaire, mais ne sont pas reprsentes sur ce schma. 2.1.2 Le terminal Dans le cadre de ce projet, il nest pas question dutiliser de vrais terminaux ou de vraies cartes. Le terminal tant un moyen denvoyer aux programmes des demandes dautorisation, il sera simul pour ce projet par un excutable qui enverra un numro de carte alatoirement tire dans la liste des cartes existantes et un montant de transaction alatoire. Pour fonctionner, un terminal a donc besoin de connaitre la liste des carte existantes. Chaque terminal devra envoyer les informations gnres au serveur dacquisistion, devra attendre la rponse du serveur dacquisition et afchera cette rponse lcran (i.e. paiement autoris ou non). Les changes entre le terminal et le serveur dacquisition ont lieu suivant un protocole bien dtermin : les informations sont formates dune certaine faon. Ce sont les constructeurs de terminaux qui imposent leurs protocoles et ce sont les serveurs dacquisition qui doivent sadapter pour parler les protocoles des diffrents terminaux qui lui sont connects. An de simplier le projet et de garantir linteroprabilit des diffrents projets entre eux (voir en annexe pour une explication de ce point), un seul protocole de communication sera utilis. Celui-ci est dcrit en annexe de ce document. 2.1.3 Le serveur dacquisition Le serveur dacquisition na quune fonction de routage : il doit pouvoir accepter des demandes dautorisation provenant de terminaux et du rseau interbancaire ; il doit pouvoir effectuer le routage des demandes dautorisation vers le serveur dautorisation de la banque ou bien vers le rseau interbancaire ; il doit pouvoir accepter les rponses provenant du rseau interbancaire ou du serveur dautorisation de la banque ; il doit pouvoir envoyer les rponses vers le rseau interbancaire ou le terminal (en tant capable dapparier chaque rponse la demande initiale). Le serveur dacquisition doit tre capable dutiliser le protocole de communication employ par les terminaux, ainsi que le protocole du rseau interbancaire et le protocole du serveur dautorisation (voir les protocoles dnis en annexe). An de pouvoir effectuer correctement le routage des messages, le serveur dacquisition doit connaitre les 4 premiers chiffres des numros des cartes de sa banque.

2.1.4 Le serveur dautorisation Le serveur dautorisation doit tre capable de fournir une rponse une demande dautorisation. Pour fonctionner, le serveur dautorisation doit donc avoir accs aux soldes des comptes des clients de la banque rfrencs par numro de carte. Dans le cadre de ce projet, nous utiliserons une mthode simple : le serveur dautorisation possde la liste des numros de cartes mises par la banque, auxquels sont associs les soldes des comptes adosss ces cartes ; lorsquune demande dautorisation lui parvient, le serveur vrie que le numro de carte gure bien dans sa liste. Il contrle alors que le solde de compte est sufsant pour effectuer la transaction, si cest le cas il repond oui, sinon il rpond non. 2.1.5 Le rseau interbancaire Le rseau interbancaire na quune fonction de routage : il doit pouvoir accepter les messages provenant des serveurs dacquisition ; il doit pouvoir analyser le contenu des messages pour dterminer vers quel serveur dacquisition il doit les envoyer. Pour fonctionner, le rseau interbancaire doit possder la liste des codes de 4 chiffres gurant en entte des cartes et les banques associes.

2.2 Cahier des charges techniques


2.2.1 Contraintes gnrales Lensemble de la simulation tournera sur une seule machine. Les programmes seront crits en langage C, et mettront en uvre les concepts et les techniques apprises pendant le cours IN301/IN3ST01. Un maximum de parralllisme est exig dans ce projet. 2.2.2 Nombre de processus Chaque composant fonctionnel tel quil a t prsent dans le cahier des charges fonctionnelles correspondra un processus. On trouvera donc un processus pour le terminal (que lon nommera Terminal), un processus pour le serveur dacquisition (Acquisition), un processus pour le serveur dautorisation (Autorisation) et un processus pour le rseau interbancaire (Interbancaire). La simulation pouvant mettre en jeu plusieurs terminauxx, plusieurs banques, etc., on trouvera en fait un processus Terminal par terminal, un processus Acquisition par serveur dacquisition et un processus Autorisation par serveur dautorisation. Pour favoriser le paralllisme, chaque processus pourra (si besoin est) tre dcoup en plusieurs threads. 2.2.3 Paramtres Les paramtres ncessaires au fonctionnement des diffrents processus seront fournis via la ligne de commande, lexception des paramtres suivants qui seront fournis

sous forme de chier : la liste des banques et de leur code 4 chiffres ; la liste des cartes bancaires de chaque banque et le solde du compte associ. Ces chiers seront au format texte, chaque ligne contenant les deux informations demandes (code sur 4 chiffres et banque associ ou numro de carte et solde du compte associ), spares par un espace. 2.2.4 Gestion des changes par tuyaux Les terminaux connects au mme serveur dacquistion (donc les terminaux dune mme banque) utiliseront chacun une paire de tuyaux pour dialoguer avec ce serveur. Le serveur dacquisition aura donc comme rle dorchestrer simultanment les lectures et les critures sur ces tuyaux. Les changes enter un serveur dacquisition et un serveur dautorisation seront possibles au travers dune paire de tuyaux fonctionnant dune faon trs classique. Pour ce qui concerne le rseau interbancaire et les serveurs dacquisition, la problmatique est strictement identique celle des terminaux : il faudra utiliser une paire de tuyaux pour connecter chaque serveur dacquisition au rseau interbancaire. Ceci confre au processus Interbancaire un rle de chef dorchestre et implique de maintenir une table de routage.

2.3 Comment tester sans sy perdre ?


Le schma propos ci-dessus comporte un petit dfaut tant que les communications entre processus se feront sur la mme machine (donc sans utiliser de socket, dveloppement propos en option) : chaque Terminal va fonctionner partir de la mme fentre xterm (le mme terminal, le mme shell). Tous les afchages vont donc se faire sur cette mme fentre. An de faire bncier chaque processus Terminal dune entre et dune sortie standard qui lui soient propres, une astuce peut tre utilise : lors de la cration dun nouveau Terminal par le processus Acquisition, recouvrir le nouveau ls du processus non pas par Terminal, mais par xterm -e Terminal. Cette astuce nest pas trs esthtique, et nest quun intermdiaire avant la communication par socket.

2.4 Livrables
Doivent tre livrs sous format lectronique : 1. Un ensemble de chier C, amplement comments, correspondant aux diffrents programmes constituant la simulation. 2. Un chier Makele permettant de compiler tous les programmes (y compris les programmes de test). 3. un mode demploi expliquant comment obtenir une application oprationnelle, comment lexcuter, et comment la tester.

10

4. Un manuel technique dtaillant larchitecture, le rle de chaque composant, expliquant comment tester le bon fonctionnement de faon indpendante et justiant les choix techniques effectus. Ce manuel devra en particulier bien prciser comment le projet rpond au cahier des charges (ce quil sait faire, ce quil ne sait pas faire, et mettre en exergue ses qualits et ses dfauts). 5. Dans le manuel technique, on dmontrera quil ne peut pas y avoir dinterblocage entre les diffrents processus, pas plus quentre les threads dun mme processus. Tous les documents produire sadressent des ingnieurs gnralistes et les rdacteurs doivent donc veiller donner des explications concises et claires. Aucun chier excutable, chier objet, chier de sauvegarde, chier superu ou inutile ne devra tre transmis avec les livrables. Une version papier des rapports sera galement remise au secrtariat.

3 Conduite du projet
Les tapes qui vous sont suggrs dans cette partie permettent une approche sereine de la programmation de ce projet.

3.1 Introduction
3.1.1 Un projet en plusieurs tapes Le dveloppement de ce simulateur qui est prsent ici est en plusieurs tapes. Ce dcoupage conduit le dveloppeur crire des programmes indpendants les uns des autres, qui communiqueront entre eux par lintermdiaire de tuyaux, souvent aprs redirection des entres/sorties standards. 3.1.2 Mthode diviser pour rgner La constitution de lapplication globale par criture de petits programmes indpendants qui communiqueront ensuite entre eux est un gage de russite : chaque petit programme gnrique peut tre crit, test et valid indpendamment, et la ralisation du projet devient alors simple et progressive. La meilleure stratgie adopter consiste crire une version minimale de chaque brique du projet, faire communiquer ces briques entre elles, puis ventuellement, enrichir au fur et mesure chacune des briques. La stratgie consistant dvelopper outrance une des briques pour ensuite sattaquer tardivement au reste du projet conduit gnralement au pire des rapport rsultat/travail. Avant toute programmation, conception ou ralisation de ce projet, il est fortement conseill de lire lintgralit de lnonc, y compris les parties que vous pensez ne pas raliser, et de sastreindre comprendre la structuration en tapes propose ici. La traduction de cet nonc sous forme de schma est indispensable. En particulier, il est particulirement important de dnir ds le dpart lensemble des ux de donnes qui vont transiter dun processus un autre, de dterminer comment 11

il est possible de sassurer que ces ux sont bien envoys et reus, puis de programmer les fonctions dmission et de rception correspondantes. Ces fonctions seront ensuite utilises dans tous les processus du projet. Un schma clair et complet associ des communications correctement gres garantissent la russite de ce projet et simplient grandement son dveloppement.

3.2 Etape 1 : les fonctions de communication


La premre tape consiste programmer les diffrentes fonctions de communication permettant de lire et crire les demandes dautorisation et des rponses selon les protocoles dnis en annexe. Les problmes de synchronisation seront abords dans les tapes suivantes et il sagit pour linstant uniquement de traduire sous forme de programmes (de fonctions en C) les protocoles de communication : formattage de messages selon la structure dnie en annexe, rcupration des informations stockes sous cette forme, etc. Une fois ces fonctions crites, elles seront utilises par tous les processus constituant le projet.

3.3 Etape 2 : ralisation de programmes indpendants


Dans cette seconde tape, il sagit de mettre en place les diffrentes briques du projet et de pouvoir les tester indpendamment. 3.3.1 Processus : Autorisation Le processus Autorisation recevra sur son entre standard des demandes dautorisation auxquels il devra rpondre sur sa sortie standard. Lexcutable Autorisation prendra sur sa ligne de commande le nom de chier de paramtres, cest--dire celui comprenant la liste des soldes des comptes des clients de la banque, rfrencs par leur numros de cartes. Le processus Autorisation pourra donc tre test indpendamment des autres processus. 3.3.2 Processus : Acquisition Le processus Acquisition recevra des messages de demande dautorisation en provenance soit des terminaux, soit du rseau interbancaire, ou bien en provenance du serveur dautorisation ou du rseau interbancaire. Ces messages seront redirigs (routs) vers le rseau interbancaire, vers le serveur dacquisition ou bien vers les terminaux, conformment au cahier des charges. A cette phase du projet, on pourra utiliser : lentre ou la sortie standard pour simuler le dialogue avec le serveur dautorisation ( la main) ; des chiers dans lesquels le processus Acquisition ira crire lorsquil est suppos envoyer un message ; des chiers dans lesquels le processus Acquisition ira lire les messages lorsquil sattend recevoir ; ces derniers seront prpars la main.

12

Ces chiers permettront de simuler les changes avec les processus Terminal et Interbancaire. Le programme devra accepter sur sa ligne de commande au moins un paramtre reprsentant les 4 premiers chiffres des cartes de la banque laquelle il appartient. Dans une premire phase, le processus Acquisition traitera squentiellement chaque terminal ainsi que les messages en provenance ou destination du serveur dautorisation et du rseau interbancaire. Dans une deuxime phase, on parrallisera au maximum les requtes. La premire phase doit tre pense et conue sur le papier an de pouvoir facilement passer la deuxime phase. La premire phase peut sufre pour passer la suite du projet, mais elle est obligatoire et devra tre rendue. On conservera toutes les versions des diffrentes phases du programme des ns de test. 3.3.3 Processus : Terminal Le processus Terminal offrira linterface permettant denvoyer et de recevoir les informations pour une transaction (montant et numro de carte). An de pouvoir tester le fonctionnement du Terminal, les messages de demande dinformation destination du serveur dacquisition pourront tre crits dans un chier. Les rponses seront galement lues dans un chier qui aura t prpar lavance.

3.4 Etape 3 : cration du rseau bancaire


3.4.1 Prparation de la communication par tuyaux En pratique, le processus Acquisition et chaque processus Terminal vont communiquer par une paire unique de tuyaux. Une fois ces deux tuyaux crs, il est possible de modier simplement les programmes Terminal et Acquisition pour quils utilisent non pas des chiers mais ces deux tuyaux. Pour cela, on comltera le programme Terminal en permettant de lui passer sur la ligne de commande les descripteurs des tuyaux utiliser en lecture et en criture. On modiera le code pour que ces tuyaux soient utiliss en lieu et place des chiers employs la deuxime tape. 3.4.2 Raccordement Pour terminer la mise en place des communications au sein dune mme banque, il faut maintenant crer dune part une paire de tuyaux entre Acquisition et chaque Terminal (il y aura autant de paires de tuyaux que de terminaux, et dautre part, une paire de tuyaux entre Acquisition et Autorisation, aprs avoir redirig leurs entres et sorties standards (voir annexe). Ecrire un programme Banque acceptant sur sa ligne de commande le nombre de terminaux de la banque. Le programme devra galement accepter sur sa ligne de commande les paramtres suivants : le nom de la banque simuler ; les 4 chiffres associs cette banque ; le nom dun chier contenant les soldes des comptes clients ; le nombre de terminaux crer. 13

Crer les tuyaux ncessaires, oprer les clonages et recouvrements ncessaires pour crer les processus Terminal et Autorisation en nombre sufsant. Enn, recouvrir Banque par le programme Acquisition sans oublier les redirections ncessaires des tuyaux avec les entres et sorties standards.

3.5 Etape 4 : cration du rseau interbancaire


3.5.1 Processus : Interbancaire Chaque serveur dacquisition sera reli au processus Interbancaire par une paire de tuyaux. Celle-ci permettra Interbancaire de recevoir les messages de demande dautorisation et de transmettre les rponses en retour, aprs les avoir routs. Larchitecture mettre en place entre Interbancaire et les diffrents processus Acquisition sera similaire celle mise en place entre chaque processus Acquisition et les processus Terminal qui y sont relis. Dans un premier temps, les messages transitant par Interbancaire seront simplement lus sur lentre et la sortie standard (ou lus et crits dans des chiers, sans quaucune communication ne soit mise en place). Dans une premire phase, le processus Interbancaire traitera squentiellement chaque serveur dacquisition. Dans une deuxime phase, on parrallisera au maximum les requtes. La premire phase doit tre pense et conue sur le papier an de pouvoir facilement passer la deuxime phase. La premire phase peut sufre pour passer la suite du projet, mais elle est obligatoire et devra tre rendue. On conservera toutes les versions des diffrentes phases du programme des ns de test. 3.5.2 Raccordement On crera un programme Dmarrage qui devra accepter sur sa ligne de commande un chier de conguration dans lequel on trouvera les informations suivantes : le nom dun chier contenant toutes les banques et les 4 chiffres associs chaque banque ; les noms des chiers ncessaires au fonctionnement de chaque banque ; le nombre de terminaux pour chaque banque. Le processus Dmarrage devra crer les tuyaux, effectuer les clnages et les recouvrements ncessaires an de crer lensemble des processus ncessaires la simulation.

4 volutions complmentaires et optionnelles


4.1 Cumul des transactions
On demande de rendre la simulation plus raliste en permettant au niveau du serveur dautorisation de comptabiliser lensemble des paiements effectus par une carte, an de proposer une rponse la demande dautorisation qui tiennent compte du solde du compte et de lencours de la carte.

14

4.2 Dlai dannulation


Dans cette version, les processus Acquisition et Interbancaire doivent pouvoir grer une fonction dannulation : une transaction est annule lorsquil sest coul plus de 2 secondes depuis le relai de la demande, sans quune rponse ne soit parvenue. Si une rponse parvient ultrieurement, elle sera ignore. Ceci suppose que les processus Acquisition et Interbancaire conservent une trace date de toutes les demandes quils traitent et quils vrient rgulirement la date de premption de chaque demande. Attention : lannulation dune demande pour dlai trop important ne dispense pas les processus Acquisition et Interbancaire denvoyer une rponse lmetteur de la demande. La synchronisation (demande, autorisation dcriture, ordre de lecture) sera mise en uvre par lintermdiaire de lappel systme select().

4.3 Utilisation de

Lutilisation de communications entre machines ne fait pas partie des objectifs de ce cours. Cependant, an de rendre le projet plus vivant et plus attractif, nous proposons aux plus dbrouillards dutiliser des socket de sorte que la simulation soit plus raliste : chaque terminal communique avec son serveur dacquisition par des socket ; chaque serveur dacquisition communique avec le rseau interbancaire par socket. Les informations ncessaires lutilisation des socket peuvent facilement se trouver sur internet. Le travail de mise en uvre des communications par socket doit tre entrepris uniquement aprs avoir russi programmer une application compltement oprationnelle en mode texte. Attention : ne jamais modier un programme qui fonctionne et toujours travailler sur une copie de celui-ci.

5 Annexes
5.1 De lintrt des standards pour assurer une meilleure interoprabilit
Le recours des protocoles standardiss (ou pour le moins communs) un double intrt : il permet de gagner du temps sur le dveloppement de ce projet et dillustrer par la pratique la faon dont les problmes sont traditionnellement rsolus en informatique : il permettra de mlanger les projets entre eux an de tester le respect du protocole et peut-tre, daider certains binmes avancer (il sufra dutiliser les processus dun autre binme2).
2 Bien

entendu, cette utilisation ne peut sentendre qu des ns de mise au point. . .

15

La capacit ainsi esquisse mlanger des composants issus de programmeurs ou prestataires diffrents pour constituer un systme dinformation unique se nomme interoprabilit. Cest un des enjeux majeurs de linformatique actuelle.

5.2 Spcications de protocoles de communication


Les messages sont constitus de caractres ASCII (sans accent). Chaque message est constitu de diffrents champs spars par les caractres | et termins par un caractre de n de message \n. Le premier caractre indique toujours la nature du message. Le rcapitulatif des changes est prsent sur la gure 3.
(1) Terminal (2) (5) (7) (6) (8) Serveur dAcquisition (4) (3) Serveur dAutorisation

Rseau Interbancaire

Fig. 3 Rcapitulatif des changes Remarque : an de simplier au maximum le protocole, on considre quil nest pas possible que plus dune demande dautorisation ou rponse, correspondant une transaction faite avec une carte donne, circule sur le rseau. Cette hypothse, assez raliste, permettra de simplier lappariement des demandes et des rponses au niveau des processus Acquisition et Interbancaire. 5.2.1 Un format de message unique Quelque soit le message, son format est toujours le mme : |I...I|C...C|A...A|B...B|\n avec : I...I est lidentiant de lenvoyeur du message (longueur strictement suprieur 0 et indtermin a priori ; C...C est le nom de la commande dcrite dans le message (longueur strictement suprieur 9 et indtermin a priori ; A...A est le premier argument (optionnel) de la commande (longueur indtermine a priori) ; B...B est le deuxime argument (optionnel) de la commande (longueur indtermine a priori) ; Ce format devrait permettre de traiter lensemble des cas possibles. An de simplier la mise en uvre, on supposera quun message comporte au plus 255 caractres. 16

La suite des spcications du protocole consiste dnir lutilisation de ce format spciquement au contexte des communications numrs dans le schma rcapitulatif 3. 5.2.2 Protocole du terminal Les changes avec le terminal utilisent deux types de message, la demande dautorisation et la rponse la demande dautorisation. (1) Message de demande dautorisation Ce message est envoy par le terminal et rceptionn par le serveur dacquisition. Format : |I...I|DemandeAutorisation|A...A|B...B|\n Chaque lettre reprsente un caractre du message. I...I est lidentiant du terminal (par exemple son pid ; A...A correspond au montant de la transaction exprim en centimes deuros ; B...B correspond au numro de la carte sur 16 chiffres dcimaux (longueur constante). (2) Message de rponse la demande dautorisation Ce message est envoy par le serveur dacquisition et rceptionn par le terminal. Format : |I...I|ReponseAutorisation|A...A||\n avec : I...I est lidentiant du serveur dacquisition (par exemple son pid ; A...A est la chane de caractre : oui si la demande est accepte ; non si la demande est refuse ; timeout si le dlai imparti pour la rceptionner la rponse est coul ; probleme si un problme inattendu est survenu. 5.2.3 Protocole du rseau interbancaire (5)(7) Message de demande dautorisation Ce message peut tre mis par le rseau interbancaire et rceptionn par un serveur dacquisition ou bien mis par un serveur dacquisition et rceptionn par le rseau interbancaire. Format : |I...I|DemandeAutorisation|A...A|B...B|\n avec : I...I est lidentiant de lenvoyeur du message (peut tre son PID) ; A...A correspond au montant de la transaction exprim en centimes deuros ; B...B correspond au numro de la carte sur 16 chiffres dcimaux (longueur constante). (6)(8) Message de rponse Ce message est fourni par un serveur dacquisition au rseau interbancaire ou par le rseau interbancaire au serveur dacquisition. Format : |I...I|ReponseAutorisation|A...A|B...B|\n avec I...I est lidentiant de lenvoyeur du message (peut tre son PID) ; A...A est la chane de caractre : oui si la demande est accepte ; non si la demande est refuse ; 17

timeout si le dlai imparti pour rceptionner la rponse est coul ; probleme si un problme inattendu est survenu. B...B est le numro de carte (16 chiffres) sur laquelle la transaction a t passe. 5.2.4 Le serveur dautorisation Message de demande dautorisation Ce message est envoy par le serveur dacquisition au serveur dautorisation. Format : |I...I|DemandeAutorisation|A...A|B...B|\n avec : I...I est lidentiant du serveur dacquisition (peut tre sont PID) ; A...A correspond au montant de la transaction exprim en centimes deuros ; B...B correspond au numro de la carte sur 16 chiffres dcimaux (longueur constante). Message de rponse Ce message est envoy par le serveur dautorisation au serveur dacquisition. Format : |I...I|ReponseAutorisation|A...A|B...B|\n avec : I...I est lidentiant du serveur dautorisation (peut tre son PID) ; A...A est la chane de caractre : oui si la demande est accepte ; non si la demande est refuse ; timeout si le dlai imparti pour rceptionner la rponse est coul ; probleme si un problme inattendu est survenu. B...B est le numro de carte (16 chiffres) sur laquelle la transaction a t passe.

5.3 Gnrateur alatoire


Pour un exemple de gnrateur alatoire, vous pouvez tlcharger le lien suivant http ://www.esiee.fr/%7Einfo/a2si/TC-ESIEE/IN301ST01/chaine.tz Pour le dcompresser, tapez la commande tar zxvf chaine.tz.

5.4 Redirection des entres et des sorties


La redirection des entres et des sorties peut se faire grce lappel systme dup. i n t dup2 ( i n t o l d f i l e d e s , i n t n e w f i l e d e s ) ; Cet appel systme sert dupliquer le contenu du descripteur oldfiledes dans un autre descripteur newfiledes. Il renvoie -1 en cas dchec, et il prend en argument deux descripteurs de chiers. Par exemple si on a envie que STDIN (==1) soit en fait STDERR (==2) on peut crire ceci : dup2 ( 2 , 1 ) ; Lexemple suivant redirige lentre et la sortie standard vers un tube, et recouvre le processus courant et son ls par deux programmes. Le pre et le ls vont communiquer par leur entre et sortie standard.

18

# i n c l u d e < s t d i o . h> # i n c l u d e < s t d l i b . h> # i n c l u d e < u n i s t d . h>

v o i d u s a g e ( char basename ) { f pr i n t f ( stderr , " u s a g e : %s [ < programme 1> [ < programme 2 > ] ] \ n " , basename ) ; exit (1); } i n t main ( i n t a r g c , char a r g v [ ] ) { int pid ; / p e r m e t d i d e n t i f i e r q u i on e s t / i n t f d p i p e [ 2 ] ; / s er a u t i l i s pour l i e r l e s p r o c e s s u s / i f ( argc != 2) usage ( argv [ 0 ] ) ; / on c r l e p i p e q u i s e r a u t i l i s p o u r r e l i e r l a s o r t i e du p r e m i e r p r o c e s s u s v e r s l e n t r e du s e c o n d / i f ( p i p e ( f d p i p e ) == 1 ) { perror ( " pipe " ) ; e x i t ( 1); } switch ( pid = fork ( ) ) { c a s e 1: / l e f o r k a chou / perror ( " fork " ) ; e x i t ( 1); case 0: / c o d e du f i l s / / on f a i t en s o r t e que l o r s q u e l e p r o c e s s u s crira sur l entre standard (1) i l l e f e r a en f a i t d a n s l e p i p e ( f d p i p e [ 1 ] ) / dup2 ( f d p i p e [ 1 ] , 1 ) ; / on f e r m e t o u t , mme l e p i p e . . . on n en a p l u s b e s o i n / close ( fdpipe [ 0 ] ) ; close ( fdpipe [ 1 ] ) ; e x e c l p ( a r g v [ 1 ] , a r g v [ 1 ] , NULL ) ; / p a s b e s o i n de b r e a k , ce code n e x i s t e dj p l u s l e x c u t i o n / default : / c o d e du p r e /

19

/ on f a i t en s o r t e que l o r s q u e l e p r o c e s s u s l i r a sur la s o r t i e standard (0) i l l e f e r a en f a i t d a n s l e p i p e ( f d p i p e [ 0 ] ) / dup2 ( f d p i p e [ 0 ] , 0 ) ; close ( fdpipe [ 0 ] ) ; close ( fdpipe [ 1 ] ) ; e x e c l p ( a r g v [ 2 ] , a r g v [ 2 ] , NULL ) ; } / c e t t e p o r t i o n de c o d e ne s e r a j a m a i s e x e c u t e , puisque le s processus ont dj t r e m p l a c . On met n a n m o i n s un return sinon le compilateur p r o t e s t e . / return 0; }

20