FR 3093575 A1 20200911 FR 1902193 A 20190304 Description Titre de l'invention : TRAITEMENT DE DONNÉES DIS- TRIBUÉES [0001] La présente invention concerne le traitement de données dans un environnement in- formatique distribué comprenant au moins un serveur et une pluralité de clients comprenant au moins un premier client et un deuxième client. Plus spécifiquement, elle porte sur la propagation de données parmi les clients tels que les clients d'un réseau pair à pair. [0002] L'éventail croissant des technologies Web et des systèmes informatiques distribués au cours des dernières décennies a conduit à la nécessité de distribuer des données qui ne sont valables que pour une durée limitée. Par conséquent, unc optimisation supplémentaire de la distribution de données sur un réseau est attendue pour veiller à ce que les serveurs et les clients ne reçoivent et n'envoient que des données valides, par exemple des données qui ne sont pas obsolètes, éliminant ainsi la transmission et le traitement de données invalides et réduisant la charge de travail des serveurs et des clients en termes de trafic sur le Web. Au cours des dernières années, certaines approches ont été adoptées en ce sens. [0003] US 7,509,372 B2 décrit un système pair à pair, dans lequel un premier noeud pair (client) envoie une demande de contenu à un deuxième noeud pair, qui a stocké le contenu demandé. En fonction d'un état de surcharge du deuxième noeud pair (serveur), le deuxième noeud pair (serveur) renvoie le contenu demandé au premier noeud pair ou renvoie unc liste avec d'autres noeuds pairs, auprès desquels le contenu demandé peut être extrait. Le premier noeud pair (client) peut alors récupérer le contenu demandé auprès de l'un des autres noeuds pairs. [0004] US 8,145,845 B2 porte sur l'extraction de données d'un protocole LDAP (Light-weight Directory Access Protocol, ou Protocole ultra-léger d'accès aux répertoires) qui peut être appliqué à un système pair à pair. Si les données demandées sont présentes, valides et qu'un temps de vie (TTL, ou Ti me-to-live) pour l'attribut LDAP ou l'index LDAP n'est pas arrivé à expiration, les données peuvent être extraites d'un cache d'attribut virtuel et renvoyées au client demandeur, au serveur d'application ou à l'opération LDAP. Un indicateur TTL est utilisé pour déterminer si un élément de données associé dans un cache, un index, un cache virtuel, un index virtuel, une structure de données similaire ou d'index virtuel est précis ou fiable. Si l'attribut virtuel est indexé, mais que le TTL de l'index est arrivé à expiration ou a été autrement invalidé, alors un signal peut être envoyé pour lancer la reconstruction de l'index. [0005] US 2002/0120710 Al décrit un client qui envoie une demande pour un ensemble de 2 contenu dynamique à un serveur. Le serveur accède ensuite aux informations associées à une version en cache du contenu et détermine si le contenu est toujours valide. Si le contenu n'est pas valide, une version mise à jour du contenu est extraite et envoyée au client. [0006] US 2003/0061272 Al porte sur un cache de proxy résidant dans un environnement réseau et recevant une demande pour une ressource particulière. Si le cache du proxy détermine que le document ne réside pas dans le cache ou que le document n'est peut-être pas valide, le cache du proxy construit alors une demande adressée à un serveur qui est la source du document et réclame une copie du document ou demande si la version en cache est valide. [0007] Selon un premier aspect, un procédé de traitement de données dans un envi- ronnement informatique distribué comprenant au moins un serveur et une pluralité de clients comprenant au moins un premier client et un deuxième client est fourni. Le procédé consiste à envoyer, au premier client, une première demande de données au deuxième client, à recevoir une première réponse du deuxième client en tant que réponse à la première quête, à déterminer une probabilité de validité des données demandées par la première demande et disponibles auprès du deuxième client sur la hase d'une indication de validité incluse dans la première réponse indiquant une probabilité que les données demandées au deuxième client sont invalides et, en réponse à la détermination que les données demandées par la première demande et disponibles auprès du deuxième client sont vraisemblablement invalides, à envoyer une deuxième demande au serveur pour obtenir les données du serveur et recevoir les données du serveur dans une deuxième réponse à la deuxième demande. [0008] Selon un autre aspect, la deuxième réponse comprend une indication de validité indiquant une probabilité que les données demandées au serveur soient invalides. Les données reçues du serveur associées à l'indication de validité incluse dans la deuxième réponse sont stockées. [0009] Selon un autre aspect encore, la détermination de la probabilité de validité des données demandées par la première demande et disponibles auprès du deuxième client consiste à estimer un temps de réception des données du deuxième client sur la base d'une taille des données demandées incluses dans la première réponse et d'une largeur de bande donnée d'une connexion au deuxième client. La probabilité de validité des données est déterminée au moment estimé de leur réception. [0010] Selon un autre aspect encore, le procédé consiste, en réponse à la détermination que les données demandées par la première demande et disponibles auprès du deuxième client sont vraisemblablement valides, à récupérer les données du deuxième client si les données n'étaient pas déjà incluses dans la première réponse, et à stocker les données récupérées associées à l'indication de validité incluse dans la première 3 réponse. [0011] Selon d'autres aspects, le premier client reçoit une troisième demande de données d'un troisième client et envoie une troisième réponse au troisième client en réponse à la troisième demande, la troisième réponse comprenant l'indication de validité associée aux données. [0012] Selon un autre aspect encore, le premier client évalue, en réponse à la réception de la troisième demande, la probabilité que les données demandées soient invalides selon l'indication de validité stockée associée aux données, et inclut, en réponse à la détermination que les données demandées sont vraisemblablement encore valides, les données demandées par le troisième client dans la troisième réponse. [0013] Selon un autre aspect, l'indication de validité comprend un horodatage tO indiquant une heure à laquelle les données demandées ont été générées. [0014] Selon un autre aspect, l'indication de validité comprend en outre un taux de validité C des données demandées modélisées par un modèle probabiliste. [0015] Selon un autre aspect encore, la détermination l'invalidité potentielle des données demandées consiste à calculer une valeur de probabilité de validité donnée par [Math. 1] E? -c(1 - t o) dans laquelle t représente l'heure actuelle ou l'heure estimée de réception des données, et comparer la valeur de probabilité de validité avec une valeur seuil donnée, et déterminer que les données demandées sont vraisemblablement invalides si la valeur de probabilité de validité est inférieure à la valeur seuil donnée. [0016] Selon un autre aspect, une machine informatique est fournie, la machine informatique agissant en tant que premier client pour traiter des données dans un environnement informatique distribué comprenant au moins un serveur et une pluralité de clients comprenant au moins le premier client et un deuxième client, la machine informatique étant prévue pour exécuter le procédé de l'un des aspects précités. [0017] Selon un autre aspect, un produit de programme informatique est fourni, le produit de programme informatique comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour exécuter les étapes du procédé selon l'un quelconque des aspects susmentionnés lorsque ledit programme est exécuté sur un ordinateur. [0018] Les mécanismes actuels seront décrits en se référant aux figures qui les ac- compagnent. Des numéros de référence similaires indiquent généralement des éléments identiques ou fonctionnellement similaires : [0019] [fig.1] est une représentation schématique d'un environnement informatique distribué tel que décrit dans les présentes. [0020] [fig.2] est un graphique séquentiel de messages selon certains modes de réalisation. [0021] [fig.3] montre l'heure de réception en unités arbitraires (par exemple en secondes) en fonction de la taille des données transmises en unités arbitraires (par exemple en secondes) selon certains modes de réalisation. [0022] [fig.4] montre un format de données possible pour la première réponse selon certains modes de réalisation. [0023] [fig.5] montre un format de données possible pour la première réponse selon certains modes de réalisation supplémentaires. [0024] [fig.6] montre dans un graphique de flux les scénarios possibles à disposition du premier client pour la réception des données selon certains modes de réalisation. [0025] [fig.7] montre un scénario possible lorsque les données demandées sont incluses dans la première réponse selon certains modes de réalisation. [0026] [fig.8] est un graphique séquentiel de messages selon un autre mode de réalisation. [0027] [fig.9] est un graphique séquentiel de messages selon un mode de réalisation supplé- mentaire. [0028] [fig.10] montre des fonctions exemplaires de la diminution probable de l'exactitude avec le temps selon certains modes de réalisation. [0029] [fig.11] est une représentation schématique des composants internes d'une machine informatique selon certains modes de réalisation. [0030] Le champ d'application croissant des technologies du Web et des systèmes infor- matiques distribués a abouti au problème de la transmission efficace de données possédant des validités limitées dans le temps sur des systèmes pair à pair. En particulier, il convient de veiller à ce que les clients demandant des données et qui font partie d'un environnement distribué reçoivent des données valides, afin d'éviter toute incohérence des données dans l'environnement distribué. [0031] Par exemple, l'invalidité des données peut survenir dans des données sélectionnées et copiées à partir de données sous-jacentes stockées dans une base de données lorsque le contenu de la base de données subit des modifications, par exemple en modifiant les données sous-jacentes à travers des mises à jour des données. Les données copiées à partir d'un ensemble sélectionné de données sous-jacentes peuvent alors ne plus être identiques à l'ensemble de données sous-jacentes correspondant mis à jour, une fois la mise à jour des données dans la base de données effectuée. Il en résulte que les données copiées deviennent obsolètes et par conséquent invalides, et la distribution ultérieure sur les réseaux, couplée au traitement par les clients, entraîne une incohérence des données chez le client de l'environnement distribué. [0032] Des exemples de données devenant invalides après une certaine durée de vie sont les projets de circuits électroniques pour les équipements informatiques tels que les téléphones portables, qui peuvent changer lorsqu'une nouvelle version du téléphone portable est sortie, et les normes techniques, telles que les spécifications 3GPP, qui sont révisées avec le temps et qui existent donc en plusieurs sorties et versions. [0033] La FIG. 1 illustre un système informatique distribué tel qu'un réseau pair à pair, tel qu'il est utilisé dans les présentes de manière schématique. Le système informatique comprend plusieurs clients 1, un serveur 4 et plusieurs interfaces de communication 6. Dans certains modes de réalisation, le serveur 4 et les clients 1 sont des machines informatiques individuelles telles que des ordinateurs personnels, des postes mobiles tels que des ordinateurs portables ou des tablettes, des smartphones, et autres articles similaires, et également dans certains modes de réalisation, des machines plus puissantes telles que des serveurs d'application de base de données, des systèmes de base de données distribués comprenant respectivement plusieurs machines interconnectées, des centres de données, etc. Dans certains modes de réalisation, le serveur 4 peut être une machine similaire aux clients 1, tandis que dans d'autres modes de réalisation, le serveur 4 est plus puissant que les clients 1. Dans un mode de réalisation, le serveur 4 et les clients 1 sont des centres de données, où les clients 1 répliquent les données détenues par le centre de données du serveur et mettent à disposition les données, par exemple dans d'autres parties géographiques du monde (par exemple sur d'autres continents) au-delà de l'emplacement géographique du centre de données du serveur. [0034] Le serveur 4 et les clients 1 peuvent être constitués de plusieurs machines matérielles en fonction des exigences de performance. Le serveur 4 et les clients 1, par exemple, sont des machines matérielles fixes ou mobiles comprenant des machines informatiques 100, comme illustré dans la figure FIG. 11 et/ou en tant que systèmes spécialisés tels que les systèmes embarqués conçus à des fins techniques particulières, et/ ou en tant que composants logiciels fonctionnant sur une machine informatique générale ou spécialisée (par exemple un serveur Web et des clients Web). [0035] Le serveur 4 et les clients 1 sont interconnectés par les interfaces de communication 6. Chacune des interfaces 6 utilise un réseau local (LAN) filaire ou sans fil, ou un réseau métropolitain (MAN) filaire ou sans fil, ou un réseau étendu (WAN) filaire ou sans fil comme Internet ou une combinaison des technologies de réseau susmentionnées et mises en oeuvre par tous les protocoles de communication et de réseau appropriés. [0036] Dans un scénario de distribution exemplaire de données devenant potentiellement invalides après une certaine durée de vie, le serveur 4 détient une base de données relationnelle SQL (Structured Query Language, ou Langage de requête structuré) et reçoit une demande SQL d'un premier client 1 (qui est également désigné comme client 1A, voir les FIG. 2 et suivantes) pour récupérer certaines données de la base de données SQL, comme une vue "tableAB" basée sur deux tables de base de données, "tableA" et "tableB", contenant des données sous-jacentes. Après la réception de la demande du premier client 1A, le serveur 4 identifie les tables de base de données pertinentes de la 6 hase de données SQL. Ensuite, le serveur 4 reçoit les tables de base de données identifiées et stocke les tables de hase de données, par exemple dans le système de stockage principal du serveur 4. [0037] Le serveur 4 poursuit le traitement des tables de hase de données récupérées et crée des sous-ensembles de tables de hase de données à partir des tables de hase de données en utilisant la commande SQL CREATE VIEW (CRÉER VUE). Les sous-ensembles de tables de hase de données forment de nouveau des tables de base de données et sont communément appelés vues et servent de hase à la création de nouvelles tables de hase de données en utilisant des instructions SQL telles que JOIN (RELIER), LEFT OUTER JOIN (RELIER EXTERNE GAUCHE), RIGHT AFTER JOIN (RELIER EXTERNE DROIT) etc. Ensuite, à l'aide d'une instruction SQL telle que SELECT (SÉLECTIONNER), le serveur 4 crée les données demandées par le client 1 A. En outre, les données peuvent être triées selon les critères définis dans la demande du client 1 A. [0038] Pour préciser de manière plus amplement l'exemple, la table de hase de données "tableA" peut résider sur une première base de données SQL et la table de hase de données "tableB" peut résider sur une deuxième base de données SQL. Le serveur 4 reçoit la "tableA" et la "tableB" et les stocke dans le système de stockage principal ou dans le cache du serveur 4. Après le décodage, l'élimination des erreurs et la définition d'un format commun comme décrit dans les exemples ci-dessus, le serveur 4 poursuit le traitement en utilisant les instructions SQL suivantes : CRÉER VUE vueA (données1A, données2A) AS (EN TANT QUE) SÉLECTIONNER données1A, données 2A FROM (À PARTIR DE) tableA CRÉER VUE vueB (données1B, données2B) EN TANT QUE SÉLECTIONNER données1B, données2B À PARTIR DE tableB ; CRÉER VUE tableAB EN TANT QUE SÉLECTIONNER données1C, données2C, données2A, données 2A, données3C, données2B à partir de la tableC, vueA, vueB où tableC.données1C = vueA.données lA et tableC.données2C = vueB.données1B [0039] Enfin, les données stockées dans la vue "tableAB" sont envoyées, éventuellement après un post-traitement tel que la compression, au premier client lA qui a demandé les données. [0040] Par la suite, le premier client lA reçoit une demande de vue "tableAB" d'un deuxième client 1 (également appelé client 1B, voir les FIG. 2 et suivantes) et envoie "tableAB" au deuxième client 1B. Encore plus tard, le deuxième client 1B peut également recevoir lui-même une nouvelle demande d'un troisième client 1 (qui est 7 également désigné sous le nom de client 1C, voir FIG. 9) et envoie la vue "tahleAB" au troisième client 1C. D'autres cascades de ce processus distribuent la vue "tahleAB" sur le réseau. [0041] Pendant que la vue "tahleAB" est distribuée sur le réseau, les données sous-jacentes stockées à l'origine dans les tables "tableA" et/ou "tahleB" de la hase de données sont remplacées par de nouvelles données sous-jacentes, c'est-à-dire que les données de la vue "tahleAB" sont mises àjour. La même demande SQL du premier client lA rapporterait dès lors une vue différente "tableAB UPDATED (MISE À JOUR)" construite sur les données différentes / mises à jour. Par conséquent, la vue "tableAB" est devenue obsolète. [0042] Toutefois, dans le cas où ce client lA ne renvoie pas la demande SQL sus- mentionnée, les autres clients ne recevront pas la vue "tahleAB_ MISE À JOUR" construite sur les données valides mises à jour. Au lieu de cela, la vue "tableAB" avec les données invalides continue d'être distribuée aux autres clients du réseau. [0043] De plus, la mise à jour des données sous-tendant la vue pourrait introduire des inco- hérences dans les données. Par exemple, lorsque le premier client l A renvoie effectivement la demande SQL susmentionnée et reçoit ensuite la vue "tableAB MISE À JOUR", le premier client l A détient la version mise àjour de la vue. Par conséquent, toute demande d'autres clients au premier client lA pour la vue "tableAB" serait dès lors traitée par "tableAB MISE À JOUR" qui se propage à travers le réseau. Cependant, d'autres clients tels que le deuxième client IB et le troisième client 1C conservent toujours l'ancienne vue "tableAB" de la version obsolète et continueraient dès lors à distribuer cette version obsolète en réponse aux demandes. Par conséquent, cela aboutit à une distribution parallèle de la vue mise à jour "tableAB_ MISE À JOUR" construite sur des données valides ainsi que de la vue obsolète "tableAB" construite sur des données invalidées. Si les clients forment, par exemple, une base de données distribuée, des versions incohérentes des mêmes données peuvent apparaître dans cette base de données. [0044] Il s'agit donc de mettre en place des mécanismes garantissant qu'un client demeurant sur un réseau tel qu'un réseau pair à pair ou une base de données distribuée et demandant des données à un autre client reçoit des données valides d'une manière efficace. Il s'agit également de s'abstenir de surcharger les serveurs tout en améliorant la cohérence des données dans l'environnement distribué. [0045] En général, ces objets sont traités en associant les informations de validité aux données détenues par les clients et en permettant aux clients demandeurs de déterminer si les données demandées à d'autres clients et détenues par eux sont vraisemblablement toujours valides. Plus précisément, une indication de validité associée aux données est fournie au client demandeur de données. Par exemple, l'indication de validité peut 8 comprendre une valeur de probabilité de validité calculée ou calculable (présentée de manière plus détaillée ci-dessous). Les données demandées sont alors considérées comme invalides par le client demandeur lorsqu'il détermine que la valeur de la pro-habilité de validité associée aux données demandées tombe sous une valeur seuil donnée. Le calcul de la valeur de probabilité de validité peut inclure, par exemple, le calcul de l'âge actuel des données demandées, en fonction d'une date de génération et d'une heure actuelle. [0046] Un graphique séquentiel de messages pour un mécanisme général selon certains modes de réalisation est présenté dans la FIG. 2. Un premier client lA envoie une première demande 10 pour des données (par exemple la vue "tableAB" présentée ci-dessus) à un deuxième client 1B et reçoit une première réponse 11 du deuxième client 1B en réponse à la première demande 10. La première réponse 11 comprend une indication de validité indiquant une probabilité que les données demandées par le premier client lA au deuxième client 1B soient invalides. Par la suite, le premier client lA détermine 12 une probabilité de validité des données demandées par la première demande 10 et disponibles auprès du deuxième client 1B en fonction de l'indication de validité incluse dans la première réponse 11. Si la détermination 12 indique que les données demandées par la première demande 11 et disponibles auprès du deuxième client 1B sont vraisemblablement invalides, le premier client lA envoie une deuxième demande 13A au serveur 4 pour obtenir les données du serveur 4, car le serveur 4 détient vraisemblablement une version actuellement valide des données demandées. En réponse à la deuxième demande 13A, le premier client lA reçoit les données du serveur 4 dans une deuxième réponse 14A. [0047] En se référant à l'exemple spécifique ci-dessus, le deuxième client 1B peut détenir la vue de la version obsolète "tableAB". Selon l'indication de validité incluse dans la première réponse 11, le premier client lA calcule une forte probabilité que la vue "tableAB" ne soit plus valide. Le premier client lA se tourne ensuite vers le serveur 4 au moyen de la deuxième demande 13A et reçoit la vue de la version actuellement valide "tableAB_MISE À JOUR" à travers la deuxième réponse 14A. [0048] Cela va au-delà de la simple redirection des demandes de données dans les réseaux pair à pair, décrite par exemple dans le cas US 7,509,372 B2, où les demandes de données d'un premier noeud pair (client) vers un deuxième noeud pair (serveur) sont redirigées vers d'autres noeuds pairs si le deuxième noeud est en état de surcharge. Alors que le cas US 7,509,372 B2 enseigne la gestion de la charge, les mécanismes actuels augmentent la cohérence des données dans un environnement distribué en permettant aux clients de fournir des indications de validité pour les données demandées, un calcul de probabilité de validité chez un client demandant des données et le renvoi à une source de données originale (par exemple le serveur 4) lorsque la probabilité 9 d'invalidité est élevée (c'est-à-dire supérieure à un certain seuil). [0049] Dans certains modes de réalisation, la deuxième réponse 14A comprend également une indication de validité indiquant une probabilité de validité des données demandées et extraites du serveur. 4. Le premier client lA stocke les données reçues du serveur 4 associées à l'indication de validité incluse dans la deuxième réponse 14A. Les données reçues du serveur 4 (par exemple la vue "tableAB MISE À JOUR") ont une date de génération, à partir de laquelle l'âge des données peut être calculé. Par conséquent, l'indication de validité incluse dans la deuxième réponse 14A pourrait indiquer la date de génération des données reçues. Ceci permet au premier client lA de fournir l'indication de validité des données extraites du serveur 4 à d'autres clients toujours demandeurs de données (par exemple un troisième client 1C, voir la FIG. 9) afin de permettre à ces autres clients de déterminer la probabilité de validité des données demandées. Pour reprendre l'exemple ci-dessus, le serveur 4 peut inclure la date de génération de la vue "tableAB MISE À JOUR" dans la deuxième réponse 14A au premier client 1A. Lorsqu'un troisième client 1C envoie une demande au premier lA pour la vue "tableAB MISE À JOUR", le premier client lA peut répondre avec la date de génération de la vue "tableAB MISE À JOUR" en premier, afin de permettre au troisième client 1C d'évaluer la probabilité de validité afin de décider s'il faut extraire la vue "tableAB MISE À JOUR" à partir du premier client lA ou extraire une autre version potentiellement actualisée de la vue "tableAB MISE À JOUR" à partir du serveur 4. [0050] Dans certains modes de réalisation, l'indication de validité comprend des in- formations sur la taille des données demandées au deuxième client 1B, l'heure de génération des données demandées, le taux de validité des données demandées ainsi que, facultativement, des informations sur la version des données demandées stockées chez le deuxième client 1B. [0051] Les indications relatives à la taille des données sont particulièrement avantageuses pour les données volumineuses demandées, dont la transmission du deuxième client 1B au premier client 1A pourrait prendre un laps de temps tel que la validité des données demandées pourrait diminuer sensiblement ou cesser. Par conséquent, dans ces modes de réalisation, le premier client lA tient compte de la taille des données indiquée afin de calculer la probabilité de validité au moment estimé de l'arrivée complète des données demandées provenant du deuxième client 1B. Plus spécifiquement, la détermination de la probabilité de validité 12 comprend l'estimation d'un temps de réception (complète) des données du deuxième client 1B en fonction de la taille des données demandées incluses dans la première réponse 11 et d'une largeur de bande donnée d'une connexion au deuxième client 1B. En outre, le premier client 1B calcule la probabilité de validité des données au moment estimé de leur réception. Par exemple, le premier client lA utilise l'heure de création pour calculer l'âge des données demandées au moment estimé de leur réception. Facultativement, le taux de validité et/ou les informations sur la version des données incluses dans l'indication de validité sont inclus dans le calcul de la probabilité de validité au moment estimé de la réception. La probabilité de validité est comparée à une valeur seuil donnée (par exemple, enregistrée au niveau du premier client 1 A) comme déjà indiqué ci-dessus. [0052] Cette détermination initiale 12 pourrait prendre beaucoup moins de temps que l'extraction des données (éventuellement volumineuses) et cc n'est qu'à partir de là que l'on peut déterminer que les données extraites sont peut-être obsolètes. Si le premier client lA déterminel 2, sur la hase des résultats du calcul, que les données demandées au deuxième client 1B sont potentiellement invalides au moment prévu de leur réception, le premier client lA peut envoyer la deuxième demande 13A au serveur 4 et obtenir les données du serveur 4. [0053] Dans certains modes de réalisation, la deuxième demande 13A comprend les mêmes données que dans la première demande, et elle comprend également des informations sur la validité des données demandées au deuxième client 1B (par exemple, la vue "tableAB"). Dans certains modes de réalisation, la deuxième demande 13A incluait la probabilité de validité des données demandées au deuxième client 1B (par exemple la vue "tableAB") telle que calculée par le premier client 1A. Dans certains modes de réalisation, la version des données stockées sur le deuxième client 1B (par exemple la vue "tableAB") est incluse dans la deuxième demande 13A. Dans certains modes de réalisation et non montrés dans la FIG. 2, le serveur 4 utilise cette probabilité de validité et/ou les informations sur la version pour examiner si le serveur 4 a stocké chez lui la même version des données demandées au deuxième client 1B, par exemple la vue "tableAB" ou une version mise à jour de la vue "tableAB", qui est dans le cas de l'exemple cité la vue "tableAB_MISE À JOUR". Si le serveur 4 a également stocké la même version des données demandées au deuxième client 1B (vue "tableAB"), alors le serveur 4 peut, dans certaines modes de réalisation, inclure dans la deuxième réponse 14A au premier client 1A les informations avançant qu'aucune version mise à jour et par conséquent plus aucune version valide des données demandées au deuxième client 1B n'est disponible, et que la recommandation faite au premier client 1A de demander les données / par exemple la vue "tableAB") forme le deuxième client 1B. Ce procédé n'aboutit qu'à la création d'une troisième réponse courte 16 et décharge donc le serveur 4 d'une charge de travail supplémentaire. [0054] La FIG. 3 visualise différents temps de réception par phases de 2 000 s en fonction de la taille des données transmises en Go (Gigaoctets) pour des données de taille identique. Plus une connexion entre deux clients, par exemple entre le premier client lA et le deuxième client 1B, dispose d'une largeur de bande importante, plus tôt le 11 premier client 1 A reçoit les données demandées (par exemple, la vue "tableAB"). en tant qu'exemple, il est présumé que la vue "tableAB" demandée par le premier client lA possède une taille de 1 Go, alors une bande passante de 0,5 Mo/s (Mo par seconde) permet au premier client lA de recevoir la vue "tableAB" en 2 000 s (ou environ 33 min, voir la courbe D de la HG). 3). Unc largeur de bande plus élevée, par exemple 1 Mo/s, permettrait au premier client l A de recevoir la vue "tableAB" en 1 000 secondes (soit environ 17 minutes, voir la courbe E de la figure FIG. 3), cc qui se traduit par une probabilité de validité projetée plus élevée pour la vue "tableAB" au moment estimé de la réception. Au contraire, des largeurs de bande plus faibles, comme par exemple 0,3 Mois (courbe C), 0,25 Mo/s (courbe B) et 0,2 Mo/s (courbe A), entraînent des temps de réception plus tardifs et donc une probabilité de validité plus faible pour la vue "tableAB" au moment de la réception estimée. [0055] Les informations sur la largeur de bande utilisée par le premier client lA pour dé- terminer le temps estimé de réception des données demandées peuvent être incluses dans la première réponse 11, peuvent être obtenues par des mesures de connexion du premier client l A (effectuées avant la première demande 10, tout en attendant la première réponse 11 et/ou après la première réponse 11), ou une valeur de largeur de bande par défaut peut être utilisée. [0056] Les FIG. 4 et 5 montrent des exemples de format de données de la première réponse 11 et de la deuxième réponse 14A. La réponse 11, 14A peut inclure une section d'en-tête 20 et une section de données 21. L'en-tête de la section 20 peut en outre inclure, dans le cadre de l'indication de validité susmentionnée, la taille des données, l'horodatage indiquant la création des données, le taux de validité, la version des données, etc. (FIG. 4). D'autres informations incluses dans l'en-tête de la section 20 et ne figurant dans aucune des figures peuvent inclure des informations telles que les informations de protocole, les adresses de l'expéditeur et du destinataire, etc. selon la couche du protocole du modèle OSI de l'en-tête. La première réponse 11 peut également inclure les données demandées à la première demande 10 (par exemple, la vue "tableAB"). Les données demandées dans la première demande 10 peuvent être incluses dans la section d'un bloc de données 21 de la première réponse 11. L'indication de validité peut, dans certains modes de réalisation et/ou selon la couche du protocole du modèle OSI de l'en-tête 20, être incluse dans la section de données 21 de la première réponse 11 (FIG. 5). Par exemple, l'indication de validité peut être incluse dans l'en-tête de la couche application (couche OSI 7) d'un protocole d'application pair à pair (FIG. 4), tandis que - du point de vue de la couche réseau (couche OSI 3) - l'en-tête 20 est un en-tête de protocole Internet (IP) et l'indication de validité se trouve dans le bloc de données 21 (FIG. 5). [0057] Le graphique séquentiel de messages de la FIG. 2 représente un mode de réalisation 12 de l'invention lorsqu'une indication de validité est incluse dans la première réponse 11. Cependant, dans certains modes de réalisation, les premières réponses 11 ne comportent pas nécessairement toutes une indication de validité. Dans de tels modes de réalisation, le premier client lA détermine si une indication de validité est incluse ou non dans la première réponse. Dans ces modes de réalisation, le deuxième client 1B pourrait répondre directement avec les données demandées dans la première réponse 11. Néanmoins, si une telle indication de validité n'est pas incluse dans la première réponse 11, le premier client lA pourrait décider, sur la base d'informations complémentaires, si les données demandées par la première demande 10 doivent (en plus) être demandées auprès du serveur 4. Par exemple, l'absence d'indication de validité dans la première réponse 11 pourrait indiquer que les données incluses dans la première réponse 11 sont vraisemblablement valides. Ainsi, il n'est pas nécessaire pour le premier client lA d'extraire en plus les données du serveur. Dans certains modes de réalisation, cette décision est fondée, par exemple, sur la taille des données reçues du deuxième client 1B. Si les données sont relativement petites, le fait d'extraire en plus les données du serveur et de comparer les deux versions des données afin de déterminer la version la plus récente n'impose pas une charge significative sur le réseau. Si, toutefois, les données sont relativement volumineuses, une extraction supplémentaire des données du serveur 4 peut être évitée et le premier client lA continue avec les données reçues du deuxième client 1B. [0058] La FIG. 6 montre un graphique du flux des modes de réception par le premier client lA des données demandées lorsque l'indication de validité dans la première réponse 11 est soit présente soit absente. En 30, le premier client 1A envoie une première demande 10 de données au deuxième client 1B (correspondant à la FIG 2). En 31, le premier client lA reçoit la première réponse 11. En 32, le premier client 1A examine si une indication de validité est incluse dans la première réponse 11. Lorsqu'il est déterminé que l'indication de validité est incluse, le flux des actions correspond à la FIG. 2 ou la FIG. 8 dont il est fait référence ci-dessous. C'est-à-dire que le premier client 1A détermine 12 si les données demandées par la première demande 11 et disponibles auprès du deuxième client 1B sont vraisemblablement invalides. Si les données disponibles du deuxième client sont déterminées comme étant invalides, le premier client lA envoie, en 35, la deuxième demande de données 13A au serveur 4 et reçoit finalement, en 39, les données demandées du serveur 4 avec la deuxième réponse 14A. Si, par contre, par la détermination 12, en 33, les données disponibles du deuxième client (deuxième client 1B) sont déterminées comme étant vraisemblablement valides, le premier client lA envoie, en 36, une deuxième demande 13A pour les données au deuxième client 1B et, en retour, reçoit les données demandées 40 du serveur 4 dans la deuxième réponse 14A. Si, d'autre part, une indication de validité n'est pas incluse dans la première 13 réponse 11, comme déterminée en 32, le premier client lA décide, en 34, selon les informations supplémentaires précitées, de recevoir ou non, en 38, les données du deuxième client 1B (comme mentionné ci-dessus et décrit plus en détail ci-dessous en référence à la FIG. 7, les données peuvent avoir déjà été incluses dans la première réponse 11, auquel cas les activités 31 et 38 coïncident ; alternativement, la première réponse peut uniquement indiquer si les données demandées sont disponibles chez le deuxième client 1B, auquel cas une extraction dédiée 38 est effectuée), et/ou recevoir, en 37, les données du serveur 4. [0059] La FIG. 7 montre un scénario dans lequel les données (par exemple la vue "tahleAB") sont déjà incluses dans la première réponse 11. Le premier client lA reconnaît, en 41, que la première réponse 11 comprend déjà les données demandées. Lorsque la détermination 12 rapporte, en 33, que les données demandées dans la première demande 11 et disponibles auprès du deuxième client 1B sont vraisemblablement valides, le processus de récupération se termine et le premier client lA traite la version reçue des données. Si les données incluses dans la première réponse 11 sont, cependant, déterminées 12, être vraisemblablement invalides, alors le premier client lA demande, à 35, les données auprès du serveur 4 par le biais de la deuxième demande 13A et continue selon la FIG. 2 pour recevoir, en 39, par exemple la vue valide actuelle "tableAB MISE À JOUR". Dans certains modes de réalisation, le premier client lA ne récupère pas les données demandées (par exemple la vue valide "tableAB_MISE À JOUR") dans son ensemble, mais seulement les différences entre les données potentiellement obsolètes déjà reçues du deuxième client 1B et la version éventuellement mise à jour des données du serveur 4. Cela permet en outre d'économiser les ressources de calcul du réseau et du serveur. [0060] Les graphiques séquentiels de messages d'un mécanisme selon certains modes de réa- lisation sont présentés par la FIG. 8. Dans l'exemple de la FIG. 8, les données disponibles par l'entremise du deuxième client 1B sont vraisemblablement valides. Comme déjà décrit ci-dessus en référence à la FIG. 2, le premier client lA envoie d'abord la première demande de données 10 (par exemple la vue "tableAB") au deuxième client 1B et reçoit une première réponse 11 du deuxième client 1B en réponse à la première demande 10. La première réponse 11 comprend une indication de validité indiquant une probabilité que les données demandées au deuxième client 1B soient invalides. Par la suite, le premier client lA détermine 12 ensuite une probabilité de validité des données demandées par la première demande et disponibles auprès du deuxième client sur la base de l'indication de validité incluse dans la première réponse 11. Si la détermination 12 rapporte que les données demandées par la première demande 11 et disponibles auprès du deuxième client 1B sont vraisemblablement valides et si les données n'ont pas déjà été incluses dans la première réponse 11, le 14 premier client lA envoie en réponse une deuxième demande 13B au deuxième client 1B pour obtenir les données (voir "tableAB") du deuxième client 1B. Enfin, en réponse à la deuxième demande 13B, le premier client lA reçoit les données du deuxième client 1B dans une deuxième réponse 14B et stocke les données récupérées (la vue "tableAB") associées à l'indication de validité incluse dans la première réponse 11. [0061] La FIG. 9 présente un scénario dans lequel le premier client lA a déjà récupéré et stocké les données ainsi que l'indication de validité associée préalablement, auprès du serveur 4 selon la FIG. 2, ou du deuxième client 1B selon la FIG. 8, ou des deux, comme mentionné en référence à la FIG. 7. Le premier client lA est donc en mesure de fournir les données récupérées à encore d'autres clients 1. Le premier client lA reçoit une troisième demande de données 15 d'un troisième client 1C, selon laquelle le troisième client 1C demande par exemple la vue "tableAB" ou la vue "tableAB_MISE À JOUR". Le premier client lA envoie une troisième réponse 16 au troisième client 1C en réponse à la troisième demande 15, selon laquelle la troisième réponse 16 comprend l'indication de validité associée aux données demandées. L'indication de validité incluse dans la troisième réponse 16 comprend, dans certains modes de réalisation, les mêmes informations que les indications de validité incluses dans la première réponse 11 du deuxième client 1B ou dans la deuxième réponse 13A du serveur 4, comme décrit ci-dessus. Le troisième client 1C est alors en mesure de déterminer s'il doit récupérer les données auprès du premier client lA et/ou du serveur 4. [0062] Dans un certain mode de réalisation, le premier client lA, en réponse à la réception de la troisième demande 15 du troisième client 1C, évalue la probabilité que les données demandées soient invalides (au moment actuel ou à un moment estimé de la réception des données au troisième client 1C) selon l'indication de validité enregistrée associée aux données. Dans le prolongement de l'exemple spécifique présenté ci-dessus, le premier client 1A évalue la probabilité que par exemple la vue "tableAB", ou par exemple la vue "tableAB_MISE À JOUR" demandée par le troisième client 1C soit invalide. Si la détermination a rapporté que les données demandées sont vraisemblablement valides, le premier client lA peut, en réponse à ce résultat, inclure directement les données demandées dans la troisième réponse 16 (par exemple, la vue "tableAB" ou la vue "tableAB_MISE À JOUR") au troisième client 1C. Si, toutefois, le premier client lA détermine que les données demandées par le troisième client 1C sont vraisemblablement invalides (au moment actuel ou à un moment estimé de la réception des données au troisième client 1C), le premier client lA inclut, dans certains modes de réalisation, l'indication de validité dans la troisième réponse 16, mais non les données demandées elles-mêmes. [0063] Comme déjà mentionné plus haut, dans certains modes de réalisation, l'indication de validité comprend un horodatage tO indiquant l'heure à laquelle les données demandées (par exemple la vue "tableAB" ou par exemple la vue "tahleAB_MISE À JOUR") ont été générées, ainsi qu'un taux de validité C des données demandées. Lc taux de validité C peut estimer la probabilité d'invalidité dans le temps, par exemple sur la hase d'un modèle probabiliste. Le taux de validité C des données demandées (par exemple la vue "tableAB" ou la vue "tahleAB_MISE À JOUR") est une mesure de la durée de validité des données demandées ou de la vitesse à laquelle les données demandées deviennent invalides en raison de modifications apportées aux données initiales sous-jacentes. Ce taux de validité d'une donnée demandée est, par exemple, dérivé statistiquement de l'occurrence et des résultats de (re)calculs passés ou de (re)collectes et de comparaisons des données demandées avec leur état ou leurs valeurs antérieures. Par exemple, il a été déterminé que certaines données demandées possèdent un taux de validité C de 10 % par heure, ce qui signifie que la probabilité que les données demandées (par exemple la vue "tableAB" ou la vue "tahleAB_MISE À JOUR") soient valides diminue de 10 % par heure. Lors de leur (re)collecte ou de leur (re)calcul, les vues "tableAB" ou "tahleAB_MISE À JOUR" sont généralement 100 % valides. Après une heure, la vue "tableAB" ou la vue "tahleAB_MISE À JOUR" sont valides avec une probabilité de 90 %. Après deux heures, la validité de la vue "tableAB" ou de la vue "tableAB_MISE À JOUR" est de 81 % (= 90 % moins 10 % supplémentaires). Après trois heures, les validités probables de la vue "tableAB" ou "tahleAB_MISE À JOUR" sont de 72,9 %, et ainsi de suite. [0064] Dans certains modes de réalisation, une valeur de probabilité de validité donnée par Math. I (tel qu'introduit ci-dessus) est calculé par le premier client lA, où t indique l'heure actuelle ou l'heure estimée de réception des données. Le taux de validité C peut être utilisé pour fournir une estimation de la probabilité selon laquelle les données demandées demeurent valides après un certain temps. Il s'agit également de la probabilité que les données demandées (par exemple la vue "tableAB" ou la vue "tableAB_MISE À JOUR") soient valides ou, en d'autres termes, ne soient pas obsolètes. Deux fonctions exemplaires de cette validité probable diminuant avec le temps sont décrites par la FIG. 10. La fonction F représente des données demandées qui restent potentiellement plus précises (ou, plus être plus con-ect, restent à une probabilité plus élevée d'être valides dans le temps) qu'une autre donnée demandée associée à la fonction G. Par exemple, les données demandées représentées par la fonction F ont 70 % de probabilité d'être encore valides 35 heures après leur dernière génération, tandis que les autres données demandées caractérisées par la fonction G ne sont valides que jusqu'à hauteur de 50 % 35 hem-es après leur toute dernière génération. Le premier client lA compare la valeur de probabilité de validité de la vue "tableAB" ou "tableAB_MISE À JOUR" avec une valeur seuil donnée et détermine 12 que les données demandées sont vraisemblablement invalides si la valeur de pro- 16 habilité de validité est inférieure à la valeur seuil donnée. [0065] La FIG. 11 est une représentation schématique du composant interne d'une machine informatique du serveur 4 et/ou des clients 1 A, 1B, 1C. La machine informatique 100 comprend un ensemble d'instructions amenant la machine informatique 100 à effectuer l'une quelconque des méthodologies décrites ici lorsqu'elle est exécutée par la machine informatique 100. La machine informatique 100 comprend au moins un processeur 101, une mémoire principale 106 et un dispositif d'interface réseau 103 qui communiquent entre eux via un bus 104. En option, la machine informatique 100 peut en outre inclure une mémoire statique 105 et une unité d'entraînement de disque. Un écran vidéo, un dispositif d'entrée alphanumérique et un dispositif de contrôle du curseur peuvent être fournis comme exemples d'interface utilisateur 102. Le dispositif d'interface réseau 103 relie la machine informatique 100 aux autres composants du système informatique distribué tels que les clients 1A, 1B, 1C, le serveur 4 ou d'autres composants tels que les hases de données. [0066] La machine informatique 100 héberge également le cache 107. Le 107 peut stocker les tables de la hase de données reçues également dans un cache. Le cachc 107 dans les présents modes de réalisation peut être composé de composants matériels et logiciels qui stockent les tables de la hase de données de sorte que les demandes futures des tables de la base de données puissent être traitées plus rapidement que sans mise en mémoire cache. Il peut y avoir des caches matériels tels que les caches CPU, les caches GPU, les processeurs de signaux numériques et les mémoires tampons d'anticipation de traduction, ainsi que des caches logiciels tels que les caches de pages, les caches Web (Protocole de transfert hypertexte, HTTP, caches), etc. Le serveur 4 et les clients 1A, 1B, 1C peuvent être constitués d'un cache 107. Le serveur 4 démarre le traitement des données telles que le décodage des tables de la base de données reçues, l'élimination des erreurs résidant dans les tables de base de données en supprimant, par exemple, les jeux de données redondants des tables de la base de données ou les jeux de données dont les entrées manquent. De plus, les tables de la base de données sont rassemblées dans un format de données commun pour faciliter le traitement ultérieur. [0067] Un ensemble d'instructions exécutables par ordinateur (c.-à-d. un code de programme informatique) comprenant l'une ou l'autre des méthodologies décrites dans le présent document, ou l'ensemble d'entre elles, réside entièrement ou au moins partiellement dans ou sur un support lisible par machine, par exemple, la mémoire principale 106. La mémoire principale 106 héberge le code de programme informatique pour les entités fonctionnelles telles que le traitement des demandes de base de données 108, qui comprend la fonctionnalité de réception et de traitement des demandes de base de données et la fonctionnalité de traitement des données 109. Les instructions peuvent en outre être transmises ou reçues sous la forme d'un signal propagé via Internet à travers 17 le dispositif de l'interface réseau 103 ou l'interface utilisateur 103. La communication au sein de la machine informatique s'effectue via le bus 104. Le fonctionnement de hase de la machine informatique 100 est commandé par un système d'exploitation qui se trouve également dans la mémoire principale 106, le au moins un processeur 101 et/ ou la mémoire statique 105. [0068] En général, les routines exécutées pour l'implémentation des modes de réalisation, qu'il s'agisse d'une implémentation faisant partie d'un système d'exploitation ou d'une application, composant, programme, objet, module ou séquence d'instructions spécifique, ou même d'un sous-ensemble de ceux-ci, peuvent être appelées ici "code programme informatique" ou simplement "code programme". Le code programme comprend généralement des instructions lisibles par ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage d'un ordinateur et qui, lorsqu'elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent cet ordinateur à effectuer les opérations nécessaires pour exécuter les opérations et/ou les éléments incarnant les divers aspects des modes de réalisation de l'invention. Les instructions de programme lisibles par ordinateur pour l'exécution d'opérations sur les modes de réalisation de l'invention peuvent être, par exemple, un langage d'assemblage ou un code source ou un code objet écrit dans une combinaison quelconque d'un ou de plusieurs langages de programmation. 18 [Revendication I] [Revendication 2] [Revendication 3] [Revendication 4]