PeSIT (Protocole d'Echanges pour un Système Interbancaire de Télécompensation) est un protocole d'échange de fichiers entre systèmes informatiques reliés par une connexion réseaux.
Aperçu Conçu par des groupes de travail d'experts dans le domaine de transfert des fichiers de grands centres d'informatique. En plus de fonctionnalités de transferts de fichiers de base, il présente les caractéristiques et les fonctionnalités qui permettent de maîtriser des flux des transferts de fichiers de masse et organiser la production industrielle de services de transferts des fichiers. La connexion PeSIT se fait entre deux partenaires nommés et identifiables. L'initiateur d’une connexion jouant le rôle de demandeur PeSIT, il négocie avec le répondeur PeSIT l’envoi ou réception d’un fichier ou l’envoi d’un message ou d’un acquittement d’un transfert. La négociation de transfert d’un fichier se fait sans jamais mentionner ni le nom de fichier ni son emplacement dans les FS respectifs des partenaires. L’objet de négociation n’est pas un fichier de FS, mais un fichier virtuel identifiable par un identifiant, “filename” qui correspond à des jeux des définitions locales permettant d’accéder et lire un fichier du côté d’émetteur et de le créer et écrire du côté de récepteur. Chaque transfert a son identification unique connue de deux partenaires d’échange. Le protocole permet d’attribuer une priorité à chaque transfert qui devrait être respecté par deux parties.
Il permet : une gestion protocolaire de contrôle de flux, des interruptions et reprises de transferts, de leurs priorités et de leurs acquittements, de transferts par étapes (store and forward), d’encodages des données, de gestion d’organisation des flux de transferts par désactivation et activation des partenaires ou des fichiers virtuels. En synthèse, il permet de créer des outils incontournables pour l’organisation de services centralisés de transferts de fichiers d’envergure industrielle.
Genèse et Historique
Les échanges des fichiers entre des ordinateurs se faisaient bien avant l’ouverture de réseau Internet aux marchés civils en 1990. D’abord chaque producteur proposait à ses clients son réseau propriétaire comme réseau SNA d’IBM ou DECNET de DEC qui permettaient de relier entre eux des ordinateurs du même constructeur. La vraie révolution est arrivée avec les réseaux publics X25 (X.25 — Wikipédia (wikipedia.org 1976)) agnostic de provenance des équipements informatiques interconnectés. Transpac, opérateur français de réseau X25 a commencé son activité en 1978. Pour des établissements bancaires, l'arrivée d’un tel réseau public de télécommunication a ouvert des possibilités d'accélérer des échanges des fichiers client/banque (protocole ETEBAC3, très rudimentaire, défini par CFONB en 1984).
La tâche d’organiser des échanges entre banques a été confiée au Groupement d'Intérêts Economiques GSIT créé en 1983. La première version du protocole PeSIT (PeSIT SIT) a permis de relier les adhérents au réseau SIT-Système Interbancaire de Télécompensation en 1992. La définition initiale sur son utilisation sur X25, X32, PAD, ISO 8802.3 et NETEX était étendue à TCP/IP et APPN. La dernière version E de PeSIT a été publiée en avec plusieurs profils de son utilisation aussi bien sur le réseau SIT qu'en dehors pour des échanges Banque Client, mais aussi des échanges B2B et B2C. Les grands changements de réglementation financière se sont imposés à la suite du Conseil européen de Lisbonne en 2000 et du passage à l'euro. Le Conseil Européen des paiements (CEP, en anglais : European Payments Council, EPC) est né en , à l’initiative des banques européennes et leurs fédérations européennes, avec l’objectif de mettre en place l’Espace unique de paiement en euros (SEPA). Le réseau SIT était remplacé par un système STET-CORE en 2008 et GSIT a cessé son activité en 2011. Mais le protocole PeSIT, grâce à ses implémentations très efficaces reste aujourd’hui largement utilisé pour des échanges B2B et B2C pas uniquement en France, mais en Europe et même en dehors de l’UE.
Profils La dernière version E de PeSIT publiée en (voir www.pesit.org) définit quatre profils PeSIT:
PeSIT SIT
PeSIT HORS SIT
PeSIT HORS SIT Secure
ETEBAC5.
PeSIT SIT était conçu uniquement pour le réseau SIT. Aujourd’hui n’est plus utilisé.
PeSIT HORS SIT était retenu pour des échanges entre banques et leurs clients est devenu le profil le plus répandu pour des échanges en dehors des échanges financiers. Il est implémenté par tous les produits qui annoncent le support du protocole PeSIT.
PeSIT HORS SIT Secure inclut des fonctionnalités de sécurisation des données comme le chiffrement (DES et RSA) ou le scellement des fichiers. Très rapidement, il s'est retrouvé dépassé.
ETEBAC5 est un dérivé du profil PeSIT HORS SIT Secure avec chiffrement RSA uniquement. C’est ETEBAC5 qui était retenu par CFONB en tant que protocole PeSIT HORS SIT sécurisé pour des échanges des fichiers sensibles entre banques et grandes entreprises. Complexité d’exploitation et petit nombre d'implémentations avant l'arrivée de normes SEPA ont fait que ce profil n’a pas gagné de popularité.
Principes de fonctionnement Le protocole PeSIT est conçu comme une machine abstraite où des messages FPDU (File transfer protocol Data Unit) sont échangés entre deux unités PeSIT homologues : l’initiateur de connexion (le demandeur) et le serveur (le répondeur). Ces messages contiennent un en-tête protocolaire et une zone variable contenant des PIs ( Parameter Identifiers) avec des paramètres du protocole ou des données du fichier.
Une session PeSIT se déroule en différentes phases qui s’imbriquent. Dans chacune de ces phases, un certain nombre des services peuvent être exécutés. Chaque phase permet aux deux partenaires de coordonner l'exécution de ses services déclenchés par une FPDU de requête (=>) et acquittées par une FPDU de réponse (<=).
Les services de coupure de connexion, d’interruption de transfert et de résynchronisation , peuvent être déclenchés aussi bien par le demandeur que par le répondeur. La FPDU.ABORT n’est jamais acquittée.
Le processus de chaque transfert de fichier débute par sa négociation FPDU.CREATE pour l’envoi et FPDU.SELECT pour la réception. Les noms de fichiers et leurs emplacements restent à la discrétion des services PeSIT locaux. Les définitions locales de fichier virtuel de chaque côté déterminent la façon d'accéder au fichier et des opérations qui doivent être faites sur des enregistrements lors de leur lecture ou écriture. Toutes les opérations nécessaires pour préparer l’envoi et la réception des fichiers sont coordonnées par appel des services de sélection et d’ouverture.
Services d’écriture et de lecture de fichier permettent de se positionner au bon endroit dans les fichiers en cas de reprise de transfert.
L’envoi des données de fichier se fait enregistrement par enregistrement avec ou sans contrôle de flux et pose de points de reprise.
L’envoi de la FPDU.DTFEND par l’émetteur déclenche le service fin d’émission des données qui précède l'exécution de service de fin de transfert déclenché par le demandeur par l’envoi de FPDU.TRANSEND.
Les paramètres de FPDU.TRANSEND permettent un contrôle de nombre des enregistrements et des octets envoyés et reçus.
Fin de transfert et suivi par service de fermeture de fichier déclenché par FPDU.CRF et ensuite le service de désélection (FPDU.DESELECT).
C’est le demandeur qui termine la phase de connexion en envoyant FPDU.RELEASE.
Chaque FPDU de réponse porte le code diagnostic de résultat d'exécution du service.
Phase CONNEXION
Service d’établissement de connexion => FPDU.CONNECT, <= FPDU.ACONNECT ou FPDU.RCONNECT Service de libération de connexion => FPDU.RELEASE, <= FPDU.ACK(RELEASE) Service de coupure de connexion => FPDU.ABORT
Phase SELECTION
Service de création de fichier => FPDU.CREATE <= FPDU.ACK(CREATE) Service de sélection de fichier => FPDU.SELECT <= FPDU.ACK(SELECT) Service de désélection de fichier => FPDU.DESELECT <= FPDU.ACK(DESELECT) Service de transfert de message => FPDU.MSG (FPDU.MSGDM, FPDU.MSGMM,FPDU.MSGFM) <= FPDU.ACK(MSG).
Phase OUVERTURE DE FICHIER
Service d’ouverture de fichier => FPDU.ORF <= FPDU.ACK(ORF) Service de fermeture de fichier. => FPDU.CRF <= FPDU.ACK(CRF)
Phase TRANSFERT DE DONNÉES DE FICHIER
Service d’écriture de fichier => FPDU.WRITE <= FPDU.ACK(WRITE) Service de lecture de fichier => FPDU.READ <= FPDU.ACK(READ) Service d’émission de données => FPDU.DTF (FPDU.DTFDA,FPDU.DTFMA, FPDU.DTFFA), Service de pose de points de synchronisation => FPDU.SYN <= FPDU.ACK(SYN) Service de fin d'émission de données => FPDU.DTF_END Service de fin de transfert => FPDU.TRANS_END <= FPDU.ACK(TRANS_END) Service d’interruption de transfert => FPDU.IDT <= FPDU.ACK(IDT) Service de resynchronisation . => FPDU.RESYN <= FPDU.ACK(RESYN)
Les phases d’une session de service PeSIT s'imbriquent et elles s'exécutent de façon séquentielle (deux transferts ne peuvent pas être exécutés en parallèle pendant une même session).
Capacités Ce sont les capacités du protocole qui ont rendu des implémentations PeSIT HORS SIT si fortement ancrées dans les infrastructures de services IT de grandes entreprises.
Identification du répondeur portée par protocole (PI4) L'établissement de connexion est initié par le demandeur par envoi de FPDU.CONNECT qui contient aussi bien son identification que l’identification de répondeur ainsi que le mot de passe ce qui permet au répondeur d’identifier le demandeur et l’authentifier et également au demandeur d’authentifier le répondeur. FPDU.CONNECT avec l’identification du répondeur permet de bâtir des proxies PeSIT intelligents.
Contrôle de flux (PI7) Lors d'établissements de connexions, les deux partenaires négocient l’utilisation de service, de points de synchronisation ou de resynchronisation.
Envoi des messages et des acquittements. Le demandeur peut envoyer un message avec un texte allant jusqu’à 4095 octets. En plus du service de fin de transfert qui assure la coordination de la fermeture et de la désélection de fichier entre deux partenaires d’échange, le receveur de fichier peut envoyer un message spécifique appelé le message d'acquittement de la bonne réception du fichier.
Envoi et la réception de fichiers. Le demandeur peut envoyer ou demander de recevoir un fichier en annonçant ses caractéristiques protocolaires, comme :
Notion de fichier virtuel (PI12) qui est l’identification de fichier virtuel connu et défini par deux partenaires qui se caractérise par des attributs échangés entre les deux partenaires, à savoir :
annonce de la taille de fichier à transférer (PI41 et PI42), organisation de fichier (PI33) peut être séquentiel, relatif ou indexé,
format d’enregistrement (PI32) peut être fixe ou variable
longueur d’enregistrement (PI31).
La position de clé (PI38) et La longueur de clé (PI39) est notifiée en cas de fichier indexé. Code des données (PI16) peut être égal à ASCII, EBCDIC ou BINAIRE. l’utilisation de compression (PI21) est négociée entre les partenaires.
Identification de transfert connu de bout en bout (PI13)
Chaque transfert de fichier ou de message à son identification attribuée par l’émetteur et notifié au receveur ce qui permet un suivi et contrôle de chaque transfert de bout en bout.
Gestion de priorité de transfert (PI17) Chaque transfert doit avoir le niveau de priorité attribué par le demandeur de transfert qui est notifié au répondeur.
Coordination et contrôles de services de démarrage et fin d’un transfert Aussi bien la négociation de transfert d’un fichier que le processus de fin d’un transfert impliquent l'exécution des services qui permettent de contrôler leur résultat et notifier des échecs éventuels au même niveau d’avancement des phases respectives.
Interruption, suspension, reprise d’un transfert interrompu.