L'objectif du projet proposé est de simuler les échanges entre banques permettant à un particulier de payer ses achats avec sa carte bancaire (sa "carte bleue"), même si celle-ci n'est pas émise par la même banque que celle du vendeur.
(D'après un projet de Jérome Gueydan pour l'ENSTA)
Le principe du paiement par carte bancaire
Le paiement par carte bancaire met en relation plusieurs acteurs :
le client, qui souhaite régler un achat avec la carte bancaire qu'il possède et qui lui a été fournie par sa banque (Banque A) ;
le commerçant, qui est équipé d'un terminal de paiement fourni par sa propre banque (Banque B) ;
la banque du commerçant (Banque B) à laquelle est connectée le terminal de paiement ;
la banque du client (Banque A) qui va dire si la transaction est autorisée (donc si le compte de son client est suffisamment provisionné ou non).
Le terminal du commerçant est relié à la banque B grâce à une simple ligne téléphonique. La banque B est connectée à toutes les autres banques installées en France, et notamment à la banque A, grâce à un réseau dédié : le réseau interbancaire
Supposons maintenant que le client lambda se rend chez son revendeur de logiciels préféré ; au moment de passer en caisse, il dégaine sa carte bancaire, le caissier l'insère dans son terminal de paiement et le client doit, après avoir regardé au passage la somme qu'il s'apprête à débourser, saisir son code confidentiel.
Ce code est directement vérifié par la carte (plus exactement par la puce contenue dans la carte). Si le code est erroné, la transaction s'arrête là. Si le code est bon, en revanche, les opérations suivantes ont lieu :
Le terminal se connecte (via le réseau téléphonique) au serveur de la banque B et envoie le numéro de la carte bancaire ainsi que le montant de la transaction.
Le serveur de la banque B regarde le numéro de la carte et, se rendant compte qu'il ne s'agit pas d'une des cartes qu'il a émises, envoie le numéro de carte avec le montant de la transaction au serveur de la banque A, via le réseau interbancaire permettant de relier les différentes banques.
Le serveur de la banque A prend connaissance du numéro de la carte bancaire et vérifie que le compte correspondant à ce numéro dispose d'un solde suffisant pour honorer la transaction.
Si c'est le cas, il répond à la banque B (toujours via le réseau interbancaire) que le paiement est autorisé. Si ce n'est pas le cas, il répond le contraire.
Enfin, le serveur de la banque B transmet la réponse au terminal du commerçant.
La transaction est validée ou refusée.
La demande d'autorisation
La suite des opérations décrites ci-dessus se nomme la demande d'autorisation et a essentiellement pour but de vérifier que le compte client est bien provisionné (ou qu'il a une autorisation de découvert). Cette demande d'autorisation n'est pas systématique et dépend du terminal, lequel prend par exemple en compte le montant de la transaction.
La demande d'autorisation transite via deux serveurs différents :
Le serveur d'acquisition - Il s'agit du serveur de la banque du commerçant auquel se connecte le terminal via le réseau téléphonique. Une fois connecté, le terminal envoie au serveur d'acquisition toutes les informations concernant la transaction, notamment le montant, le numéro de carte et des données permettant d'assurer la sécurité de la transaction.
Le serveur d'autorisation - Il s'agit du serveur de la banque du client auquel le serveur d'acquisition transmet l'autorisation de paiement émise par le terminal. La réponse à la demande suit le chemin inverse, à savoir serveur d'autorisation de la banque du client puis le serveur d'acquisition de la banque du commerçant et le terminal du commerçant
Le routage
Pour effectuer le routage des demandes d'autorisation, c'est-à-dire pour déterminer à quelle banque chaque demande d'autorisation doît être transmise, le serveur d'acquisition utilise les premiers numéros de chaque carte bancaire concernée : ceux-ci indiquent la banque ayant émis cette carte.
Dans ce projet, nous partirons des principes suivants :
un numéro de carte est constitué de seize chiffres décimaux ;
les quatres premiers correspondent à un code spécifique à chaque banque ;
les serveurs d'acquisition des banques sont directement reliés au réseau interbancaire. Chaque serveur d'acquistion analyse donc le numéro de la carte qui figure dans la demande d'autorisation qu'il reçoit, puis :
si le client est dans la même banque que le commerçant (et que le serveur d'acquisition), il envoie la demande directement au serveur d'acquisition de cette banque ;
si le client est dans une autre banque, le serveur d'acquisition envoie la demande sur le réseau interbancaire, sans se préoccuper de la suite du transit.
Le réseau interbancaire n'est donc pas un simple réseau physique : il doit aussi effectuer le routage des demandes d'autorisation, c'est-à-dire analyser les demandes qui lui sont fournies, envoyer chaque demande vers le serveur d'autorisation de la banque correspondante et, enfin, prendre en charge la transmission de la réponse lorsqu'elle lui revient.
topCahier des charges
L'objectif de ce projet est de simuler les mécanismes décrits ci-dessus, c'est-à-dire :
le terminal envoyant une demande d'autorisation au serveur d'acquisition de sa banque ;
le serveur d'acquisition effectuant le routage de la transaction vers le bon serveur
d'autorisation et effectuant le routage des réponses qu'il reçoit en retour des
terminaux ;
le réseau interbancaire auquel sont connectés les différents serveurs d'acquisition, capable d'effectuer le routage des demandes et des réponses relayées par les serveurs d'acquisition ;
le serveur d'autorisation fournissant la réponse à la demande d'autorisation ;
le tout permettant un maximum de parallélisme.
Le cahier des charges fonctionnelles précise l'architecture générale, les fonctionnalités devant être programmées ainsi que les contraintes fonctionnelles à respecter. Le cahier des charges techniques fournit les restrictions concernant la mise en oeuvre.
Cahier des charges fonctionnelles
Le terminal est relié via le réseau téléphonique (1) au serveur d'acquisition de la banque du commerçant. Celui-ci est connecté au sein de la banque (2) au serveur d'autorisation de cette même banque.
Le réseau interbancaire relie (3,3') les serveurs d'acquisition des différentes banques. Toutes les autres banques de la place sont également reliées au réseau interbancaire, mais ne sont pas représentées sur ce schéma.
Le terminal
Dans le cadre de ce projet, il n'est pas question d'utiliser de vrais terminaux ou de vraies cartes. Le terminal étant un moyen d'envoyer aux programmes des demandes d'autorisation, il sera simulé pour ce projet par un exécutable qui enverra un numéro de carte aléatoirement tirée dans la liste des cartes existantes et un montant de transaction aléatoire.
Pour fonctionner, un terminal a donc besoin de connaitre la liste des carte existantes. Chaque terminal devra envoyer les informations générées au serveur d'acquisistion, devra attendre la réponse du serveur d'acquisition et affichera cette réponse à l'écran (i.e. paiement autorisé ou non).
Les échanges entre le terminal et le serveur d'acquisition ont lieu suivant un protocole bien déterminé : les informations sont formatées d'une certaine façon. Ce sont les constructeurs de terminaux qui imposent leurs protocoles et ce sont les serveurs d'acquisition qui doivent s'adapter pour “parler” les protocoles des différents terminaux qui lui sont connectés.
Afin de simplifier le projet et de garantir l'interopérabilité des différents projets entre eux (voir en annexe pour une explication de ce point), un seul protocole de communication sera utilisé. Celui-ci est décrit en annexe de ce document.
Le serveur d'acquisition
Le serveur d'acquisition n'a qu'une fonction de routage :
il doit pouvoir accepter des demandes d'autorisation provenant de terminaux et du réseau interbancaire ;
il doit pouvoir effectuer le routage des demandes d'autorisation vers le serveur d'autorisation de la banque ou bien vers le réseau interbancaire ;
il doit pouvoir accepter les réponses provenant du réseau interbancaire ou du serveur d'autorisation de la banque ;
il doit pouvoir envoyer les réponses vers le réseau interbancaire ou le terminal (en étant capable d'apparier chaque réponse à la demande initiale).
Le serveur d'acquisition doit être capable d'utiliser le protocole de communication employé par les terminaux, ainsi que le protocole du réseau interbancaire et le protocole du serveur d'autorisation (voir les protocoles définis en annexe).
Afin de pouvoir effectuer correctement le routage des messages, le serveur d'acquisition doit connaitre les 4 premiers chiffres des numéros des cartes de sa banque.
Le serveur d'autorisation
Le serveur d'autorisation doit être capable de fournir une réponse à une demande d'autorisation. Pour fonctionner, le serveur d'autorisation doit donc avoir accès aux soldes des comptes des clients de la banque référencés par numéro de carte.
Dans le cadre de ce projet, nous utiliserons une méthode simple : le serveur d'autorisation possède la liste des numéros de cartes émises par la banque, auxquels sont associés les soldes des comptes adossés à ces cartes ; lorsqu'une demande d'autorisation lui parvient, le serveur vérifie que le numéro de carte figure bien dans sa liste. Il contrôle alors que le solde de compte est suffisant pour effectuer la transaction, si c'est le cas il repond oui, sinon il répond non.
Le réseau interbancaire
Le réseau interbancaire n'a qu'une fonction de routage :
il doit pouvoir accepter les messages provenant des serveurs d'acquisition ;
il doit pouvoir analyser le contenu des messages pour déterminer vers quel serveur d'acquisition il doit les envoyer.
Pour fonctionner, le réseau interbancaire doit posséder la liste des codes de 4 chiffres figurant en entête des cartes et les banques associées.
Cahier des charges techniques
Contraintes générales
chaque terminal communique avec son serveur d'acquisition par des socket ;
chaque serveur d'acquisition communique avec le réseau interbancaire par socket. ;
Les programmes seront écrits en langage C, et mettront en oeuvre les concepts et les techniques apprises pendant le cours.
Un maximum de parrallélisme est exigé dans ce projet.
Nombre de processus
Chaque composant “fonctionnel” tel qu'il a été présenté dans le cahier des charges fonctionnelles correspondra à un processus. On trouvera donc un processus pour le terminal (que l'on nommera Terminal), un processus pour le serveur d'acquisition (Acquisition), un processus pour le serveur d'autorisation (Autorisation) et un processus pour le réseau 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 d'acquisition et un processus Autorisation par serveur d'autorisation.
Pour favoriser le parallélisme, chaque processus pourra (si besoin est) être découpé en plusieurs threads.
Paramètres
Les paramètres nécessaires au fonctionnement des différents processus seront fournis via “la ligne de commande”, à l'exception des paramètres suivants qui seront fournis sous forme de fichier :
la liste des banques et de leur code à 4 chiffres ;
la liste des cartes bancaires de chaque banque et le solde du compte associé.
Gestion des échanges par tubex
Les terminaux connectés au même serveur d'acquistion (donc les terminaux d'une même banque) utiliseront chacun une paire de tubex pour dialoguer avec ce serveur. Le serveur d'acquisition aura donc comme rôle d'orchestrer simultanément les lectures et les écritures sur ces tubex.
Les échanges enter un serveur d'acquisition et un serveur d'autorisation seront possibles au travers d'une paire de tubex fonctionnant d'une façon très classique.
Pour ce qui concerne le réseau interbancaire et les serveurs d'acquisition, la problématique est strictement identique à celle des terminaux : il faudra utiliser une paire de tubex pour connecter chaque serveur d'acquisition au réseau interbancaire. Ceci confère au processus Interbancaire un rôle de chef d'orchestre et implique de maintenir une table de routage.
topLivrables
Doivent être livrés sous format électronique :Un ensemble de fichier C, amplement commentés, correspondant aux différents programmes constituant la simulation.
Un fichier Makefile permettant de compiler tous les programmes (y compris les programmes de test).
un mode d'emploi expliquant comment obtenir une application opérationnelle, comment l'exécuter, et comment la tester.
Un manuel technique détaillant l'architecture, le rôle de chaque composant, expliquant comment tester le bon fonctionnement de façon indépendante et justifiant les choix techniques effectués. Ce manuel devra en particulier bien préciser comment le projet répond au cahier des charges (ce qu'il sait faire, ce qu'il ne sait pas faire, et mettre en exergue ses qualités et ses défauts).
Dans lemanuel technique, on démontrera qu'il ne peut pas y avoir d'interblocage entre les différents processus, pas plus qu'entre les threads d'unmême processus
Tous les documents à produire s'adressent à des ingénieurs généralistes et les rédacteurs doivent donc veiller à donner des explications concises et claires.
Aucun fichier exécutable, fichier objet, fichier de sauvegarde, fichier superflu ou inutile ne devra être transmis avec les livrables.
topFonctionnalités supplémentaires optionnelles
Multi-demandes
Les processus Acquisition et Interbancaire doivent pouvoir gérer plusieurs demandes en parallèle. Il faudra donc utiliser toutes les possibilités d'identification des messages proposés par les protocoles.
Cumul des transactions
On demande de rendre la simulation plus réaliste en permettant au niveau du serveur d'autorisation de comptabiliser l'ensemble des paiements effectués par une carte afin de proposer une réponse à la demande d'autorisation qui tienne compte du solde du compte, mais également de l'encours carte.
Délai d'annulation (time out)
Les processus Acquisition et Interbancaire doivent pouvoir gérer une fonction d'annulation : une transaction est annulée lorsqu'il s'est écoulé plus de 2 secondes depuis le relais de la demande, sans qu'une réponse ne soit parvenue. Si une réponse parvient ultérieurement, elle sera ignorée.
Protocoles de communication
De l'intérêt des standards pour assurer une meilleure interopérabilité
Le recours à des protocoles “standardisés” (ou pour lemoins communs) à un double intérêt :
il permet de gagner du temps sur le développement de ce projet et d'illustrer par la pratique la façon dont les problèmes sont traditionnellement résolus en informatique :
il permettra demélanger les projets entre eux afin de tester le respect du protocole et peut-être, d'aider certains binômes à avancer (il suffira d'utiliser les processus d'un autre binôme).
La capacité ainsi esquissée à mélanger des composants issus de programmeurs ou prestataires différents pour constituer un système d'information unique se nomme “interopérabilité”. C'est un des enjeux majeurs de l'informatique actuelle.
Spécifications de protocoles de communication
Les messages sont constitués de caractères ASCII (sans accent). Chaque message est constitué de différents champs séparés par les caractères '|' et terminés par un caractère de fin demessage '\n'. Le premier caractère indique toujours la nature du message.
Un format de message unique
Quelque soit le message, son format est toujours lemême : |I...I|C...C|A...A|B...B|\n avec :
I...I est l'identifiant de l'envoyeur du message (longueur strictement supérieur à 0 et indéterminé a priori ;
C...C est le nom de la commande décrite dans le message (longueur strictement supérieur à 9 et indéterminé a priori ;
A...A est le premier argument (optionnel) de la commande (longueur indéterminée a priori) ;
B...B est le deuxième argument (optionnel) de la commande (longueur indéterminée a priori) ;
Ce format devrait permettre de traiter l'ensemble des cas possibles. Afin de simplifier la mise en oeuvre, on supposera qu'un message comporte au plus 255 caractères.
Protocole du terminal
Les échanges avec le terminal utilisent deux types de message, la demande d'autorisation et la réponse à la demande d'autorisation.
Message de demande d'autorisation
Ce message est envoyé par le terminal et réceptionné par le serveur d'acquisition.
Format : |I...I|DemandeAutorisation|A...A|B...B|\n
Chaque lettre représente un caractère du message.
I...I est l'identifiant du terminal (par exemple son pid) ;
A...A correspond au montant de la transaction exprimé en centimes d'euros ;
B...B correspond au numéro de la carte sur 16 chiffres décimaux (longueur constante).
Message de réponse à la demande d'autorisation
Ce message est envoyé par le serveur d'acquisition et réceptionné par le terminal.
Format : |I...I|ReponseAutorisation|A...A||\n avec :
I...I est l'identifiant du serveur d'acquisition (par exemple son pid ;
A...A est la chaîne de caractère :
oui si la demande est acceptée ;
non si la demande est refusée ;
timeout si le délai imparti pour la réceptionner la réponse est écoulé ;
probleme si un problème inattendu est survenu.
Protocole du réseau interbancaire
Message de demande d'autorisation
Ce message peut être émis par le réseau interbancaire et réceptionné par un serveur d'acquisition ou bien émis par un serveur d'acquisition et réceptionné par le réseau interbancaire.
Format : |I...I|DemandeAutorisation|A...A|B...B|\n avec :
I...I est l'identifiant de l'envoyeur du message (peut être son PID) ;
A...A correspond au montant de la transaction exprimé en centimes d'euros ;
B...B correspond au numéro de la carte sur 16 chiffres décimaux (longueur constante).
Message de réponse
Ce message est fourni par un serveur d'acquisition au réseau interbancaire ou par le réseau interbancaire au serveur d'acquisition.
Format : |I...I|ReponseAutorisation|A...A|B...B|\n avec
I...I est l'identifiant de l'envoyeur du message (peut être son pid) ;
A...A est la chaîne de caractère :
oui si la demande est acceptée ;
non si la demande est refusée ;
timeout si le délai imparti pour réceptionner la réponse est écoulé ;
probleme si un problème inattendu est survenu.
B...B est le numéro de carte (16 chiffres) sur laquelle la transaction a été passée.
Le serveur d'autorisation
Message de demande d'autorisation
Ce message est envoyé par le serveur d'acquisition au serveur d'autorisation.
Format : |I...I|DemandeAutorisation|A...A|B...B|\n avec :
I...I est l'identifiant du serveur d'acquisition (peut être son pid) ;
A...A correspond au montant de la transaction exprimé en centimes d'euros ;
B...B correspond au numéro de la carte sur 16 chiffres décimaux (longueur constante).
Message de réponse
Ce message est envoyé par le serveur d'autorisation au serveur d'acquisition.
Format : |I...I|ReponseAutorisation|A...A|B...B|\n avec :
I...I est l'identifiant du serveur d'autorisation (peut être son pid) ;
A...A est la chaîne de caractère :
oui si la demande est acceptée ;
non si la demande est refusée ;
timeout si le délai imparti pour réceptionner la réponse est écoulé ;
probleme si un problème inattendu est survenu.
B...B est le numéro de carte (16 chiffres) sur laquelle la transaction a été passée.