Le plus simple est encore que chaque serveur d'acquisition prenne de lui-même l'initiative de se connecter au serveur interbancaire en lui disant « Bonjour, je suis la banque DuFlouze, à votre service. », et maintienne la connexion ouverte. Le serveur du réseau interbancaire, lui, maintient en temps réel la liste des banques connectées.
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).
[^] # Encore des précisions :
Posté par Obsidian . En réponse au message Sockets - Processus. É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).