Brevet FR2792086A1 — publié le 20001013

L'invention est du domaine général des procédés pour machines informatiques. Elle concerne plus particulièrement les procédés de transfert d'informations. Sur une machine à mémoire virtuelle paginée, il existe principalement deux méthodes de base permettant le transfert de l'information entre deux espaces d'adressage (ici entre le driver et une application cliente): la copie et le mappage (" mapping " en anglais). 1/ Une première méthode, appelée copie, consiste à recopier les informations à transmettre entre deux applications de l'espace mémoire de la première vers l'espace mémoire de la seconde. Ceci implique une duplication de l'information. Le temps nécessaire à cette copie est directement proportionnel à la quantité d'informations à transférer. 2/ Dans le cas d'une quantité importante d'informations à transférer, il existe une seconde technique intéressante à base de mappage mémoire. On rappelle que le principe de la mémoire virtuelle est de dissocier la mémoire physique et la vue qu'en ont les applications. La mémoire physique est découpée en pages, et il y a une correspondance entre pages physiques et pages virtuelles. Cette correspondance entre pages virtuelles et pages physiques est maintenue dans une table de pages associée à chaque application. Dans la gestion mémoire, la page est usuellement l'unité d'allocation de base, une taille habituelle de page est de 4 kilo-octets. Dans une architecture à mémoire virtuelle, chaque application possède une mémoire virtuelle linéaire et contiguë de taille potentiellement supérieure à la taille de la mémoire physique réellement disponible pour ladite application. Au fur et à mesure de l'utilisation par l'application de pages mémoires virtuelles, des pages physiques sont attribuées à l'application pour y travailler réellement. Bien que l'application partage les ressources mémoire de la machine avec les autres applications s'exécutant sur la machine, elle a l'illusion de posséder sa propre ressource mémoire linéaire et contiguë. Le mappage est l'association entre une page physique et une page virtuelle. Quand une page physique est associée à une page virtuelle, elle est dite mappée en mémoire (virtuelle), Lorsque cette association est supprimée, la page est dite démappée. Une page physique peut être mappée sur plusieurs adresses virtuelles différentes à la fois. La méthode de transfert par mappage consiste à modifier le mappage de la page physique contenant les informations à transférer afin de la rendre visible et accessible par l'application destinataire. Il s'agit principalement de modifier l'association virtuelle-physique dans la ou les table(s) de page de l'application destinataire (et éventuellement dans celle de l'application émettrice), et d'invalider les entrées correspondantes dans le cache des adresses virtuelles (Translation Lookaside Buffer: TLB) du système de gestion de mémoire virtuelle de la machine. Plusieurs variantes de cette méthode existent selon si le mappage est maintenu ou non entre la page physique et l'application " émettrice ", ou encore selon que l'adresse virtuelle de destination référence déjà ou non une page physique. Le temps de mappage dépend moins directement de la taille des données à transférer que le temps de copie car il est proportionnel au nombre de pages à transférer. Ce mécanisme peut ainsi être particulièrement intéressant pour des tailles de données proche d'un multiple de la taille d'une page. Lié au fait que le coût de la copie est directement proportionnel à la taille du transfert contrairement au mappage, le coût de la copie progresse plus rapidement avec la taille des données que le coût du mappage. Ainsi on observe généralement que la copie se révèle plus coûteuse que le mappage au delà d'une taille de transfert donnée. En dessous d'une taille seuil, on utilise la copie pour transférer des données. Au dessus de la valeur seuil, au contraire, c'est la méthode de mappage qui est utilisée. Cette technique est illustrée par la figure 2. La limite se situe communément en deçà de la taille d'une page. La copie présente cependant l'avantage que seule la mémoire contenant l'information est concernée par le transfert, tandis qu'avec le mappage la mémoire transférée est forcément un multiple de la taille d'une page. Il existe dans la littérature de nombreuses propositions de mécanismes de transfert utilisant l'une ou l'autre ou une combinaison des deux méthodes de transfert que sont la copie et le mappage. Ces propositions cherchent à tirer parti de ces méthodes afin de transférer efficacement de l'information entre deux espaces d'adressage. Ces différents mécanismes mettent en oeuvre une ou plusieurs des techniques suivantes: Mappage statique: une zone de la mémoire physique est partagée par le système et l'ensemble des applications, par exemple la mémoire tampon de réception de la carte réseau. Cette technique offre un coût de transfert nul mais limite l'emplacement des blocs de mémoire tampon (" buffer " en anglais) à une zone spéciale. De plus les données sont visibles et éventuellement accessibles par toutes les applications. Afin de garantir l'intégrité des données, il est possible de modifier les droits d'accès à la page de manière à ce qu'une seule application ait le droit d'écriture à un instant donné. Il est à noter que lorsque l'on parle ici de coût de transfert nul, on ne considère que le coût du transfert des données proprement dites (la mémoire étant déjà mappée dans l'application, il n'y a rien à faire pour rendre les données accessibles). On ne considère pas le coût lié à la notification (prévenir l'application qu'une donnée est disponible, indiquer à l'application o elle peut trouver les données transférées, etc.). Cette remarque est vraie pour toutes les techniques de l'art antérieur présentées ici. Mappage dynamique: les pages contenant les données sont mappées dans l'espace d'adressage de l'application destinataire. Ainsi, contrairement à la technique précédente, les données ne sont visibles que par l'application destinataire. Les pages peuvent être mises en lecture seulement chez l'émetteur pour garantir l'intégrité des données ou elles peuvent être démappées de l'espace d'adressage de l'émetteur à condition que celui-ci n'ait plus besoin d'y accéder. Afin de limiter les coûts de remappage, les pages mappées peuvent être maintenues après libération par le client pour le cas o elles seraient réutilisées ultérieurement. Copie sur écriture (COW: " copy-on-write "): dans le cas o le mappage d'une page est en lecture seulement dans l'espace d'adressage d'une application et que celle-ci ait besoin d'y accéder en écriture, la technique de copie sur écriture peut être associée au mappage. Dans ce cas, l'application qui accède en écriture à la page provoque une violation d'accès dont l'événement est récupérable par le système. Celui- ci peut alors allouer une nouvelle page physique, y copier les données et modifier le mappage afin que l'application puisse accéder en écriture aux données. Cette technique associé au mappage permet de maintenir l'intégrité des données et limite les copies au cas o les applications émettrices et réceptrices ont besoin d'accéder en écriture aux données, Copie en deçà d'un seuil: réalise une copie si la taille des données à transférer est inférieure à un seuil en deçà duquel un mécanisme par mappage se révèle plus coûteux qu'une copie (voir figure 2). Permutation ("Swapping" en anglais): I'émetteur et le receveur s'échangent des pages physiques par remappage. Cette technique permet d'éviter le problème de fuite des pages physiques de l'émetteur vers le récepteur auquel on peut rapidement être confronté avec le mappage dynamique. Dans le cas o les données à transférer n'ont pas une taille multiple de celle de la page, les techniques précédentes peuvent être associées aux techniques suivantes pour tenir compte de la différence de granularité existant dans les mécanismes par mappage entre les conteneurs (les pages physiques) et les données: Complément à zéro (" zero-completion "): cette technique consiste à compléter avec des zéros les parties d'une page mappée qui ne sont pas déjà remplies par les données à transférer. Cette technique est utilisée pour éviter qu'une application ait accès à des données autres que celles qui lui sont transférées. Permutation avec copie en retour (" reverse copy "): cette technique est une extension de la technique de permutation vue précédemment. La page contenant les données à transférer est complétée par copie par les informations situées dans la page de l'application destinataire. Puis les deux pages sont interverties par permutation. L'opération est totalement transparente pour l'application destinataire. Excepté avec la dernière technique de permutation avec copie en retour, ces différentes techniques à base de mappage peuvent impliquer une perte importante de place mémoire lors de transferts successifs de grande taille. En effet, lors d'un mappage, toute page entamée est considérée comme entièrement utilisée (on utilise toujours un nombre entier de pages), ainsi un mappage d'une zone de données de 4097 octets utilisera deux pages dont une comportera un seul octet utile. Une multiplication d'un tel motif peut rapidement causer une saturation de la mémoire utilisée pour les transferts alors qu'elle est partiellement libre (en particulier dans le cas de transferts multiples dans un temps rapide). Si la technique de permutation avec retour permet d'éviter ce problème de sous-utilisation de la mémoire, elle se révèle par contre très coûteuse car elle nécessite à chaque transfert deux opérations de mappage et une, voire deux, copies. Le problème fondamental formulé dans l'invention est donc de prendre en compte le problème de différence de "granularité" entre la taille des données à transférer et la taille des pages mémoire, lors de transfert de données entre applications, tout en minimisant le coût du transfert en termes de temps par une combinaison des techniques de mappage et de copie. Le but de la présente invention est de proposer un nouveau procédé de transfert mémoire permettant la réutilisation des espaces perdus lors des transferts par mappage. Un second but de l'invention est d'optimiser la performance de transfert tout en maximisant l'utilisation de la mémoire physique utilisée pour le transfert mémoire. A cet effet, le procédé de transfert mémoire entre applications exécutées sur un ordinateur disposant de moyens adaptés à la réalisation de transfert mémoire par copie ou par mappage, comporte une étape d'allocation, lors d'un transfert par copie, d'au moins une partie de l'espace inutilisé dans un ensemble de pages physiques mappées incomplètement utilisées lors de précédents transferts mémoire. Selon une mise en oeuvre avantageuse, le procédé comporte: une étape de choix entre copie et mappage selon un critère prédéterminé (ou une combinaison de critères), et, dans le cas de choix de copie, un second choix entre: une copie de type classique dans un bloc de mémoire tampon de l'application, ou une copie dans au moins une partie de l'espace inutilisé dans un ensemble de pages mappées incomplètement utilisées lors de précédents transferts mémoire. Comme on le voit, le procédé selon l'invention combine les deux types de transfert mémoire pour offrir deux modes de fonctionnement permettant une optimisation du transfert selon un critère éventuellement propre à l'utilisateur (ou une combinaison de critères) Dans une mise en oeuvre préférée de l'invention, le procédé de transfert mémoire comporte outre la phase de transfert de données dans des blocs de mémoire tampon de l'application réceptrice par copie ou mappage, des phases de libération de ces blocs de mémoire tampon, d'ouverture et de fermeture de session. On comprend que la phase d'ouverture de session correspond à la mise en place et à l'initialisation du mécanisme de transfert entre deux applications, que la phase de libération est réalisée lorsque l'application réceptrice n'a plus besoin du contenu d'un bloc de mémoire tampon, et que la phase de fermeture de session correspond à la désinstallation du mécanisme de transfert. Dans la phase d'ouverture de session, l'application réceptrice réserve un espace de mémoire virtuelle contigu de son espace d'adressage virtuel o seront mappées les pages transférées, et met en place un espace de mémoire partagée avec le système contenant la table des adresses virtuelles décrivant l'espace virtuel réservé pour le mappage, une queue de réception et une table de hashage pour la gestion des espaces libres résultant des transferts par mappage. La table de hashage sert à gérer les espace libres dans les pages virtuelles sur lesquelles ont été mappées les pages physiques contenant les données que l'on souhaite transférer. Cette disposition correspond à la mise en place de moyens de repérage et de mémorisation des pages mémoires incomplètement utilisées. Selon une mise en oeuvre préférée, la phase de transfert comporte une étape de choix du mode de transfert mémoire par mappage ou par copie. Dans ce cas, selon des dispositions préférentielles éventuellement utilisées en conjonction, - si le choix est une copie des données à transférer, la phase de transfert comporte des étapes de: C1 - recherche d'un bloc de mémoire libre de taille supérieure ou égale à la taille des données à transférer dans la table de hashage, C2 - retrait du bloc de mémoire libre de la liste chaînée pointée par l'entrée trouvée dans la table de hashage, C3 - copie des données à transférer dans le bloc de mémoire libre ainsi alloué, C4 - si le bloc mémoire appartient à une page physique précédemment mappée suivant l'invention, mise à jour de l'entête de la page, C5 - initialisation et insertion d'un nouveau descripteur dans la queue de réception. - et, si le choix est un mappage, la phase de transfert comporte des étapes de: M1 - recherche d'une adresse virtuelle libre dans la table d'adresses virtuelles située dans l'espace de mémoire partagé M2 - modification du statut de l'adresse virtuelle ainsi trouvée, pour indiquer que l'adresse est utilisée. M3 - mappage de la page physique à l'adresse virtuelle trouvée M4 - mise à jour de l'entête de la page M5 - initialisation et insertion d'un nouveau descripteur dans la queue de réception Avantageusement, dans ces deux cas, le procédé comporte en outre une étape d'insertion du bloc d'espace encore libre dans la table de hashage pour une utilisation ultérieure. Ces dispositions permettent une mise en oeuvre favorable de l'allocation d'espace inutilisé dans des pages mappées lors du transfert mémoire, et de mémorisation d'espace encore utilisable dans des pages demeurant incomplètement utilisées après le transfert. Le procédé constitue préférentiellement une extension du procédé de gestion de mémoire virtuelle de l'ordinateur. L'invention vise également un dispositif comportant des moyen de réutilisation, lors du transfert, de l'espace inutilisé dans des pages mappées incomplètement utilisées. L'invention vise plus généralement un téléphone, un appareil photographique, une imprimante, un scanner, une caméra, un ordinateur, un télécopieur, un téléviseur, un lecteur audio/vidéo, caractérisés en ce que ces dispositifs comportent un dispositif tel qu'exposé brièvement ci-dessus L'invention vise également un moyen de stockage d'informations et un moyen de stockage d'informations amovible, partiellement ou totalement, lisibles par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, permettant la mise en oeuvre du procédé exposé succinctement ci-dessus La description et les dessins qui suivent permettront de mieux comprendre les buts et avantages de l'invention. Il est clair que cette description est donnée à titre d'exemple, et n'a pas de caractère limitatif. Dans les dessins: la figure 1 représente le schéma bloc classique d'un dispositif mettant en oeuvre l'invention; - la figure 2 représente le coût comparé en termes de temps pour un transfert de mémoire par copie ou par mappage, selon la taille des données à transférer; - la figure 3 montre un exemple de descripteur de la queue de réception; - la figure 4 représente le format d'un descripteur du groupe (" pool " en anglais) d'adresses virtuelles; la figure 5 représente un exemple d'organisation d'une page physique suivant l'invention; - la figure 6 illustre l'organisation de la table de hashage; - la figure 7 illustre les structures de données utilisées par l'invention De façon générale, le procédé est destiné à être mis en oeuvre dans un micro- ordinateur 10, par exemple de type dit PC, dont l'architecture générale est illustrée sur la figure 1, et sur lequel travaillent un système d'exploitation et plusieurs applications (dénommés clients du système) de façon simultanée. Le micro-ordinateur 10 comporte une unité centrale 100 (notée CPU sur la figure 1), par exemple un processeur de type Pentium, laquelle exécute les instructions relatives à la mise en oeuvre de l'invention, lesdites instructions étant stockées dans une mémoire morte (ROM) 102 ou dans d'autres éléments de stockage. Ce micro-ordinateur 10 possède des moyens classiques (matériels et/ou logiciels) de gestion de mémoire virtuelle, connu de l'homme de l'art. Une architecture de communication 101 (par exemple sous la forme d'un bus) permet la communication entre les différents sous-éléments (écran 104, clavier 105, disque dur 106, Lecteur de disquettes 107, etc.) du micro- ordinateur 10 ou liés à lui. La représentation de l'architecture de communication 101 n'est naturellement pas limitative, et notamment l'unité centrale 100 est susceptible de communiquer des instructions ou des données à tout sous- élément du micro-ordinateur 10 directement ou par l'intermédiaire d'un autre sous-élément du micro-ordinateur 10. Apres la mise sous tension, une mémoire vive (RAM) 103 contient le code exécutable du procédé selon l'invention ainsi que les variables nécessaires à la mise en oeuvre de l'invention. Cette mémoire vive 103 contient également les informations qu'un client souhaite transférer de l'espace d'adressage d'une application ou du système d'exploitation vers l'espace d'adressage d'une autre application. Ces informations peuvent être produites et placées en mémoire par les applications elles-mêmes durant leur exécution ou par tout sous-élément du micro-ordinateur 10, comme par exemple une interface de communication 109 vers un réseau 110. La description ci-dessous du procédé selon l'invention concerne un transfert d'information entre le système et une application dans le cas o, par exemple, le système reçoit des informations d'une carte réseau de type éthernet destinée à ladite application. Dans la description, on présente d'abord des structures de données utilisées par l'invention, avant de décrire le procédé de transfert selon l'invention. En ce qui concerne les structures de données, lors de l'ouverture de session, c'est à dire de l'initialisation d'une session de transfert entre deux applications, un espace mémoire partagé 60 entre une application émettrice 62 et une application réceptrice 61 est mis en place par mappage. Cet espace de mémoire partagé 60 contient, entre autres, une queue de réception 603, utilisée pour communiquer à l'application réceptrice 61 I'emplacement o les données ont été transférées. Cette queue de réception 603 peut prendre par exemple la forme d'une table circulaire de descripteurs 6030 parcourus en ordre premier arrivé premier sorti "FIFO" (First In, First Out), ou encore la forme d'une liste de descripteurs 6030 chaînés permettant l'insertion d'un nouveau descripteur 6030 en n'importe quel point de la liste. La deuxième forme de queue de réception 603 présente l'avantage de pouvoir éventuellement associer un niveau de priorité à un transfert quant à sa prise en compte par l'application réceptrice 61. Dans le cas d'une queue de réception 603 sous forme d'une table circulaire de descripteurs 6030 "FIFO", les descripteurs 6030 contiennent au moins les informations suivantes: - Pointeur(s) sur l'emplacement mémoire contenant les données, - Taille(s) des données transférées, - Bit assurant l'exclusion mutuelle sur le descripteur 6030, celui-ci est utilisé pour indiquer quelle est l'application de l'émettrice 62 ou de la réceptrice 61, propriétaire du descripteur 6030 à un instant donné, - D'autres informations comme le statut de la réception peuvent également apparaître dans le descripteur 6030. La figure 3 illustre un exemple de ce que peut être un descripteur 6030 de queue de réception 603. Il est à noter que dans le cas d'une queue de réception 603 sous forme d'une liste chaînée de descripteurs 6030, chaque descripteur 6030 doit également posséder un pointeur vers le descripteur 6030 suivant et éventuellement vers le descripteur précédent (selon l'implémentation), ces pointeurs étant nécessaires pour assurer le chaînage. L'espace mémoire partagé 60 entre les deux applications 61, 62 contient également des structures de données décrivant une table d'adresses virtuelles 602 (figure 6) de l'application réceptrice 61, lesdites adresses virtuelles correspondant à des pages virtuelles 630 sur lesquelles peuvent être mappées des pages physiques 640 contenant des informations à transférer. Cette table d'adresses virtuelles 602 est organisée sous la forme d'une liste de descripteurs 6020. La figure 4 est un exemple d'un descripteur 6020 décrivant une adresse virtuelle de la table 602. Un statut placé, dans l'exemple décrit ici à titre non limitatif, en tête de descripteur 6020 indique si la page 630 correspondant à cette adresse virtuelle est en cours d'utilisation ou non. Dans la suite de la description, à chaque fois qu'il est fait mention d'une page physique 640, il faut comprendre une page physique 640 mappée sur une page virtuelle 630 de l'application réceptrice 61, la page virtuelle 630 faisant partie d'un groupe 63 de pages virtuelles réservée par l'application réceptrice 61. Le contenu des pages physiques 640 utilisées pour le transfert des données est organisé suivant le schéma de la figure 5 et, par exemple, la structure C suivante: Typedef struct { page_st *pgnext; unsigned short pkt_cpt; unsigned short avait lsz; unsigned short availoff; unsiqned short data_off; ) page_st; Ainsi, suivant l'invention, chaque page physique 640 utilisée pour le transfert de données comprend un entête en début de page, comprenant par exemple - un pointeur sur la page physique 640 suivante (pg_next) permettant de chaînée les pages physiques 640 entre elles, - un compteur de référence (pktcpt), indiquant le nombre de paquets de données situés sur la page physique 640, - la taille de l'espace libre (avail_sz) dans la page physique 640, - un offset (avail_off) sur le prochain espace libre de la page physique 640, - et un offset (dataoff) sur le début de l'espace contenant les données. Le procédé de gestion des espaces libres dans les pages physiques 640 mappées sur des pages virtuelles 630 de l'application réceptrice 61 est une adaptation du mécanisme de gestion mémoire par les fonctions alloueur de mémoire "malloc" (de l'anglais memory allocation) et libération "free", connues de l'homme du métier. Il utilise une table dite "de hashage" 601 (qui est une table permettant de garder une trace des espaces disponibles pour des copies ultérieures), située dans l'espace mémoire partagé 60 entre l'application émettrice 62 et l'application réceptrice 61. Cette table de hashage 601 est utilisée pour gérer les espaces libres dans une page virtuelle 630 après une opération de mappage et, selon l'implémentation, des espaces libres supplémentaires 650 (sous-blocs de mémoire) spécialement alloués par l'application réceptrice 61 pour recevoir les données par copie. Cette table de hashage 601 permet de mémoriser les espaces libres dans les pages virtuelles 630 sur lesquelles ont été mappées des pages physiques 640, en les triant suivant leur taille. Chaque entrée de la table de hashage 601 définit une taille minimale d'un espace libre (en général défini comme une puissance de 2). La figure 6 illustre l'organisation de la table de hashage 601 pour la gestion des espaces libres utilisés dans le transfert par copie. Par exemple la irème entrée de la table de hashage 601 est un pointeur sur un espace libre (dans une page physique 640 mappée sur une page virtuelle 630) d'au moins 2^(i+3) octets (2 puissance (i+3)). Dans ce cas le plus petit bloc d'espace libre (d'une page physique 640) gérable par cette table de hashage 601 ne peut être inférieur à 8 octets (i = 0). Les espaces libres (dans les pages physiques 640) correspondant à une même entrée i de la table de hashage 601 sont alors organisés en une liste chaînée 630i, ainsi qu'on le voit sur la figure 6. Afin de pouvoir chaîner les espaces libres (dans les pages physiques 640) correspondant à une même entrée de la table de hashage 601 on utilise une structure de données située au début de l'espace libre (d'une page physique 640) contenant au moins un pointeur sur l'espace libre suivant. Cette structure de données n'est présente que quand l'espace libre (d'une page physique 640 mappée) est référencé par la table de hashage 601. Elle est placée dans l'espace libre afin de chaîner les espaces libres entre eux, et est destinée à être écrasée par les données qui seront copiées dans cet espace libre lorsque celui-ci sera alloué pour transférer par copie à l'application réceptrice 61 de nouvelles données. Si l'application réceptrice 61 combine dans une même table de hashage 601, d'une part, des pointeurs vers des blocs de mémoire libre provenant des pages physiques 640 mappees sur des pages virtuelles 630, avec, d'autre part, des pointeurs vers des sous-blocs de mémoire 650 spécialement réservés à la copie, alors les blocs sont différenciés à l'aide d'un marqueur (en anglais tag) spécifique placé en début de bloc. La figure 7 donne alors un aperçu de l'ensemble des structures de données utilisées par l'invention. Cette figure montre un espace de mémoire partagé 60 entre une application réceptrice 61 et une application émettrice 62. L'espace partagé comprend une table d'adresses virtuelles 602 (les descripteurs 6020 de la table 602 sont illustrés figure 4), une table de hashage 601 utilisée pour la gestion des espaces libres dans les pages physiques 640 mappées, une queue de réception 603 (comportant les descripteurs 6030 illustrés par exemple figure 3), et un compteur 604 comptabilisant le nombre de pages mappées. Les pages physiques 640 (figure 5) que l'application émettrice 62 peut utiliser pour transférer de l'information à l'application réceptrice 61 décrivent une liste chaînée 64. Lors du transfert mémoire, ces pages physiques 640 seront mappées sur des pages virtuelles 630 dans l'espace de mémoire virtuelle 63 réservé par l'application réceptrice 61 et décrit par la table 602. L'espace de mémoire partagé 60 peut être décrit par la structure C suivante: Struct channel f /* pointeur sur la table des espaces libres pour copie 601*/ freeblockd *freetbl []; /* compteur des pages couramment mappées 604*/ unsigned int *cptpqmap; /* description de la tabla des adresses virtuelles 602*/ vmd *vm_first; vmd *vmnext; vmd *vm_last; /* description de la queue de réception 603*/ rxd *rx_first; rxd *rx_next; rxd *rx_last; Les deux applications, émettrice 62 et réceptrice 61, impliquées dans le transfert, possèdent leur propre copie de la structure de l'espace de mémoire partagé 60. En ce qui concerne maintenant le procédé de transfert mémoire selon I'invention, il comporte des phases d'ouverture de session, de transfert des données dans des blocs de mémoire tampon de l'application réceptrice par copie ou mappage, de libération de ces blocs de mémoire tampon (quand l'application n'a plus besoin de leur contenu) et de fermeture de session. Quand une application réceptrice 61 souhaite pouvoir échanger des informations avec le système, elle doit procéder en premier lieu à une phase d'initialisation lors d'une ouverture de session avec le système afin de mettre en place les structures de données utilisées par l'invention (figure 7). Pour ce faire, l'application réceptrice 61 réserve un espace de mémoire virtuelle 63 contigu de son espace d'adressage virtuelle o seront mappées les pages transférées. Elle met en place un espace de mémoire partagée 60 avec le système contenant la table des adresses virtuelles 602 décrivant l'espace virtuel réservé pour le mappage, une queue de réception 603, une table de hashage 601 pour la gestion des espaces libres, et un compteur 604 du nombre de pages mappées dans l'espace de mémoire virtuelle 63 réservé. Par exemple, si les données transférées entre le système et l'application réceptrice 61 sont des paquets réseaux de type éthernet, la table de hashage 601 devra pouvoir gérer des espaces libres allant de 64 octets (taille minimale d'un paquet éthernet) à 1516 octets (taille maximale d'un paquet = Maximum Transmission Unit + header). Ainsi la ième entrée de la table de hashage 601 pointera sur des espaces libres d'au moins 2^(i+6) octets avec 0 Le système alloue autant de pages physiques 640 qu'il y a d'entrées dans la table des adresses virtuelles 602, pages qu'il rajoute à son groupe de mémoires tampon (" pool of buffers " en anglais) de transfert libres. Eventuellement (selon sa programmation), l'application réceptrice 61 peut allouer des blocs de mémoire supplémentaires 65, destinés au transfert par copie, qu'elle peut décomposer en sous-blocs 650, qu'elle insère dans sa table de hashage 601 à l'entrée adéquate (voir plus haut et figure 6) en fin de liste chaînée 630i correspondante. Un marqueur (" tag " en anglais) placé dans le descripteur des sous-blocs mémoires permet de différencier les sous-blocs mémoires provenant des espaces libres des pages mappées 630, des sous- blocs 650 ainsi alloués. Pour le transfert de données, on suppose que les données à transférer sont placées directement dans les pages physiques utilisés pour le transfert. Par exemple, le système utilise le groupe (" pool " en anglais) de pages physiques 64 comme groupe de mémoires tampon de réception d'une carte réseau classique, par exemple de type DEC21140 "TULIP". Le choix du mode de transfert peut être fait suivant différents paramètres comme la taille des données à transférer N, le coût respectif d'un transfert par copie ou par mappage (suivant un seuil prédéterminé) pour un transfert de taille N, l'état des différents groupes de mémoires (existe t-il un emplacement libre pour y faire un mappage ?, existe t-il un bloc de mémoire libre suffisamment grand pour y copier le paquet ?). L'importance des différents paramètres peut varier suivant que l'on privilégie la vitesse ou l'occupation mémoire. Plus précisément, si on souhaite privilégier la vitesse, on optera pour le mécanisme de transfert le moins coûteux en perte de temps, c'est à dire le mappage pour de gros paquets de données et la copie pour des petits paquets. Si l'on souhaite privilégier l'occupation mémoire, on privilégiera plutôt le mécanisme par copie dans les espaces libres d'une page précédemment mappée. Par exemple, si on reçoit deux paquets successifs de données de 1500 octets, si on privilégie la vitesse de transfert, on procédera à deux mappages successifs (en considérant que le coût de transfert par mappage est inférieur au coût de transfert par copie pour un paquet de 1500 octets). Deux pages physiques sont alors utilisées pour le transfert des deux paquets. Si on privilégie l'occupation mémoire, le premier transfert peut être un mappage (plus rapide que la copie), mais le deuxième transfert est une copie dans l'espace libre de la page que l'on vient de mapper. Le transfert des deux paquets est alors plus coûteux en terme de temps mais une seule page physique est utilisée pour le transfert des deux paquets. Si la politique de choix utilisée ne permet pas de départager entre un transfert par copie ou un transfert par mappage, il existe alors un choix par défaut, déterminé par le fait de privilégier la vitesse de transfert ou l'occupation mémoire (décrit ci-dessus). Si par contre il n'est possible de faire ni un transfert par copie ni un transfert par mappage par manque de blocs de mémoire tampon disponibles, alors le transfert ne peut avoir lieu (le paquet de données est rejeté) et éventuellement selon l'implémentation une erreur est retournée à I'initiateur du transfert.. Si le choix est une copie des données à transférer, les étapes de l'algorithme sont les suivantes: C1 - recherche d'un bloc de mémoire libre FB de taille supérieure ou égale à la taille des données à transférer N dans la table de hashage 601 suivant les techniques classiques de parcours d'une table de hashage 601 connues de l'homme du métier c'est-à-dire: calcul du premier i vérifiant N À C2 - retrait du bloc de mémoire libre FB (de la page physique 640) de la liste chaînée 630i pointée par l'entrée i de la table de hashage 601. Par construction de la table de hashage 601, ce bloc de mémoire libre FB est assez grand pour y copier les données à transférer. Le bloc de mémoire libre qui est retiré de cette liste chaînée 630i appartient soit à une page virtuelle 630 (et donc à la page physique 640 mappée sur cette page virtuelle 630), soit à un sous-bloc mémoire 650 (figure 5). À C3 - copie des données à transférer dans le bloc de mémoire libre FB ainsi alloué. C4 - si le bloc mémoire FB appartient à une page physique 640 précédemment mappée suivant l'invention (ce qui est déterminé par la valeur du marqueur (tag) situé au début du bloc de mémoire), mise à jour de I'entête de la page c'est-à-dire incrémentation du compteur de référence pktcpt indiquant le nombre de paquets de données situés sur la page physique 640, mise à jour de la taille avail_sz restant disponible dans la page, ainsi que de l'offset sur l'espace disponible avail_off. L'adresse de l'entête d'une page (adresse notée AP) est déterminée à partir de l'adresse du bloc de mémoire FB (adresse notée AB) suivant la formule: AP = AB & -PGOFSET avec PGOFSET égale à la taille d'une page mémoire moins 1 (soit 4096 - 1 pour une taille de page de 4096 octets). Eventuellement (la décision pouvant par exemple dépendre d'un seuil), le bloc d'espace encore libre FB1 (espace restant dans le bloc de mémoire libre FB après y avoir copié les données de taille N) est inséré dans la table de hashage 601 pour une utilisation ultérieure. Dans ce cas, il y a: - calcul du premier i vérifiant 2A(i+6) exemple), - puis insertion d'un pointeur vers le bloc de mémoire encore libre FB1 dans la liste chaînée 630i pointée par l'entrée i ainsi calculée, dans la table de hashage 601. L'insertion peut être faite en début ou en fin ou en tout point de la liste chaînée 630i suivant les choix d'implémentation (par exemple si la liste chaînée 630i est maintenue triée suivant une taille de bloc mémoire croissante ou décroissante). Il est important de noter que si le bloc de mémoire encore libre FB1 n'est pas inséré dans la table de hashage 601, alors le champ offset sur le prochain espace libre de la page physique 640 (availoff) est positionné à 0. C5 - initialisation et insertion d'un nouveau descripteur 6030 (figure 3) dans la queue de réception 603 donnant à l'application réceptrice 61 les informations nécessaires sur le transfert de données (localisation, taille, statuts, Si le choix (de transfert pour la page mémoire MP) est un mappage, les étapes de l'algorithme sont les suivantes: M1 - recherche d'une adresse virtuelle libre FA dans la table d'adresses virtuelles 602 située dans l'espace de mémoire partagé 60 (recherche d'une entrée dans la table d'adresses virtuelles 602 dont le statut est marqué comme libre). ò M2 - modification du statut de l'adresse virtuelle FA ainsi trouvée, pour indiquer que l'adresse est utilisée. M3 - mappage de la page physique à l'adresse virtuelle FA trouvée (la page physique peut être maintenue mappée dans l'espace mémoire de lI'application émettrice 62 ou non suivant les implémentations). Avec le mappage de la page physique à l'adresse virtuelle FA, il y a également incrémentation du compteur 604 indiquant le nombre de pages couramment mappées. À M4 - mise à jour de l'entête de la page: incrémentation du compteur de référence indiquant le nombre de paquets de données situés sur la page pkt_cpt, mise à jour de la taille disponible dans la page avail_sz et de l'offset sur l'espace libre avail_off. Eventuellement (la décision peut par exemple dépendre d'un seuil), le bloc d'espace encore libre FB2 (espace non utilisé dans le bloc de mémoire pointé par l'adresse virtuelle FA après y avoir mappé la page mémoire MP) est inséré dans la table de hashage 601 pour une utilisation ultérieure. Dans ce cas, il y a: - calcul de i tel qu'il vérifie 2^(i+6) 630i pointée par l'entrée i ainsi calculée dans la table de hashage 601. L'insertion peut être faite en début ou en fin ou en tout point de la liste chaînée 630i suivant les choix d'implémentation (par exemple si la liste chaînée 630i est maintenue triée suivant une taille de bloc mémoire croissante ou décroissante). Ici encore il est important de noter que si le bloc de mémoire encore libre FB2 n'est pas inséré dans la table de hashage 601 alors le champ offset sur le prochain espace libre de la page (avail_off) est positionné à 0. M5 - initialisation et insertion d'un nouveau descripteur 6030 (figure 3) dans la queue de réception 603 donnant à l'application réceptrice 61 les informations nécessaires sur le transfert de données (localisation, taille, statuts, Dans tous les cas, après le transfert, l'application réceptrice 61 trouve les données transférées dans son espace d'adressage en consultant les informations situées dans les descripteurs 6030 de la queue de réception 603. Après réception des données transférées, l'application réceptrice 61 peut procéder à l'étape de libération du bloc de mémoire tampon de réception en mettant en jeu les étapes suivantes: À L1- mise à jour de l'entête de la page contenant le bloc de mémoire tampon. L'adresse de l'entête de page (adresse notée AP) est déterminée à partir de l'adresse du bloc de mémoire tampon (adresse notée AB) à l'aide de la formule suivante: AP = AB & -PGOFSET avec PGOFSET égale à la taille d'une page mémoire moins 1 (soit 4096 - 1 pour une taille de page de 4096). Le compteur de référence indiquant le nombre de paquets de données situés sur la page pktcpt est décrémenté, * L2 - si le compteur de référence indiquant le nombre de paquets de données situés sur la page pktcpt vaut 0, et si le champ offset sur le prochain espace libre de la page avail_off vaut 0, alors la page peut être démappée et rendue à l'application émettrice 62: L2.1 - démappage de la page physique 640 qui est replacée dans le groupe des pages libres 64 de l'application émettrice 62 et le compteur 604 est décrémenté. L2.2 - modification du statut du descripteur 6020 correspondant à l'adresse virtuelle utilisée dans l'application réceptrice 61 pour marquer cette adresse comme à nouveau disponible pour un autre mappage. Cette étape peut par exemple utiliser l'algorithme suivant: offset = ( (buf & -PGOFSET) - chan->vmfirst->addr) / NBPG; if (offset ≤ chan->vmatbi sz) { current = chan->vmfirst + offset; current->status = DESCFREE; } avec buf, l'adresse du bloc de mémoire tampon de réception, chan-> vm_first- >addr, l'adresse de la première entrée de la table d'adresses virtuelles 602, NBPG, la taille d'une page mémoire (par exemple 4096 octets), et enfin chan- >vmatblsz, la taille de la table d'adresses virtuelles 602. Il est à noter ici que la phase de libération est légèrement modifiée dans le cas o l'implémentation prévoit l'allocation de sous blocs mémoire 650 destinés au transfert par copie par l'application réceptrice 61. On a vu plus haut que dans ce cas, l'application réceptrice 61 insère ces sous blocs 650 dans sa table de hashage 601 à l'entrée adéquate en fin de liste chaînée 630i correspondante et qu'un marqueur placé dans le descripteur des sous-blocs mémoires permet de différencier les sous-blocs mémoires provenant des espaces libres des pages mappées 630, des sous-blocs 650 ainsi alloués. Ce marqueur est alors utilisé dans la phase de libération d'un bloc mémoire pour déterminer s'il s'agit d'un bloc provenant d'une page virtuelle 630 ou d'un sous bloc 650. Dans le cas o il s'agit d'un bloc provenant d'une page virtuelle 630, la libération correspond aux phases L1 et L2 telles que décrites plus haut. Par contre, dans le cas o il s'agit d'un sous bloc 650, la libération consiste à replacer le sous-bloc mémoire 650 dans la table de hashage 601 pour une réutilisation ultérieure. Lors de la fermeture d'une session de transfert, l'ensemble des structures de données utilisées par le mécanisme, et mises en place à l'ouverture de session, sont libérées. Si la valeur du compteur 604 vaut zéro, alors la libération des structures de données survient lors de l'appel à la fermeture de la session. Si le compteur 604 a une valeur différente de zéro, c'est que plusieurs pages virtuelles 630 sont en cours d'utilisation. Dans ce cas la fermeture de session peut se dérouler suivant différentes variantes: 1 - I'appel de fermeture retourne une erreur. La fermeture de session ne peut pas avoir lieu tant qu'il y a des blocs de mémoire tampon en cours d'utilisation. L'application réceptrice 61 pourra renouveler son appel après avoir libéré les blocs de mémoire tampon en cours d'utilisation. 2 - la libération effective des structures de données est différée. La session de transfert de données est terminée mais les structures de données ne seront libérées que lors de la libération du dernier bloc de mémoire tampon en cours d'utilisation. 3 - bien que des blocs de mémoire tampon soient en cours d'utilisation, les structures de données sont tout de même libérées (y compris les blocs de mémoire tampon), et l'application réceptrice 61 est prévenue que l'utilisation desdits blocs de mémoire tampon générera une erreur. On comprend que, dans la description précédente, lorsque le choix d'un transfert par copie est effectué, la réalisation d'une copie de type classique ou d'une copie dans une page précédemment mappée ne relève pas forcément d'un choix explicite. En effet, cela dépend de l'implémentation qui est faite: si les blocs de mémoire tampon correspondant au premier cas et les blocs de mémoire tampon correspondant au second cas sont gérés dans des groupes séparés, il faut faire un choix entre l'un ou l'autre groupe; si les blocs de mémoire tampon sont gérés dans un même groupe, il n'y a pas de choix à réaliser. La description qui a été faite dans le cas d'un transfert de données entre le système et une application peut naturellement et facilement être adaptée par I'homme du métier à un transfert de données entre deux applications. Dans une variante de mise en oeuvre du procédé de transfert mémoire, la phase d'ouverture de session comporte une étape supplémentaire de négociation entre l'application réceptrice 61 et l'application émettrice 62 ou entre l'application réceptrice 61 et un serveur de connexion (non représenté) auprès duquel serait enregistrée l'application émettrice 62. Cette négociation a pour but d'autoriser la connexion et de fixer la taille des différents groupe de blocs de mémoire tampon. Dans une autre variante, le choix du type de transfert réalisé se fait selon trois critères de seuils: le premier seuil (A) concerne le nombre de pages mémoire disponibles pour effectuer le transfert. Le calcul de ce seuil peut être fait de plusieurs manières suivant la taille de mémoire totale, les caractéristiques du système (vitesse des transferts, durée d'utilisation des pages mémoire...). Ce seuil peut être exprimé avec un pourcentage de la mémoire globale (par exemple 4% de la mémoire globale) ou avec une valeur absolue (par exemple 4 pages mémoires). Si on est dans une configuration o la mémoire disponible est supérieure au seuil prédéterminé A, alors on est dans le cas o le choix pour le procédé de transfert (copie ou mappage) dépend uniquement de la taille des données à transférer. Si on est dans une situation avec une mémoire disponible inférieure à ce seuil A avant le transfert des données, alors la gestion de la mémoire devenant critique, on passe dans un second mode de transfert. Si on est au dessus de ce seuil A de mémoire restante, un second seuil (B) concerne la taille des transferts et équivaut au seuil cité dans la méthode hybride exposée plus haut, et illustrée par la figure 2. Il sert à choisir entre le transfert par copie ou par mappage. En dessous du seuil B, le transfert par copie est choisi, au dessus de ce seuil, le transfert par mappage est préféré, et on passe au critère de seuil suivant. Un troisième seuil (C) concerne l'espace perdu lors du transfert d'une page par mappage. Si l'espace perdu lors du transfert d'une page de données est inférieur à ce seuil C, le transfert par mappage est réalisé directement. Par contre, pour un espace perdu supérieur à ce seuil C, on stocke en mémoire les références de la page de données concernée, qui devient alors candidate à une réutilisation ultérieure, puisque elle contient une grande part d'espace en fait inutilisé. Le calcul de l'espace perdu est obtenu avec la formule suivante: Espace perdu = TP - (TT modulo TP) dans laquelle TP désigne la taille d'une page mémoire, et TT la taille totale des données transférées. Cet espace perdu correspond à une information de taille de la mémoire disponible associée à cette page pour une réutilisation ultérieure, ce qui sera en particulier le cas lorsque la mémoire restante pour le transfert de données devient inférieure au seuil A. Cette information de taille mémoire disponible associée à la page est également stockée en mémoire. Le fonctionnement détaillé du mappage avec stockage d'information, est alors le suivant. Une liste de structures est associée à chaque client. Dans cette liste sont stockées les pages candidates à être utilisées dans le second mode de gestion de mémoire. Si le mappage d'une nouvelle page dans l'espace mémoire du client donné concerne une page dont le remplissage est inférieur au seuil C (taille de la page - seuil C), alors une nouvelle structure est insérée dans la liste associée au client. Cette structure est initialisée avec l'adresse physique de la page et la taille mémoire disponible restant dans la page. Le contenu de la liste associée au client est utilisé soit quand on passe en mode mémoire restreinte (test de seuil A), soit quand une page du client est * démappée, et que la structure associée est retirée de la liste du client. Plusieurs variantes sont envisageables en ce qui concerne la gestion des listes. On peut stocker les informations sur toutes les pages partiellement utilisées (seuil C égal à 0) ou uniquement sur celles présentant un espace supérieur à un seuil donné (C>0). Dans une autre variante, seules les informations sur les N dernières pages mappées sont conservées (car ce sont celles qui ont le plus de probabilité d'être conservées dans l'espace cible pour le temps le plus long). D'autres variantes sont encore envisageables, selon les propriétés d'utilisation des données par le client (durée fixe, ou durée proportionnelle à la taille totale du transfert). Lorsque une application (client) n'est plus exécutée par l'ordinateur, les pages mémoires qui lui sont associées sont libérées. Lors de la libération d'une page mappée (c'est à dire la suppression de l'adresse virtuelle associée à cette page, également appelé démappage), on vérifie si cette page a été concernée par un second référencement via une copie dans la partie non occupée. Dans ce cas, le démappage n'est pas réalisé tout de suite, mais lorsque la seconde référence sur la page est invalidée. Cette fonctionnalité est supportée déjà par certains gestionnaires de mémoire virtuelle (dans le cas de mappage dans plusieurs espace d'adressage, la liste des différents utilisateurs est conservée et mise à jour au fur et à mesure des utilisations). De même, on peut envisager en variante qu'une page soit référencée plus de deux fois par le même utilisateur (s'il y eu plusieurs copies successives dans une même page mappée). On décrit maintenant l'algorithme utilisé dans la variante de procédé, dans le cas o la taille mémoire disponible est inférieure à un seuil prédéterminé A au moment de la demande de transfert de données mémoire d'une application vers une autre application. Dans ce mode dit "mémoire restreinte", si la taille des données à transférer est supérieure ou égale à la taille restante maximale disponible dans la liste des pages incomplètement utilisées, alors on revient à une méthode classique de transfert. Sinon, la copie est effectuée dans la page de la liste qui a suffisamment de place disponible. Plusieurs variantes sont envisageables: copie dans la page ayant juste une taille un peu supérieure à la taille des données à transférer, copie dans la page la plus grande, copie dans la première page assez grande. L'enregistrement de la page est alors mis à jour en indiquant qu'elle contient un référencement supplémentaire (c'est à dire le pointeur sur la copie), ceci peut être matérialisé par l'incrémentation d'un compteur référence contenu dans la structure dédiée à la page concernée. De plus, il est possible, si l'on veut limiter le nombre de copies dans une page mappée, de retirer la structure de la liste associée au client, et éventuellement de l'insérer dans une seconde liste associée au client, concernant les pages déjà réutilisées. Les étapes du traitement, pour la réutilisation de pages lors d'un transfert avec mémoire restante inférieure au seuil A (mode mémoire restreinte), sont les suivantes: - accès à la liste de pages disponibles associée au destinataire du transfert, - extraction du premier descripteur (structure) de la liste dont l'espace libre est suffisant pour stocker le transfert courant, - lecture de l'adresse de début de l'espace libre, transfert des données à partir de cette adresse et mise à jour de l'adresse utilisateur, - mise à jour de l'adresse de fin de données, incrémentation du compteur de références sur la page mappée, - retrait de la page de la liste des pages disponibles, associée au destinataire du transfert, et - insertion dans une liste de pages réutilisées du client. La structure utilisée pour stocker les informations associées aux pages déjà mappées qui présentent de l'espace disponible (espace disponible > seuil C), ou qui présentaient de l'espace disponible et qui ont été réutilisées pour recevoir au moins une copie de données supplémentaires, est par exemple de la forme suivante: struct infomap{ unsigned long page_available; unsigned int size_available; unsigned int ref_number; I dans laquelle page_available est un champ contenant un pointeur vers la page mappée, size_available est un champ contenant la taille de l'espace encore disponible dans la page, ref_number est un champ contenant le nombre de références associées à la page. Dans cette variante de procédé, différentes bases de données sont associées aux clients de transferts. La première base est une liste des clients destinataires qui permet de retrouver les pages associées à un espace mémoire donné. Chaque élément de cette base est une liste de structures, qui contient les structures (descripteurs) associées aux pages effectivement disponibles pour réutilisation d'espace en mode mémoire restreinte. La seconde base est une liste de pages référencées plusieurs fois, qui sert à garder trace des pages qui ont été utilisées et qui sont en attente de libération. Lors des demandes de démappage de ces pages, le compteur ref_number associé permet au gestionnaire de mémoire virtuelle de savoir quand il est possible d'effectuer réellement le démappage: quand ref_number est revenu à la valeur zéro, le descripteur (structure) associé à la page est libéré (plus de référence à cette page dans quelque application que ce soit). Bien entendu, la présente invention ne se limite pas aux détails des formes de réalisation décrits ici à titre d'exemple, mais s'étend au contraire aux modifications à la portée de l'homme de l'art. REVENDICATIONS 1. Procédé de transfert mémoire entre applications émettrice (62) et réceptrice (61), exécutées sur un ordinateur (10) comportant un système d'exploitation et disposant de moyens adaptés à la réalisation de transfert mémoire par copie ou par mappage, ledit procédé comportant une phase de transfert par copie ou mappage, caractérisé en ce qu'il comporte une étape d'allocation, lors d'un transfert par copie, d'au moins une partie de l'espace inutilisé dans un ensemble de pages physiques mappées (640) incomplètement utilisées lors de précédents transferts mémoire. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte: une étape de choix entre copie ou mappage selon un critère prédéterminé, et, dans le cas de choix de copie, un second choix entre: - une copie de type classique dans un bloc de mémoire tampon de l'application réceptrice (61), - ou une copie dans au moins une partie de l'espace inutilisé dans un ensemble de pages mappées incomplètement utilisées lors de précédents transferts mémoire. 3. Procédé selon la revendication 1, caractérisé en ce que le procédé de transfert mémoire comporte outre la phase de transfert de données dans des blocs de mémoire tampon de l'application réceptrice (61) par copie ou mappage, des phases de libération de ces blocs de mémoire tampon, d'ouverture de session et de fermeture de session. 4. Procédé selon la revendication 3, caractérisé en ce que dans la phase d'ouverture de session, I'application réceptrice (61): réserve un espace de mémoire virtuelle (63) contigu de son espace d'adressage virtuel o seront mappées les pages physiques (640) transférées, met en place un espace de mémoire partagée (60) avec l'application émettrice (62). 5. Procédé selon la revendication 4, caractérisé en ce que, en outre, dans la phase d'ouverture de session, l'application réceptrice (61) alloue des blocs de mémoire supplémentaires (65), destinés au transfert par copie. 6. Procédé selon l'une quelconque des revendications 4 à 5, caractérisé en ce que l'espace de mémoire partagée (60) comprend: une table des adresses virtuelles (602) décrivant l'espace virtuel réservé pour le mappage, une queue de réception (603), un compteur (604) comptabilisant le nombre de pages mappées, et une table de hashage (601) pour la gestion des espaces libres résultant des transferts par mappage. 7. Procédé selon la revendication 6, caractérisé en ce que la table de hashage (601) est adaptée à mémoriser les espaces libres des pages physiques (640) mappées sur des pages virtuelles (630) en les triant suivant leur taille, chaque entrée de la table de hashage (601) définissant une taille minimale d'un espace libre, les espaces libres dans les pages physiques (640) correspondant à une même entrée (i) de la table de hashage (601) étant organisés en liste chaînée (630i). 8. Procédé selon les revendications 5 et 7, caractérisé en ce que dans la phase d'ouverture de session, l'application réceptrice (61) décompose les blocs de mémoire supplémentaires (65) en sous-blocs (650), qu'elle insère dans la table de hashage (601) à l'entrée adéquate en fin de liste chaînée (630i) correspondante. 9. Procédé selon l'une quelconque des revendications 6 à 8, caractérisé en ce que la table d'adresses virtuelles (602) est organisée sous la forme d'une liste de descripteurs (6020), un statut inséré dans le descripteur (6020) indiquant si la page (630) correspondant à cette adresse virtuelle est en cours d'utilisation ou non. 10. Procédé selon l'une quelconque des revendications 6 à 9, caractérisé en ce que la queue de réception (603), utilisée pour communiquer à l'application réceptrice (61) I'emplacement o les données ont été transférées, est organisée sous la forme d'une table circulaire de descripteurs (6030) parcourus en ordre premier arrivé premier sorti "FIFO". 11. Procédé selon la revendication 10, caractérisé en ce que les descripteurs (6030) de la queue de réception (603) contiennent au moins les informations suivantes: - Pointeur(s) sur l'emplacement mémoire contenant les données, - Taille(s) des données transférées, - Bit assurant l'exclusion mutuelle sur le descripteur (6030), celui-ci est utilisé pour indiquer quelle est l'application de l'émetteur ou du récepteur, propriétaire du descripteur (6030) à un instant donné. 12. Procédé selon l'une quelconque des revendications 6 à 9, caractérisé en ce que la queue de réception (603), utilisée pour communiquer à l'application réceptrice (61) l'emplacement o les données ont été transférées, est organisée sous la forme d'une liste de descripteurs (6030) chaînés permettant l'insertion d'un nouveau descripteur (6030) en n'importe quel point de la liste 13. Procédé selon la revendication 12, caractérisé en ce que les descripteurs (6030) de la queue de réception (603) contiennent au moins les informations suivantes: - Pointeur(s) sur l'emplacement mémoire contenant les données, - Taille(s) des données transférées, - Bit assurant l'exclusion mutuelle sur le descripteur (6030), celui-ci est utilisé pour indiquer quelle est l'application de l'émetteur ou du récepteur, propriétaire du descripteur (6030) à un instant donné, - Au moins un pointeur de chaînage vers le descripteur (6030) suivant et/ou le descripteur (6030) précédent. 14. Procédé selon l'une quelconque des revendications 9 à 11, caractérisé en ce que chaque page physique (640) utilisée pour le transfert de données comprend un entête en début de page, comprenant: - un pointeur sur la page physique (640) suivante (pg_next) permettant de chaînée les pages physiques (640) entre elles, - un compteur de référence (pktcpt), indiquant le nombre de paquets de données situés sur la page physique (640), - la taille de l'espace libre (avail_sz) dans la page physique (640), - un offset (availoff) sur le prochain espace libre de la page physique (640), - et un offset (dataoff) sur le début de l'espace contenant les données. 15. Procédé selon l'une quelconque des revendications 4 à 14, caractérisé en ce que la phase d'ouverture de session comporte en outre une étape de négociation entre, d'une part, I'application réceptrice 61, et, d'autre part, I'application émettrice 62 ou un serveur de connexion auprès duquel est enregistrée l'application émettrice 62, afin d'autoriser la connexion et de fixer la taille des différents groupes de blocs de mémoire tampon. 16. Procédé selon l'une quelconque des revendications 3 à 15, caractérisé en ce que la phase de transfert comporte une étape de choix du mode de transfert mémoire par mappage ou par copie. 17. Procédé selon la revendication 16, caractérisé en ce que si le choix est une copie des données à transférer, la phase de transfert comporte des étapes de C1 - recherche d'un bloc de mémoire libre (FB) de taille supérieure ou égale à la taille des données à transférer (N) dans la table de hashage (601), C2 - retrait du bloc de mémoire libre (FB) de la liste chaînée (630i) pointée par l'entrée (i) trouvée dans la table de hashage (601), C3 - copie des données à transférer dans le bloc de mémoire libre (FB) ainsi alloué, C4 - si le bloc mémoire (FB) appartient à une page physique (640) précédemment mappée suivant l'invention, mise à jour de l'entête de la page (640), C5 - initialisation et insertion d'un nouveau descripteur (6030) dans la queue de réception (603). 18. Procédé selon la revendication 17, caractérisé en ce que il comporte en outre une étape d'insertion du bloc d'espace encore libre (espace restant dans le bloc de mémoire libre FB après y avoir copié les donnees de taille N) dans la table de hashage (601) pour une utilisation ultérieure. 19. Procédé selon l'une quelconque des revendications 16 à 18, caractérisé en ce que si le choix (de transfert pour la page mémoire MP) est un mappage, la phase de transfert comporte des étapes de: M1 recherche d'une adresse virtuelle libre FA dans la table d'adresses virtuelles (602) située dans l'espace de mémoire partagé (60), M2 modification du statut de l'adresse virtuelle FA ainsi trouvée, pour indiquer que l'adresse est utilisée, M3 - mappage de la page physique à l'adresse virtuelle FA trouvée, et incrémentation du compteur (604) du nombre de pages mappées, M4 - mise à jour de l'entête de la page, M5 initialisation et insertion d'un nouveau descripteur (6030) dans la queue de réception (603). 20. Procédé selon la revendication 19, caractérisé en ce qu'il comporte en outre une étape d'insertion du bloc d'espace encore libre FB2 (espace non utilisé dans le bloc de mémoire pointé par l'adresse virtuelle FA après y avoir mappé la page mémoire MP) dans la table de hashage (601) pour une utilisation ultérieure. 21. Procédé selon l'une quelconque des revendications 3 à 20 sauf 5 et 8, caractérisé en ce que la phase de libération de ces blocs de mémoire tampon de l'application réceptrice (61) comporte les étapes suivantes: L1mise à jour de l'entête de la page contenant le bloc de mémoire tampon, L2 - si le nombre de paquets de données situés sur la page vaut 0, et si le prochain espace libre de la page vaut 0, alors la page peut être démappée et rendue à l'application émettrice (62). 22. Procédé selon la revendication 21, caractérisé en ce que l'étape de démappage (L2) comporte des sous étapes de: L2.1 - démappage de la page physique (640) qui est replacée dans le groupe des pages libres (64) de l'application émettrice (62), et décrémentation du compteur (604), L2.2 modification du statut du descripteur (6020) correspondant à l'adresse virtuelle utilisée dans l'application réceptrice (61) pour marquer cette adresse comme à nouveau disponible pour un autre mappage. 23. Procédé selon l'une quelconque des revendications 3 à 22, caractérisé en ce que l'étape de fermeture de session comporte la libération des structures de données mises en place dans l'étape d'ouverture de la session. 24. Procédé selon l'une quelconque des revendications 1 à 23, caractérisé en ce que il constitue une extension du procédé de gestion de mémoire virtuelle de l'ordinateur. 25. Dispositif de transfert mémoire entre applications émettrice (62) et réceptrice (61) exécutées sur un ordinateur comportant un système d'exploitation et disposant de moyens adaptés à la réalisation de transfert mémoire par copie ou par mappage, caractérisé en ce qu'il comporte un moyen d'allocation, lors d'un transfert par copie, d'au moins une partie de l'espace inutilisé dans un ensemble de pages physiques mappées (640) incomplètement utilisées lors de précédents transferts mémoire. 26. Dispositif selon la revendication 25, caractérisé en ce qu'il comporte des moyens d'effectuer: un premier choix entre copie ou mappage selon un critère prédéterminé, et, dans le cas de choix de copie, un second choix entre: - une copie de type classique dans un bloc de mémoire tampon de l'application réceptrice (61), - ou une copie dans au moins une partie de l'espace inutilisé dans un ensemble de pages mappées incomplètement utilisées lors de précédents transferts mémoire. 27. Dispositif selon la revendication 25, caractérisé en ce que le dispositif de transfert mémoire comporte outre des moyens de transfert de données dans des blocs de mémoire tampon de l'application réceptrice (61) par copie ou mappage, des moyens de libération de ces blocs de mémoire tampon, d'ouverture de session et de fermeture de session. 28. Dispositif de transfert mémoire selon la revendication 27, caractérisé en ce qu'il comprend des moyens permettant à l'application réceptrice (61): de réserver un espace de mémoire virtuelle (63) contigu de son espace d'adressage virtuel sur lequel seront mappées les pages physiques (640) transférées, de mettre en place un espace de mémoire partagée (60) avec l'application émettrice (62). 29. Dispositif selon la revendication 28, caractérisé en ce qu'il comprend des moyens permettant à l'application réceptrice (61) d'allouer des blocs de mémoire supplémentaires (65), destinés au transfert par copie. 30. Dispositif selon la revendication 24, caractérisé en ce que l'espace de mémoire partagée (60) comprend: une table des adresses virtuelles (602) décrivant l'espace virtuel réservé pour le mappage, une queue de réception (603), un compteur (604) comptabilisant le nombre de pages mappées, et une table de hashage (601) pour la gestion des espaces libres résultant des transferts par mappage. 31. Dispositif selon la revendication 30, caractérisé en ce que la table de hashage (601) permet de mémoriser les espaces libres des pages physiques (640) mappées sur des pages virtuelles (630) en les triant suivant leur taille, chaque entrée de la table de hashage (601) définissant une taille minimale d'un espace libre, les espaces libres dans les pages physiques (640) correspondant à une même entrée (i) de la table de hashage (601) étant organisés en liste chaînée (630i). 32. Dispositif selon les revendications 29 et 31, caractérisé en ce qu'il comprend des moyens permettant à l'application réceptrice (61) dans la phase d'ouverture de session, de décomposer les blocs de mémoire supplémentaires (65) en sous-blocs (650), et de les insérer dans la table de hashage (601) à l'entrée adéquate en fin de liste chaînée (630i) correspondante. 33. Dispositif selon l'une quelconque des revendications 25 à 26, caractérisé en ce que la table d'adresses virtuelles (602) est organisée sous la forme d'une liste de descripteurs (6020), un statut inséré dans le descripteur (6020) indiquant si la page (630) correspondant à cette adresse virtuelle est en cours d'utilisation ou non. 34. Dispositif selon l'une quelconque des revendications 25 à 27, caractérisé en ce que la queue de réception (603), utilisée pour communiquer à l'application réceptrice (61) I'emplacement o les données ont été transférées, est organisée sous la forme d'une table circulaire de descripteurs (6030) parcourus en ordre premier arrivé premier sorti "FIFO". 35. Dispositif selon la revendication 28, caractérisé en ce que les descripteurs (6030) de la queue de réception (603) contiennent au moins les informations suivantes: - Pointeur(s) sur l'emplacement mémoire contenant les données - Taille(s) des données transférées - Bit assurant l'exclusion mutuelle sur le descripteur (6030), celui-ci est utilisé pour indiquer quelle est l'application de l'émetteur ou du récepteur, propriétaire du descripteur (6030) à un instant donné. 36. Dispositif selon l'une quelconque des revendications 30 à 33, caractérisé en ce que la queue de réception (603), utilisée pour communiquer à l'application réceptrice (61) I'emplacement o les données ont été transférées, est organisée sous la forme d'une liste de descripteurs (6030) chaînés permettant l'insertion d'un nouveau descripteur (6030) en n'importe quel point de la liste 37. Dispositif selon la revendication 36, caractérisé en ce que les descripteurs (6030) de la queue de réception (603) contiennent au moins les informations suivantes: - Pointeur(s) sur l'emplacement mémoire contenant les données, - Taille(s) des données transférées, - Bit assurant l'exclusion mutuelle sur le descripteur (6030), celui-ci est utilisé pour indiquer quelle est l'application de l'émetteur ou du récepteur, propriétaire du descripteur (6030) à un instant donné, - Au moins un pointeur de chaînage vers le descripteur (6030) suivant et/ou le descripteur (6030) précédent. 38. Dispositif selon l'une quelconque des revendications 27 à 29, caractérisé en ce que chaque page physique (640) utilisée pour le transfert de données comprend un entête en début de page, comprenant: - un pointeur sur la page physique (640) suivante (pg_next) permettant de chaînée les pages physiques (640) entre elles, - un compteur de référence (pktcpt), indiquant le nombre de paquets de données situés sur la page physique (640), - la taille de l'espace libre (avail_sz) dans la page physique (640), - un offset (availoff) sur le prochain espace libre de la page physique (640), - et un offset (dataoff) sur le début de l'espace contenant les données. 39. Dispositif selon l'une quelconque des revendications 24 à 30, caractérisé en ce qu'il comporte en outre une moyen de négociation entre, d'une part, l'application réceptrice 61, et, d'autre part, l'application émettrice 62 ou un serveur de connexion auprès duquel est enregistrée l'application émettrice 62, afin d'autoriser la connexion et de fixer la taille des différents groupes de blocs de mémoire tampon. 40. Dispositif de transfert mémoire selon l'une quelconque des revendications 25 à 39, caractérisé en ce qu'il comprend des moyens de choix du mode de transfert mémoire par mappage ou par copie. 41. Dispositif de transfert mémoire selon la revendication 40, caractérisé en ce qu'il comprend des moyens de: Cl - rechercher, dans la table de hashage (601), un bloc de mémoire libre (FB) de taille supérieure ou égale à la taille des données à transférer (N), C2 - retirer le bloc de mémoire libre (FB) de la liste chaînée (630i) pointée par l'entrée trouvée dans la table de hashage (601), C3 - copier les données à transférer dans le bloc de mémoire libre (FB) ainsi alloué, C4 - si le bloc mémoire (FB) appartient à une page physique (640) précédemment mappée suivant l'invention, mettre à jour l'entête de la page (640), C5 - initialiser et insérer un nouveau descripteur (6030) dans la queue de réception (603). 42. Dispositif de transfert mémoire selon l'une quelconque des revendications 40 à 41, caractérisé en ce qu'il comprend des moyens de: M1 - rechercher une adresse virtuelle libre (FA) dans la table d'adresses virtuelles (602) située dans l'espace de mémoire partagé (60), M2 modifier le statut de l'adresse virtuelle (FA) ainsi trouvée, pour indiquer que l'adresse est utilisée, M3 - mapper la page physique à l'adresse virtuelle (FA) trouvée, M4 - mettre à jour l'entête de la page, M5 - initialiser et insérer un nouveau descripteur (6030) dans la queue de réception (603). 43. Dispositif de transfert mémoire selon l'une quelconque des revendications 41 à 42, caractérisé en ce qu'il comprend des moyens d'insérer un bloc d'espace encore libre dans la table de hashage (601) pour une utilisation ultérieure. 44. Dispositif de transfert mémoire selon l'une quelconque des revendications 27 à 43 sauf 29 et 32, caractérisé en ce qu'il comprend des moyens de: L1 - mettre à jour l'entête de la page contenant le bloc de mémoire tampon, L2 - si le nombre de paquets de données situés sur la page vaut 0, et si le prochain espace libre de la page vaut 0, démapper la page et la restituer à l'application émettrice (62). 45. Dispositif selon la revendication 44, caractérisé en ce qu'il comporte en outre des moyens de: L2.1 - démappage de la page physique (640) qui est replacée dans le groupe des pages libres (64) de l'application émettrice (62), et décrémentation du compteur (604), L2.2 - modification du statut du descripteur (6020) correspondant à l'adresse virtuelle utilisée dans l'application réceptrice (61) pour marquer cette adresse comme à nouveau disponible pour un autre mappage. 46. Dispositif selon l'une quelconque des revendications 27 à 45, caractérisé en ce qu'il comporte des moyens d'effectuer la libération des structures de données mises en place dans l'étape d'ouverture de la session. 47. Dispositif selon l'une quelconque des revendications 25 à 46, caractérisé en ce que il constitue une extension du gestionnaire de mémoire virtuelle de l'ordinateur (10). 48. Téléphone, caractérisé en ce que il comporte un dispositif selon l'une quelconque des revendications 25 à 47. 49. Appareil photographique, caractérisé en ce que il comporte un dispositif selon l'une quelconque des revendications 25 à 47. 50. Imprimante, caractérisée en ce qu'elle comporte un dispositif selon l'une quelconque des revendications 25 à 47. 51. Scanner, caractérisé en ce que il comporte un dispositif selon l'une quelconque des revendications 25 à 47. 52. Caméra, caractérisée en ce qu'elle comporte un dispositif selon l'une quelconque des revendications 25 à 47. 53. Ordinateur, caractérisé en ce que il comporte un dispositif selon l'une quelconque des revendications 25 à 47. 54. Télécopieur, caractérisé en ce que il comporte un dispositif selon l'une quelconque des revendications 25 à 47. 55. Téléviseur, caractérisé en ce que il comporte un dispositif selon l'une quelconque des revendications 25 à 47. 56. Lecteur audio/vidéo, caractérisé en ce que il comporte un dispositif selon l'une quelconque des revendications 25 à 47.