FR2827104A1 - Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur - Google Patents

Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur Download PDF

Info

Publication number
FR2827104A1
FR2827104A1 FR0108974A FR0108974A FR2827104A1 FR 2827104 A1 FR2827104 A1 FR 2827104A1 FR 0108974 A FR0108974 A FR 0108974A FR 0108974 A FR0108974 A FR 0108974A FR 2827104 A1 FR2827104 A1 FR 2827104A1
Authority
FR
France
Prior art keywords
application
hyperserver
applications
ftp
transfer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0108974A
Other languages
English (en)
Other versions
FR2827104B1 (fr
Inventor
Elzbieta Krystyna Ploc Cochard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to FR0108974A priority Critical patent/FR2827104B1/fr
Priority to US10/482,667 priority patent/US7440959B2/en
Priority to PCT/FR2002/002275 priority patent/WO2003005670A1/fr
Priority to EP02764936A priority patent/EP1407594A1/fr
Publication of FR2827104A1 publication Critical patent/FR2827104A1/fr
Application granted granted Critical
Publication of FR2827104B1 publication Critical patent/FR2827104B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

Le procédé selon l'invention assure le contrôle des échanges de fichiers ou autres objets transférables entre deux applications, respectivement de type client et de type serveur, selon un protocole de type FTP de TCP/ IP ou analogue, l'une des deux applications étant de type FTP, tandis que l'autre est soit une application de type FTP, soit une application compatible. Il met en oeuvre une application Hyperserveur qui s'exécute sur une plateforme hôte et joue le rôle d'intermédiaire entre les deux applications dans des négociations protocolaires de transferts ainsi que dans des transferts de fichiers ou autres objets transférables eux-mêmes.

Description

<Desc/Clms Page number 1>
La présente invention concerne un procédé pour le contrôle d'échanges de données entre deux applications, respectivement de type client et de type serveur, selon un protocole de type FTP de TCP/IP (RFC 959 1579) ou analogue, étant entendu que : - TCP/IP ("Transmission Control Protocol")/ ("Internet Protocol") est un ensemble de protocoles de transmission utilisé sur le réseau Internet, - FTP ("File Transfert Protocol") est un protocole de transfert de fichiers de
TCP/IP utilisé aussi bien sur Internet que sur des réseaux TCP/IP d'entreprise Intranet dont le protocole de réseau est TCP/IP,
Figure img00010001

- RFC ("Request for comments") est une nomination des protocoles TCP/IP, les applications serveur et client sont spécifiques du protocole FTP ou ont la capacité de générer un flux de données compatibles avec ce protocole.
L'invention a plus particulièrement pour objet, mais non exclusivement, un procédé mettant en oeuvre une application Hyperserveur qui s'exécute sur une plateforme hôte et qui joue le rôle d'intermédiaire entre deux applications dont l'une est de type FTP tandis que l'autre est soit une application de type FTP, soit une application compatible, pour conduire les négociations protocolaires de transferts ainsi que les transferts de données elles-mêmes.
<Desc/Clms Page number 2>
Indépendamment de l'environnement d'exécution de ces applications, l'application Hyperserveur est dotée de moyens lui permettant d'avoir la visibilité et la faculté d'une interprétation et d'une traduction des informations échangées. Cette position de l'application Hyperserveur lui permet, non seulement de suivre les échanges de façon passive, mais aussi de les contrôler en interférant dans ces échanges en fonction des règles de contrôle, qui lui seront imposées et définies dans ses bases de données des annuaires des applications-partenaires et des profils de transfert.
Pour renforcer et élargir ces capacités de suivi et de contrôle au-delà de sa propre plateforme d'exécution, le procédé selon l'invention peut comprendre des applications agents sur les plateformes d'exécution des applications de type FTP (ou compatibles). En fonction des règles de contrôle et du déploiement des applications agents, tout ou seulement une partie de la population des applications de type FTP (ou compatible) peut être pleinement contrôlée. Cette population (ou partie de population) sera appelée ci-après "population contrôlée". L'ensemble des applications de type FTP (ou compatible) ne bénéficiant pas du contrôle de l'application Hyperserveur est dénommé population banalisée dans la suite de cette présentation. Les deux populations peuvent faire partie d'un même réseau IP ou appartenir à deux réseaux différents et, dans le deuxième cas, l'application Hyperserveur devra résider dans le réseau de la population contrôlée et être accessible par les applications de la population banalisée.
S'exécutant sur un hôte Intranet et étant le point de passage unique et obligatoire dans les échanges Intra/Intemet, le procédé selon l'invention permet d'effectuer les transferts en assurant la sécurité et la confidentialité des données abritées dans le réseau Intranet. Il assure par ailleurs les fonctionnalités d'un puissant moniteur d'exécution centralisé d'échanges de fichiers ou autres objets transférables. Les applications de type FTP (ou
<Desc/Clms Page number 3>
compatibles) du réseau Intranet constituent dans ce cas-là la population contrôlée et les partenaires Internet jouent le rôle de la population banalisée.
Dans cet environnement, la sécurité et la confidentialité de l'ensemble du réseau Intranet peuvent être préservées par le procédé selon l'invention puisque les noms des hôtes de ce réseau, les annuaires de fichiers (ou autres objets transférables) et leurs noms physiques peuvent rester invisibles pour les partenaires extérieurs du réseau Intranet. En fonction des règles d'attribution de noms physiques des fichiers (objets transférables) et des hôtes serveurs de type FTP ou compatibles FTP, les partenaires extérieurs n'ont besoin de connaître que les identificateurs des entrées de la base de données des profils de transfert de fichiers et des profils de connexion, définie ci-dessous et, parmi ces identificateurs, seulement ceux accessibles au demandeur identifié et authentifié.
L'application Hyperserveur est une application intermédiaire qui a la visibilité et le contrôle complet de toutes les données de négociations protocolaires et des fichiers (ou autres objets transférables) échangées par les applications qui communiquent entre-elles. De ce fait, et indépendamment de l'environnement de son exécution, l'application Hyperserveur a toutes les informations nécessaires pour assurer les fonctions d'un moniteur telles que le suivi, les statistiques et les interactions avec des opérateurs ou d'autres applications.
D'une façon plus précise, le procédé selon l'invention pourra mettre en oeuvre : - une population banalisée des hôtes résidant dans un réseau IP ayant accès à l'application Hyperserveur et hébergeant : - des applications de type FTP ou capables de générer un flux de données compatibles avec le protocole FTP, - des fichiers ou autres objets transférables identifiables et visibles pour ces applications,
<Desc/Clms Page number 4>
- une application Hyperserveur s'exécutant sur un hôte ayant accès aux applications de type FTP ou compatibles mentionnées ci-dessus et disposant de : - une base de données d'annuaire des hôtes contrôlés et banalisés désignant les applications communicantes avec leurs adresses IP et des listes des utilisateurs autorisés à y accéder ainsi que les attributs d'autorisation, si nécessaire (BDH), - une base de données d'annuaire des profils de transfert de fichiers ou autres objets transférables (BDP), - un fichier"LOG"central de l'application Hyperserveur (LGH), contenant les enregistrements de suivi de transferts, - un fichier journal central de l'application Hyperserveur (JRH), contenant les enregistrements récapitulatifs des transferts, - une population contrôlée d'hôtes résidant dans un réseau IP et hébergeant : - des applications de type FTP ou capables de générer un flux de données compatible avec le protocole FTP, - des fichiers ou autres objets transférables identifiables et visibles pour ces applications, - des applications agents de l'application Hyperserveur disposant éventuellement de leurs propres fichiers"LOG"et journal.
Il convient de noter que la population contrôlée des hôtes avec celui hébergeant l'application Hyperserveur peut être un ensemble d'ordinateurs et de fichiers d'une entreprise constituant un réseau Intranet. La base BDP de profil des transferts de fichiers avec les applications FTP ou compatibles constituent pour l'application hyperserveur le système d'accès aux fichiers aux termes du modèle de FTP. La population banalisée peut être, dans ce cas-là, l'ensemble des ordinateurs accédant via le réseau Internet à l'application Hyperserveur pour transférer des fichiers avec les hôtes de l'entreprise sous son contrôle.
<Desc/Clms Page number 5>
La base de données BDH contient toutes les informations nécessaires à l'application Hyperserveur pour : - identifier et/ou authentifier chaque demandeur de transfert, - identifier et/ou accéder à l'application destinatrice en respectant ses règles d'authentifications, - déterminer éventuellement les règles de cryptage à utiliser en fonction des demandeurs et des destinataires identifiés, - identifier et localiser l'application agent de l'application Hyperserveur assignée pour la partie de la connexion dans l'environnement contrôlé, - identifier éventuellement les processus à exécuter au début et/ou à la fin de la connexion, etc...
La base de données BDP définit les profils et scénarios des transferts de fichiers ou autres objets transférables à l'aide des attributs suivants, notamment : - l'emplacement des fichiers ou autres objets à émettre ou recevoir, et/ou - leur nom ou leur méthode de dénomination, et/ou - leur méthode d'accès, et/ou le type de données et/ou le code, et, éventuellement : - les processus et scénarios à exécuter au début et/ou pendant et/ou à la fin des transferts et/ou leur lieu d'exécution, et/ou - les critères et attributs d'autorisation d'accès au fichier ou objets à transférer.
Il est à noter que, à part des applications de type FTP qui sont les partenaires des échanges, la seule application ayant accès aux données de fichiers (autre objet) transférés est l'application Hyperserveur. Cette capacité lui permet
<Desc/Clms Page number 6>
d'agir éventuellement sur ces données en exécutant des processus en cours de transfert.
La mise en place d'un agent de l'application Hyperserveur sur chaque hôte de la population contrôlée permet d'effectuer un suivi local des transferts des fichiers. Les applications agents pourvues d'une interface de communication avec l'application Hyperserveur peuvent récupérer les informations concernant les transferts de fichiers de leur lieu d'exécution et/ou de recevoir de l'application Hyperserveur un ordre de lancer sous leur propre contrôle les processus en début ou en fin de ces transferts.
Dans une version préférée de l'invention, les bases de données BDH et BDP peuvent constituer les annuaires locaux de type LDAP ("Lightweight Directory Access Protocol") du réseau de la population contrôlée. LDAP est un protocole ouvert et largement diffusé qui permet d'accéder à ces annuaires sans un développement supplémentaire pour les applications s'exécutant dans un environnement fortement hétérogène.
A titre d'exemple, la présentation qui suit décrit les déroulements des opérations de transfert de fichiers dans l'environnement Intranet/Intemet où l'application Hyperserveur assure le suivi et le"monitoring"des transferts de fichiers côté Intranet. Rien n'empêche par ailleurs d'imaginer une autre application Hyperserveur située sur le réseau Internet générant le flux compatible à FTP et contrôlant des transferts de fichiers de sa population d'hôtes.
Dans cet environnement, le déroulement des opérations lors d'une demande de transfert à partir du réseau Internet est le suivant : - l'application de type FTP du client demandeur côté Internet ouvre, grâce à un jeu de commandes d'ouverture de connexion, la connexion avec
<Desc/Clms Page number 7>
l'application Hyperserveur en spécifiant son nom d'utilisateur, son mot de passe et éventuellement ses données d'authentification comme avec un serveur FTP classique, en fonction de règles définies dans l'annuaire BDH, les informations échangées pendant cette phase de la négociation avec le client FTP peuvent être suffisantes pour déterminer l'entrée de cet annuaire définissant les attributs de connexion avec l'application visée côté Intranet (sinon, une commande supplémentaire, par exemple SITE de FTP, peut être utilisée pour l'identifier), la corrélation entre le client demandeur et le serveur visé permet à l'application Hyperserveur de rechercher dans la base de données BDH toutes les informations concernant les droits d'accès du demandeur, le cryptage éventuel et ses clés, ainsi que le protocole éventuel de négociation et les modalités de la connexion avec le serveur visé, dès que le protocole et les modalités de connexion sont connus, l'application Hyperserveur peut ouvrir la connexion avec l'application destinatrice visée et entamer l'échange de commandes éventuellement prévues par le protocole, la poursuite de la négociation et le contenu d'une des commandes de transfert FTP du type"store","store unique","retrive"etc.. reçu par l'application Hyperserveur doivent lui permettre d'identifier un profil de transfert de fichier ou d'autres objets transférables qui constitue une entrée dans l'annuaire BDP, la définition du profil déterminé permet à l'application Hyperserveur de vérifier le sens de transfert, d'identifier le fichier à transférer, ses attributs, les processus éventuels à exécuter au début, pendant et à la fin du transfert ainsi que la désignation des applications sous contrôle desquelles leurs exécutions doivent avoir lieu, - qu'ayant achevé les éventuelles négociations de transfert induites par le profil de transfert avec l'application visée, l'application Hyperserveur pourra acquitter la demande du transfert reçu du client,
<Desc/Clms Page number 8>
- deux connexions"DATA"au sens FTP seront ouvertes : une, entre client
FTP et application Hyperserveur et l'autre entre l'application Hyperserveur et l'application visée ; les données reçues par l'application Hyperserveur sur une connexion seront envoyées sur l'autre en subissant éventuellement le traitement du processus"pendant le transfert", - l'exécution des éventuels processus au début et/ou à la fin du transfert s'effectuera sous le contrôle de l'agent de l'application Hyperserveur de l'hôte de l'application visée en synchronisme avec le dialogue entre cette application et l'application Hyperserveur à l'ordre de ce dernier, les enregistrements LOG (fichiers dans lesquels sont enregistrés tous les événements des connexions, des négociations et des transferts) et journal (fichier de statistiques) générés par l'application Hyperserveur seront effectués dans des fichiers LGH et JRH et leurs copies seront envoyées vers l'agent de l'application Hyperserveur concerné pour être mises dans les fichiers"LOG"et journal locaux.
Dans le cas où une demande de transfert provient d'un hôte du réseau Intranet donc de la population contrôlée, le déroulement de la procédure de transfert peut s'effectuer de manière symétrique. On sait cependant que la négociation d'un transfert entre l'application client et l'application serveur FTP ne laisse pas passer au serveur le nom de fichier à transmettre utilisé côté client.
Lorsque la demande provient donc d'une application client FTP côté Intranet, cette particularité du protocole FTP réduit les possibilités de supervision des échanges de fichiers qui peuvent être demandées à l'application Hyperserveur, puisqu'il ne dispose d'aucune information concernant le fichier (ou l'objet à transmettre) de son propre domaine de contrôle.
Il est préférable, dans ce cas, d'utiliser un dispositif du procédé selon l'invention, dénommé"Demande Directe de Transfert".
<Desc/Clms Page number 9>
Dans ce fonctionnement, lorsqu'une Demande Directe de Transfert est déposée par un utilisateur auprès de l'application Hyperserveur, le déroulement des opérations est le suivant : - la demande doit contenir toutes les informations nécessaires pour déterminer aussi bien l'entrée de l'annuaire BDH que celui de BDP, - en utilisant les informations trouvées dans l'entrée BDH déterminée, l'application Hyperserveur initialisera, en tant que client, deux connexions : une avec le serveur de type FTP (ou une application compatible) côté
Intranet et une avec le serveur de type FTP côté Internet, - il va négocier deux transferts selon les informations trouvées dans le (s) entrée (s) BDP et dans la demande elle-même ; un des transferts sera une réception et l'autre une émission de fichiers (ou d'un autre objet transférable), - l'application Hyperserveur acheminera les données du fichier, de son origine à sa destination à travers deux connexions de type DATA au sens
FTP ou compatibles entre elles-mêmes et deux applications serveurs, - le (s) profil (s) de transfert et autres paramètres de la Demande Directe de
Transfert permettra à l'application Hyperserveur de déterminer les noms de fichiers des deux côtés et tous les attributs du transfert ainsi que les processus à déclencher au début, pendant et à la fin du transfert.

Claims (13)

Revendications
1. Procédé pour le contrôle d'échanges de fichiers ou autres objets transférables entre deux applications, respectivement de type client et de type serveur, selon un protocole de type FTP de TCP/IP ou analogue, l'une des deux applications étant de type FTP, tandis que l'autre est soit une application de type FTP, soit une application compatible, caractérisé en ce qu'il met en oeuvre une application Hyperserveur qui s'exécute sur une plateforme hôte et qui joue le rôle d'intermédiaire entre les deux applications dans des négociations protocolaires de transferts ainsi que dans des transferts de fichiers ou autres objets transférables eux-mêmes.
2. Procédé selon la revendication 1, caractérisé en ce que l'application Hyperserveur comprend des moyens permettant d'effectuer une interprétation et/ou une traduction des informations échangées, indépendamment de l'environnement d'application des deux susdites applications.
3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que l'application Hyperserveur comprend des moyens de contrôler les échanges entre les deux susdites applications en interférant dans ces échanges en fonction de règles de contrôle qui lui sont imposées et définies dans ses bases de données des annuaires des applications partenaires et des profils de transferts.
4. Procédé selon l'une des revendications précédentes, caractérisé en ce que des applications agents disposant éventuellement de leurs propres fichiers"LOG"et journal sont mises en oeuvre sur les plateformes d'exécution des susdites applications de type FTP (ou compatibles) de manière à pouvoir contrôler tout ou partie de la population des applications de type FTP ou compatibles, la population des applications de type FTP (ou
<Desc/Clms Page number 11>
compatible) contrôlée et la population de l'ensemble des applications de type FTP (ou compatible) ne bénéficiant pas du contrôle de l'application Hyperserveur pouvant faire partie d'un même réseau IP ou appartenir à deux réseaux différents, l'application Hyperserveur résidant alors dans le réseau de la population contrôlée et être accessible par les applications de la population banalisée, les applications agents étant pourvues d'une interface de communication avec l'application Hyperserveur pour récupérer les informations concernant les transferts de fichiers de leur lieu d'exécution et/ou de recevoir de l'application Hyperserveur un ordre de lancer sous leur propre contrôle les processus en début ou en fin de ces transferts.
5. Procédé selon la revendication 4, caractérisé en ce que les applications de type FTP (ou compatibles) du réseau Intranet constituent la population contrôlée et les partenaires du réseau Internet jouent le rôle de la population banalisée.
6. Procédé selon la revendication 5, caractérisé en ce que l'application Hyperserveur s'exécute sur un hôte d'un réseau Intranet, et en ce qu'il constitue le point de passage unique et obligatoire entre ce réseau Intranet et le réseau Internet.
7. Procédé selon la revendication 6, caractérisé en ce que la susdite application Hyperserveur comprend des moyens rendant invisible l'identification des hôtes du réseau Intranet ainsi que ses annuaires de fichiers et tout autre objet transférable aux partenaires extérieurs du réseau Intranet, chaque utilisateur n'ayant à connaître que les identificateurs des entrées de la base de données des profils de transfert de fichiers et des profils de connexion de l'application Hyperserveur et, parmi ces identificateurs, uniquement ceux accessibles au demandeur identifié et authentifié.
<Desc/Clms Page number 12>
8. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il met en oeuvre : - une population banalisée des hôtes résidant dans un réseau IP ayant accès à l'application Hyperserveur et hébergeant : - des applications de type FTP ou capables de générer un flux de données compatibles avec le protocole FTP, - des fichiers ou autres objets transférables identifiables et visibles pour ces applications, - une application Hyperserveur s'exécutant sur un hôte ayant accès aux applications de type FTP ou compatibles mentionnées ci-dessus et disposant de : - une Base de Données d'annuaire des Hôtes contrôlés et banalisés (BDH) désignant les applications communicantes avec leurs adresses IP et des listes des utilisateurs autorisés à y accéder ainsi que les attributs d'autorisation, si nécessaire, - une Base de Données d'annuaire des Profils de transferts de fichiers ou autres objets transférables (BDP), - un fichier"LOG"central de l'application Hyperserveur (LGH), contenant les enregistrements de suivi de transferts, - un fichier journal central de l'application Hyperserveur (JRH), contenant les enregistrements récapitulatifs des transferts, - une population contrôlée d'hôtes résidant dans un réseau IP et hébergeant : des applications de type FTP ou capables de générer un flux de données compatible avec le protocole FTP, - des fichiers ou autres objets transférables identifiables et visibles pour ces applications, - des applications agents de l'application Hyperserveur disposant éventuellement de leurs propres fichiers"LOG"et journal.
<Desc/Clms Page number 13>
9. Procédé selon la revendication 8, caractérisé en ce que la base de données BDH contient toutes les informations nécessaires à l'application Hyperserveur pour : - identifier et/ou authentifier chaque demandeur de transfert, et/ou - identifier et/ou accéder à l'application destinatrice en respectant ses règles d'authentification, et/ou - déterminer éventuellement les règles de cryptage à utiliser en fonction des demandeurs et des destinataires identifiés, et/ou - identifier et localiser l'application agent de l'application Hyperserveur assignée pour la partie de la connexion dans l'environnement contrôlé, et/ou - identifier éventuellement les processus à exécuter au début et/ou à la fin de la connexion.
10. Procédé selon l'une des revendications 8 et 9, caractérisé en ce que la base de données BDP définit les profils et scénarios des transferts de fichiers ou autres objets transférables à l'aide des attributs suivants : - l'emplacement des fichiers ou autres objets à émettre ou recevoir, et/ou - leur nom ou leur méthode de dénomination, et/ou - leur méthode d'accès, et/ou le type de données et/ou le code, et, éventuellement : - les processus et scénarios à exécuter au début et/ou pendant et/ou à la fin des transferts et/ou leur lieu d'exécution, et/ou - les critères et attributs d'autorisation d'accès au fichier ou objets à transférer.
<Desc/Clms Page number 14>
11. Procédé selon la revendication 8, caractérisé en ce que les bases de données BDP constituent des annuaires locaux de type LDAP ("Lightweight Directory Access Protocol") du réseau de la population contrôlée.
12. Procédé selon la revendication 8, caractérisé en ce que, dans le cas d'une demande de transfert à partir du réseau Internet, il comprend la séquence opératoire suivante : - l'ouverture par le client demandeur du réseau Internet de la connexion avec l'application Hyperserveur grâce à un jeu de commandes d'ouverture d'une connexion comprenant un nom d'utilisateur, un mot de passe et éventuellement des données d'authentification, la détermination de l'entrée de l'annuaire définissant les attributs de connexion avec l'application visée du réseau Intranet dans le cas où lesdites informations sont suffisantes compte tenu des règles définies dans l'annuaire BDH, sinon l'utilisation d'une commande FTP supplémentaire pour permettre de le faire, - la recherche par l'application Hyperserveur, dans la base de données BDH de toutes les informations concernant les droits d'accès du demandeur, le protocole de transfert ainsi que les modalités de connexion avec le serveur visé, l'ouverture par l'application Hyperserveur de la connexion avec l'application destinatrice et l'échange de commandes éventuellement prévu dès que celui-ci ainsi que les modalités de connexion sont connus, l'identification par l'application Hyperserveur d'un profil de transfert de fichier ou d'autre objet transférable qui constitue une entrée dans l'annuaire BDP, à la suite de la réception par l'application Hyperserveur d'une commande de transfert, la vérification par l'application Hyperserveur du sens de transfert, de même que l'identification par celle-ci du fichier à transférer, de ses attributs, des
<Desc/Clms Page number 15>
Hyperserveur concerné pour enregistrement dans des fichiers locaux appropriés.
processus éventuels à exécuter au début, pendant et à la fin du transfert ainsi que la désignation des applications sous contrôle desquelles leurs exécutions doivent avoir lieu, grâce à la définition du profil déterminé, - l'acquittement, par l'application Hyperserveur, de la demande du transfert reçu du client à la fin des éventuelles négociations de transferts induites par le profil de transfert avec l'application visée, - l'ouverture de deux connexions"DATA"au sens FTP à savoir : une connexion entre client FTP et l'application Hyperserveur, et l'autre connexion entre l'application Hyperserveur et l'application visée, les données reçues par l'application Hyperserveur sur une connexion étant ensuite envoyées sur l'autre application en subissant éventuellement un traitement pendant le transfert, - l'exécution d'éventuels processus au début et/ou en fin de transfert sous le contrôle de l'agent de l'application Hyperserveur de l'hôte de l'application visée en synchronisme avec le dialogue entre cette application et l'application Hyperserveur, - l'enregistrement des événements apportés au cours de la séquence dans des fichiers correspondants (fichier LOG) ainsi que les informations de statistiques dans le fichier journal de l'application Hyperserveur et la transmission des copies de ces enregistrements à l'agent de l'application
13. Procédé selon la revendication 8, caractérisé en ce que dans le cas d'une demande de transfert provenant d'un hôte du réseau Intranet, la demande contient toutes les informations nécessaires pour déterminer les entrées aussi bien l'annuaire BDH que celui de 3DP, et en ce qu'il comprend la séquence opératoire suivante : - l'initialisation par l'application Hyperserveur en tant que client, de deux connexions à savoir : une première connexion avec le serveur de type FTP
<Desc/Clms Page number 16>
(ou une application compatible) du réseau Intranet et une deuxième connexion avec un serveur de type FTP situé sur le réseau Internet, cette initialisation utilisant les informations trouvées dans l'entrée BDH déterminée, - la négociation de deux transferts FTP selon les informations trouvées dans le (s) entrée (s) BDP et dans la demande elle-même, l'un des transferts étant une réception et l'autre une émission de fichiers ou d'un autre objet transférable, - l'acheminement par l'application Hyperserveur des données de fichier, de son origine à sa destination, à travers deux connexions de type DATA au sens FTP ou compatibles, entre l'application Hyperserveur et deux applications serveurs, la détermination par l'application Hyperserveur, des noms de fichiers des deux côtés et de tous les attributs du transfert ainsi que les processus à déclencher au début, pendant et à la fin du transfert, grâce au profil de transfert et autres paramètres de la demande.
FR0108974A 2001-07-03 2001-07-03 Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur Expired - Fee Related FR2827104B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR0108974A FR2827104B1 (fr) 2001-07-03 2001-07-03 Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur
US10/482,667 US7440959B2 (en) 2001-07-03 2002-07-01 Method of controlling exchanges of data between two applications, namely a client-type application and a server-type application respectively
PCT/FR2002/002275 WO2003005670A1 (fr) 2001-07-03 2002-07-01 Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur
EP02764936A EP1407594A1 (fr) 2001-07-03 2002-07-01 Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0108974A FR2827104B1 (fr) 2001-07-03 2001-07-03 Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur

Publications (2)

Publication Number Publication Date
FR2827104A1 true FR2827104A1 (fr) 2003-01-10
FR2827104B1 FR2827104B1 (fr) 2004-01-30

Family

ID=8865189

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0108974A Expired - Fee Related FR2827104B1 (fr) 2001-07-03 2001-07-03 Procede pour le controle d'echanges de donnees entre deux applications, respectivement de type client et de type serveur

Country Status (4)

Country Link
US (1) US7440959B2 (fr)
EP (1) EP1407594A1 (fr)
FR (1) FR2827104B1 (fr)
WO (1) WO2003005670A1 (fr)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110040730A1 (en) * 2007-10-23 2011-02-17 Eugen Adrian Belea System and method for backing up and restoring email data
EP2558934A4 (fr) * 2010-04-15 2014-08-13 Nokia Corp Procédé et appareil pour compatibilité et transfert de gadgets logiciels
US9021017B2 (en) * 2011-09-03 2015-04-28 Barracuda Networks, Inc. Configuring a plurality of diverse devices/services from an adaptive configuration control hyper-server apparatus
US9251360B2 (en) * 2012-04-27 2016-02-02 Intralinks, Inc. Computerized method and system for managing secure mobile device content viewing in a networked secure collaborative exchange environment
US9253176B2 (en) 2012-04-27 2016-02-02 Intralinks, Inc. Computerized method and system for managing secure content sharing in a networked secure collaborative exchange environment
US9148417B2 (en) 2012-04-27 2015-09-29 Intralinks, Inc. Computerized method and system for managing amendment voting in a networked secure collaborative exchange environment
US9553860B2 (en) 2012-04-27 2017-01-24 Intralinks, Inc. Email effectivity facility in a networked secure collaborative exchange environment
EP3069462A4 (fr) 2013-11-14 2017-05-03 Intralinks, Inc. Assistance en matière de litige passant par le partage de fichiers hébergés sur un cloud et la collaboration
WO2015164521A1 (fr) 2014-04-23 2015-10-29 Intralinks, Inc. Systèmes et procédés d'échange de données sécurisé
US10033702B2 (en) 2015-08-05 2018-07-24 Intralinks, Inc. Systems and methods of secure data exchange
CN112883009B (zh) * 2019-11-29 2024-05-07 北京百度网讯科技有限公司 用于处理数据的方法和装置
CN112383612B (zh) * 2020-11-11 2022-06-14 成都卫士通信息产业股份有限公司 一种文件传输方法、装置、设备及可读存储介质
CN115150207B (zh) * 2022-09-06 2022-11-29 北京六方云信息技术有限公司 工业网络设备识别方法、装置、终端设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998004971A1 (fr) * 1996-07-25 1998-02-05 Tradewave Corporation Procede et systeme de mise en application d'un protocole generalise sur des connexions de communications client/serveur

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4605414A (en) 1984-06-06 1986-08-12 John Czajka Reconstruction of a cruciate ligament
JPH0563749A (ja) * 1991-09-02 1993-03-12 Hitachi Ltd マルチプロトコル通信制御装置
JP2519390B2 (ja) * 1992-09-11 1996-07-31 インターナショナル・ビジネス・マシーンズ・コーポレイション デ―タ通信方法及び装置
AU702628B2 (en) 1995-04-12 1999-02-25 Smith & Nephew, Inc. Improved process for knee reconstruction
US6170008B1 (en) * 1998-12-07 2001-01-02 Mediaone Group, Inc. On-the-fly trivial file transfer protocol
US20030149601A1 (en) * 2000-12-14 2003-08-07 Cabral Anthony J. Network billboard system and method thereof
US7171668B2 (en) * 2001-12-17 2007-01-30 International Business Machines Corporation Automatic data interpretation and implementation using performance capacity management framework over many servers
US7724281B2 (en) * 2002-02-04 2010-05-25 Syniverse Icx Corporation Device facilitating efficient transfer of digital content from media capture device
CA2391719A1 (fr) * 2002-06-26 2003-12-26 Ibm Canada Limited-Ibm Canada Limitee Edition de fichiers de systemes eloignes dans un environnement de developpement integre

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998004971A1 (fr) * 1996-07-25 1998-02-05 Tradewave Corporation Procede et systeme de mise en application d'un protocole generalise sur des connexions de communications client/serveur

Also Published As

Publication number Publication date
US20040216128A1 (en) 2004-10-28
FR2827104B1 (fr) 2004-01-30
US7440959B2 (en) 2008-10-21
EP1407594A1 (fr) 2004-04-14
WO2003005670A1 (fr) 2003-01-16

Similar Documents

Publication Publication Date Title
FR2827104A1 (fr) Procede pour le controle d&#39;echanges de donnees entre deux applications, respectivement de type client et de type serveur
US7349974B2 (en) Method for coordinating actions among a group of servers
De Laat et al. Generic AAA architecture
US7275102B2 (en) Trust mechanisms for a peer-to-peer network computing platform
EP1645971B1 (fr) Procede de controle d&#39;acces a une base de donnees, controleur d&#39;acces a une base de donnees, serveur de traitement d&#39;agent, programme de controle d&#39;acces a une base de donnees, et support d&#39;enregistrement de ce programme
KR100781725B1 (ko) 피어 투 피어 인가를 위한 방법 및 시스템
US5944793A (en) Computerized resource name resolution mechanism
US5857191A (en) Web application server with secure common gateway interface
CA2738295C (fr) Procede pour autoriser et bloquer un pc utilisateur qui peut utiliser l&#39;internet au meme moment dans un reseau prive associe a un procede pour analyser et detecter une evaluation pour savoir si une nat (translation d&#39;adresse de reseau) peut etre utilisee ou non a l&#39;aide de donnees de trafic, et le nombre de terminaux qui partagent la nat
JP2002529856A5 (fr)
US20040044776A1 (en) Peer to peer file sharing system using common protocols
JP4467256B2 (ja) 代理認証プログラム、代理認証方法、および代理認証装置
WO2001001656A1 (fr) Partage de sessions universel
CA2826680A1 (fr) Systeme et procede pour conscience de donnees en temps reel et suivi de fichier
US20060143301A1 (en) Systems and methods for establishing and validating secure network sessions
US20090193127A1 (en) Systems and Methods for Establishing and Validating Secure Network Sessions
EP1244264A2 (fr) Dispositif et procédé de traitement de données d&#39;accès illégal
EP1561327A1 (fr) Procedes et systemes pour l&#39;acheminement de demandes au niveau d&#39;un commutateur de reseau
US8024784B1 (en) Method and system for providing remote secure access to a peer computer
JP2003518820A (ja) 循環暗号化および復号化プロセスのための方法および装置
JP3877388B2 (ja) 情報提供システム
CN100559769C (zh) 访问远程应用的方法和基础设施
Ning et al. A query facility for common intrusion detection framework
EP2235881A2 (fr) Préservation de système client-serveur d&#39;informations d&#39;état mis en réseau par l&#39;intermédiaire d&#39;un protocole sans état
Gommans et al. Generic AAA architecture

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20130329