Voilà je dois réaliser un petit programme "simulation bancaire".
Voici le schéma :
---------- --------------- ---------------- )
| Terminal |=========| Serveur |=========| Serveur | ) BANQUE DU
---------- (1) | d’acquisition | (2) | d’autorisation | ) COMMERCANT
--------------- ---------------- )
/\
|| (3) )
\/ )
================= ) RESEAU
|| Réseau || ) INTERBANCAIRE
|| Interbancaire || )
================= )
/\ )
|| (3’) )
\/
--------------- ---------------- )
| Serveur |=========| Serveur | ) BANQUE DU
| d’acquisition | (2’) | d’autorisation | ) CLIENT
--------------- ---------------- )
Le but est qu'un terminal se connecte au serveur d'acquisition de la banque dont-il appartient.
- Si la carte bancaire lue fait partie de cette banque, redirection vers le serveur d'autorisation pour vérification solde etc ...
- Sinon redirection vers le Réseau Interbancaire. Pour recherche de la banque via le numéro de compte bancaire.
C'est à ce moment si que je coince ;)
Les serveurs d'acquisitions se trouvent dans le même programme. Donc utilisation de processus pour autant de serveurs d'acquisitions que de banques.
Comment le Réseau Bancaire peut-il rediriger l'information sur le socket du processus de la banque en question (Acquisition).
Puisque l'information vient de l'acquisition de la banque du terminal et doit être envoyée du réseau interbancaire à l'acquisition de la banque du numéro de compte.
Via le PID du processus est-ce possible ?
Je vous remercie d'avance
# des précisions?
Posté par ecyrbe . Évalué à 2.
quel son les but? te force t'on a utiliser les socket? des processus differents pour chaque serveur?
Car si tu peut tout faire en simulation pure, pas besoin de lancer un process pour chaque banque. Juste une bonne gestion de graphe... avec un système de notification de type slot/signal ou de callback.
[^] # Re: des précisions?
Posté par Sebastian . Évalué à 3.
Ici utilisation intensive des sockets.
Utilisation d'une mémoire partagée
Chaque terminal est un processus.
Chaque banque est représentée par un processus pour le serveur acquisition et un processus pour le serveur d'autorisation.
[^] # Encore des précisions :
Posté par Obsidian . Évalué à 1.
Ensuite, tu définis un protocole de communication commun à tous les protagonistes de l'affaire mais concrètement, il s'agit de faire trois choses :
- S'authentifier (« Je suis le terminal|serveur d'acquisition|serveur d'autorisation|réseau interbancaire, et pour le prouver, voici mon mot de passe »).
- Faire une requête de transaction.
- Répondre à cette requête par « Oui », « Non », ou « Réseau Indisponible ».
Ensuite, cela se passe au niveau des serveurs d'acquisition.
- Une requête peut provenir invariablement d'un terminal ou du réseau interbancaire. Les deux connexions seront traitées exactement de la même façon :
- La requête est réémise telle quelle soit vers le serveur d'autorisation local s'il s'agit de la bonne banque, soit vers le réseau interbancaire, là encore de manière complètement transparente.
- Le réseau interbancaire réémet vers la requête vers la connexion du serveur bancaire idoine si celui-ci a pris le soin au préalable de se connecter ou de s'authentifier, ou bien prends l'initiative de renvoyer lui-même la réponse « Réseau indisponible ».
- On suit exactement la même procédure pour envoyer les réponses des serveurs d'authentification aux terminaux.
Le principe du réseau interbancaire est donc le même que celui d'un hub ou d'un serveur IRC : n connectés tous identiques, et le premier qui envoie un message le voit relayé à tout le monde, ou au moins aux connexions autorisées.
Conseil : Pour les messages, adopte le principe des datagrammes. Plutôt que de faire une suite séquentielle genre write question read réponse write merci read de rien, tu fais comme au bingo : Chaque fois qu'un cas de figure sort (requête,réponse, etc), tu mets un flag sur une ligne et quand une ligne est pleine (càd lorsque tu as réuni toutes les conditions), tu déclenches une action. Cela te permet de gérer plusieurs connexions en parallèle sans avoir à lancer plusieurs processus, et en t'affranchissant totalement de l'ordre d'arrivée des différents messages. C'est d'ailleurs comme cela que fonctionne la pile TCP/IP, à un niveau bien plus bas.
Il faudra veiller également à ce que chaque serveur d'autorisation contienne non seulement la liste de ses propres comptes en banque, mais également celle des terminaux autorisés à s'y connecter.
Enfin, à mon goût, ce modèle est le meilleur à ce niveau-là, mais dans la vie réelle avec des machines distantes, l'usage veut que chaque processus soit bidirectionnel, et que ce soit le premier qui ait quelque chose à dire qui ouvre la connexion, transmette son message et referme la connexion (comme au téléphone).
[^] # Re: Encore des précisions :
Posté par Sebastian . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.