FR 2989241 A1 20131011 FR 1253152 A 20120405 La présente invention se rapporte à la diffusion d'un contenu au sein d'un réseau informatique, et plus particulièrement mais non exclusivement à la diffusion d'un contenu sur la toile (Web). A l'exception des messageries instantanées, du « chat » et de certains logiciels P2P, la plupart des applications Internet sont fondées sur un modèle traditionnel client/serveur. L'architecture client/serveur s'appuie sur un poste central, le serveur, qui envoie les données aux machines clientes. Plusieurs limites du fonctionnement au Web ont commencé à apparaître après l'avènement des connexions haut débit et l'augmentation fulgurante de la taille des contenus (vidéo 1-ID, images de grande résolution ...) véhiculés sur Internet. Bien que les applications Web aient considérablement évolué en profitant de l'expérience utilisateur et des aspects communautaires, le paradigme client/serveur impose toujours des limitations techniques et fonctionnelles au niveau utilisateur à cette évolution. Le coût de fonctionnement d'une application Web constitue l'une de ces limitations. Généralement le coût de développement d'un service Internet est relativement faible. Cependant, le coût de fonctionnement, qui est essentiellement lié à la bande passante et à l'espace de stockage, est assez élevé au détriment de ce qui peut être offert aux utilisateurs. Par exemple, fournir des médias (photos, audio, vidéo) libres de droit implique un investissement continu qui est difficile à amortir. De plus, actuellement, l'interruption d'une connexion avec le serveur entraîne l'arrêt pur et simple du service fourni. L'alternative utilisée pour faire face aux problématiques de saturation des serveurs en cas de forte affluence des Internautes sur un site Internet consiste à faire appel au service d'entreprises qui proposent des CDN (Content Delivery Network). Cette solution a un coût très important pour le fournisseur de contenu et nécessite une surveillance permanente des serveurs en cas de surcharge des réseaux afin d'augmenter la bande passante et la taille des serveurs. Une telle solution est adaptée à fiabiliser la disponibilité du contenu pour une sollicitation moyenne mais n'arrive toujours pas à relever le défi en cas de très forte sollicitation ou d'une transmission en direct. Cela est dû au problème des pics d'audience et de leur régulation qui nécessite une bande passante abondante et un matériel adapté selon l'importance du pic. existe par conséquent un besoin pour améliorer encore la diffusion d'un contenu au sein d'un réseau informatique et plus particulièrement sur la toile, et notamment éliminer définitivement et au moindre coût les problèmes de congestion des réseaux. L'invention y parvient grâce à un procédé de diffusion d'un contenu dans un réseau informatique comportant un serveur de contenu disposant du contenu à diffuser et une pluralité de clients cherchant à récupérer ledit contenu, procédé dans lequel le contenu est servi en mode client/serveur à au moins un client sous un format permettant sa diffusion ultérieure en mode P2P à d'autres clients. L'invention permet de combiner le paradigme du pair-à-pair (Peer to Peer) au traditionnel modèle client/serveur des applications Web pour tirer profit des avantages de ces deux architectures. L'invention offre une solution fondée sur une technologie P2P adaptée à un environnement Web et couplée à un fonctionnement client/serveur classique. Cette solution est intégrable, notamment sous forme de plug-in, dans tous les navigateurs Web et permet de distribuer des contenus multimédia en réduisant les coûts d'infrastructure et de bande passante pour les fournisseurs de contenus, en conservant la même qualité de service pour l'intérnaute. L'invention petinet d'accélérer et de fluidifier l'accès à certains services très sollicités, notamment lors d'événements particuliers (manifestations sportives, festivités ...) ou d'informations déposées sous forme de contenu multimédia, par exemple des documents ou des vidéos de plus de 30 Mo déposés sur des sites d'information. L'invention concerne tout type de contenu récupérable ou visualisable, par exemple une vidéo en direct, sur le Web via un navigateur. L'invention permet que les ressources, notamment l'espace de stockage et la bande passante, de l'internaute soient impliquées d'une façon relativement faible. L'espace de stockage investi par l'internaute peut ne pas dépasser le cache déjà utilisé par les applications Web. Le coût d'exploitation de l'invention est faible du fait que celle-ci bénéficie de 30 la nature même de l'architecture P2P. En effet, les fournisseurs de contenus peuvent décharger l'essentiel du traitement des services à leurs utilisateurs finaux et se limiter, une fois la diffusion amorcée, à jouer le rôle d'annuaire tout en offrant des services plus. attrayants à leurs internautes. L'invention permet que la continuité du service soit assurée par le nombre d'internautes partageant le même contenu. L'invention permet aux petits et grands fournisseurs de contenus de proposer à leur internautes une Qualité de Service (QoS) équivalente, voire supérieure, à un CDN et 5 ce à moindre coût. Le serveur de contenu peut répertorier les clients qui ont déjà récupéré une partie du contenu et adresser à un nouveau client cherchant à récupérer le contenu l'adresse d'au moins un autre client auprès duquel il peut récupérer au moins une pièce de ce contenu. 10 Le serveur de contenu peut avantageusement déterminer la ou les pièces les plus manquantes dans le swarm, et le serveur de contenu peut adresser à un nouveau client au moins l'une des pièces identifiées comme les plus manquantes afin de faciliter son intégration dans le swarm. Le contenu peut être adressé par le serveur de contenu sous forme de pièces 15 identifiées avec une information associée visant à faciliter l'échange entre clients en mode P2P. L'information associée comporte de préférence le hash. Un module de suivi de qualité de service est avantageusement utilisé pour récupérer au moins un paramètre de qualité de service des clients. Le nombre de connexions autorisées client/serveur est de préférence fonction 20 dudit au moins un paramètre. Le nombre de connexions autorisées entre les internautes peut être limité si la connexion de l'internaute émetteur du contenu n'est pas bonne, afin de limiter l'utilisation de sa bande passante. Le procédé peut comporter la fourniture par le serveur de contenu à un client 25 d'un programme à installer notamment sous forme de plug-in au niveau du navigateur de ce client pour pouvoir récupérer le contenu en mode client/serveur avec un format P2P et recevoir la liste des clients du serveur de contenu. Le procédé peut comporter la détermination du mode de diffusion du contenu en temps réel, client/serveur ou P2P, en fonction de seuils prédéfinis, notamment QoS et 30 QoE des clients récupérant le contenu. Le procédé peut permettre la diffusion du contenu, en mode P2P, via les navigateurs des clients. L'invention a encore pour objet, selon un autre de ses aspects, un produit programme d'ordinateur, comportant un programme informatique enregistré sur un support ou téléchargé, agencé pour, sur l'ordinateur d'un client : - installer sur l'ordinateur une application qui permet, à partir du navigateur du client, lors de la connexion à un serveur de contenu agencé pour mettre en oeuvre le procédé selon l'invention : - télécharger le contenu depuis le serveur en mode client/serveur par pièces compatibles avec sa diffusion en mode P2P à d'autres clients s'étant connectés au serveur de contenu ou, si le serveur n'offre pas cette possibilité, - télécharger depuis le serveur une liste de clients disposant de pièces du contenu de façon à le récupérer dans un mode P2P auprès d'autres clients s'étant connectés au serveur de contenu. Lors de la réception d'une nouvelle demande de connexion par le serveur de contenu, ce dernier détermine si le client dispose d'un programme permettant de mettre en oeuvre l'invention. Dans la négative, le serveur de contenu propose au client le téléchargement d'un programme sous forme de plug-in assurant la compatibilité protocolaire. Dans l'affirmative, le serveur de contenu met à jour des seuils et détermine si les seuils sont franchis et si le client doit être servi selon un mode P2P ou selon un mode client/serveur. Si les seuils du nombre de connexions ne sont pas franchis, le contenu peut être transmis en mode client/serveur. Le serveur de contenu répertorie les coordonnées du client qui va être servi en mode client/serveur. Le contenu est envoyé en petites pièces et en mode client/serveur http. Si les seuils sont franchis, le client sera servi en mode P2P. Le serveur de contenu répertorie les coordonnées du client et lui envoie les coordonnées des clients, notamment l'adresse IP et le port, ainsi qu'au moins l'une des 25 pièces. Durant son exécution, après une demande de contenu au serveur, le programme récupère auprès du serveur de contenu le mode de téléchargement. Dans le cas où le serveur indique au programme que le contenu peut être récupéré en mode client/serveur, celui-ci est reçu sous forme de pièces du serveur de contenu. En cas de mode P2P, le 30 programme récupère la liste des clients et au moins une pièce du contenu, de préférence l'une au moins des plus manquantes. Le programme se connecte alors au swarm et récupère le contenu. Le contenu récupéré par pièces est reconstruit par le programme en vue de sa lecture et/ou affichage. L'invention pourra être mieux comprise à la lecture de la description détaillée qui va suivre, d'un exemple de mise en oeuvre non limitatif de celle-ci, et à l'examen du dessin annexé, sur lequel : la figure 1 illustre, de façon schématique, une architecture permettant la mise en oeuvre de l'invention, - la figure 2 représente schématiquement un diagramme de tâches du module manager, et - la figure 3 représente schématiquement un diagramme de tâches du module plug-in du navigateur. Le procédé selon l'invention peut être mis en oeuvre au sein d'une architecture globale 1, représentée schématiquement sur la figure 1, comportant un serveur de contenu 2 et plusieurs clients 3 constitués dans cet exemple par des intemautes qui communiquent avec le serveur de contenu par l'intermédiaire du réseau Internet. Contrairement à un fonctionnement pur P2P, le contenu à diffuser est toujours présent sur le serveur de contenu 2. Au cours de la mise en oeuvre du procédé, le serveur 2 commence à servir en mode client/serveur les premiers clients intemautes, encore appelés pairs. Pour faciliter le basculement en mode P2P, le serveur 2 découpe le contenu en petites pièces (de 65 Ko à 1Mo en fonction de la taille et du type de contenu) et identifie chaque pièce du contenu. Par exemple, les N-1 premiers intemautes sont servis en mode client/serveur mais le contenu est envoyé en petites pièces avec des infounations sur chacune de ces pièces, telles que numéro et identifiant, ce dernier comportant de préférence le hash. Le mode client/serveur utilise ainsi le découpage en petites pièces du contenu et l'identification de chaque pièce pour faciliter le passage vers le mode P2P ainsi que la sécurisation du contenu sur les deux modes client/serveur et P2P. À partir par exemple du. Nième internaute et/ou le franchissement d'un ou 30 plusieurs seuils prédéfinis, par exemple relatifs à la bande passante ou la charge CPU, le serveur 2 envoie au Nième internaute, nouvellement connecté, une liste d'internautes qui ont déjà récupéré une partie du contenu afin que le Nième internaute puisse commencer à récupérer le contenu en mode P2P à partir des internautes répertoriés par la liste. Le Nième internaute peut être le 100ième ou le 200iè' ou plus en fonction de la puissance du serveur et des paramètres de Qualité de Service (QoS) et de Qualité d'Expérience (QoE) en retour des différents internautes. Parmi les informations remontées au serveur par les internantes, en plus des paramètres QoS et QoE, chaque client envoie des informations sur la dernière pièce qu'il vient de télécharger et indique quel niveau de téléchargement est atteint. Ces informations permettent au serveur 2 de connaître les pièces les plus manquantes dans le « swarm », c'est-à-dire ici l'ensemble des clients qui consultent le serveur 2. Un des grands problèmes des protocoles P2P est la lenteur de l'intégration du nouvel arrivant dans le swarm. Le nouvel arrivant n'a rien à proposer car il n'a aucune pièce et aucun client dans le swarm ne s'intéressera à lui, sauf ceux qui ont déjà tout téléchargé et qui sont appelés «seeds ». S'il n'y a pas beaucoup de seeds, le nouveau client mettra plusieurs minutes pour s'intégrer au swarm. Pour résoudre ce problème, en plus de la liste des clients et des informations sur le contenu, le serveur 2 envoie aussi au nouvel arrivant au moins l'une des pièces les plus manquantes dans le swarm pour permettre au nouveau client d'intégrer rapidement le swarm et de commencer les échanges avec les autres clients. Toutes les fonctionnalités de l'échange P2P, telles que l'échange de la liste des clients entre internautes, notamment PEX2 Peer Exchange, la récupération de la liste des clients via des moyens autres que le serveur de contenu, notamment DHT3 Table de hachage distribuée, peuvent être utilisées dans l'invention. Le serveur de contenu 2 comporte des modules appelés module manager 11, 25 module de suivi de qualité de service 12 et module préparateur du contenu 13. Module manager Le module manager 11 fait le choix, en fonction des limites fixées par le module qualité de service 12, du mode de communication : client/serveur ou P2P. Les différentes tâches du module manager 11 sont présentées sur la figure 2. 30 Lors d'une nouvelle demande de connexion par un internaute, à l'étape 21, le module manager détermine à l'étape 22 si l'internaute dispose du programme adapté à recevoir le contenu. Dans la négative, il permet à l'internaute de télécharger le programme sous forme de plug-in à l'étape 23. Dans l'affirmative, le module manager met à jour à l'étape 24 les seuils qui déterminent le mode de fonctionnement, client/serveur ou P2P. A l'étape 25, le module manager détermine si les seuils sont dépassés. Si oui, l'internaute est conduit à l'étape 26 à télécharger le contenu en mode 5 P2P et le module manager enregistre à l'étape 27 les coordonnées de l'internaute, puis à l'étape 28 envoie à l'internaute les coordonnées IP et le port des intemautes du swarm ainsi qu'une des pièces, notamment une pièce recherchée, comme indiqué plus haut. Si les seuils ne sont pas dépassés, le module manager permet à l'étape 29 à l'internaute de télécharger en mode client/serveur, mémorise ses coordonnées à l'étape 30 10 et lui adresse le contenu sous forme de pièces à l'étape 31, comme expliqué précédemment. Module de suivi de la Qualité Le module 12 récupère tous les paramètres de Qualité, notamment qualité de service QoS et qualité d'expérience QoE, ainsi que des paramètres protocolaires tels que 15 bande passante et taux de téléchargement, associés à chaque contenu, et transmis par tous les clients intemautes. A partir de ces paramètres, le module 12 met à jour les seuils, notamment la limite du nombre de connexions autorisées en mode client /serveur, la bande passante maximale par connexion, et détermine les pièces les plus manquantes dans le swarm. 20 Les paramètres et les seuils peuvent changer en fonction du contenu échangé dans le swarm. En particulier, les critères et les seuils de qualité d'un contenu vidéo ne sont pas les mêmes que pour une page Web statique. Module de préparation du contenu Le module 13 découpe le contenu à diffuser en petites pièces transportables sur 25 chacun des modes de communication client/serveur ou P2P et calcule pour chacune des pièces un identifiant, de préférence le hash. La taille des pièces dépend essentiellement du type du contenu (vidéo « streaming » ou « live », contenu statique, ..) et de sa taille. Pour le streaming et le live la taille des pièces dépendra également du codage utilisé sur le contenu. Dans ce cas de figure 30 (Streaming ou live) la taille des pièces peut varier de 125Ko à 500Ko. Pour les contenus statiques la taille peut varier de 65Ko à 1Mo. Le programme installé sous forme de plug-in au niveau du navigateur du client permet au navigateur de récupérer le contenu en mode client/serveur avec le format P2P, sous forme de pièces avec leurs informations associées (Numéro des pièces, leurs tailles et leurs identifiants). On a illustré à la figure 3 le fonctionnement de ce programme. A l'étape 40, l'internaute s'est connecté au serveur de contenu 2. Le programme récupère à l'étape 41, du serveur de contenu, le mode de téléchargement. Dans le cas où celui-ci est le mode client/serveur, le programme récupère à 10 l'étape 42 le contenu directement du serveur, sous forme de pièces, comme indiqué plus haut, qui sont ensuite assemblées à l'étape 43 pour reconstruire le contenu, et permettre son utilisation par exemple par lecture ou affichage à l'étape 44. Dans le cas où le mode de téléchargement est le mode P2P, le programme récupère à l'étape 45 la liste des pairs et une pièce du contenu, de préférence la plus 15 recherchée, comme expliqué précédemment, afin de s'intégrer dans le swarm à l'étape 46 pour récupérer les autres pièces du contenu. Ensuite, la reconstruction du contenu peut avoir lieu à l'étape 43 et son utilisation à l'étape 44. L'invention n'est pas limitée aux exemples qui viennent d'être décrits. 20 L'expression « comportant » doit se comprendre comme étant synonyme de « comportant au moins un ». REVENDICATIONS1. Procédé de diffusion d'un contenu dans un réseau informatique comportant un serveur de contenu (2) disposant du contenu à diffuser, et une pluralité de clients (3) cherchant à récupérer ledit contenu, procédé dans lequel le contenu est servi en mode client/serveur à au moins un client sous un format permettant sa diffusion ultérieure en mode P2P. 2. Procédé selon la revendication 1, dans lequel le serveur de contenu (2) répertorie les clients (3) qui ont déjà récupéré une partie du contenu et adresse à un nouveau client cherchant à récupérer le contenu l'adresse d'au moins un autre client auprès 10 duquel il peut récupérer au moins une pièce de ce contenu. 3. Procédé selon la revendication 1 ou 2, dans lequel le serveur de contenu (2) détermine la ou les pièces les plus manquantes dans le swarm, et dans lequel le serveur de contenu (2) adresse à un nouveau client au moins l'une des pièces identifiées comme les plus manquantes afin de faciliter son intégration dans le swarm. 15 4. Procédé selon l'une quelconque des revendications 1 à 3, le contenu étant adressé par le serveur de contenu (2) sous forme de pièces identifiées avec une information associée visant à faciliter l'échange entre clients en mode P2P. 5. Procédé selon la revendication 4, l'information associée comportant le haste. 20 6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel un module de suivi de qualité de service récupère au moins un paramètre de qualité de service des clients. 7. Procédé selon la revendication 6, dans lequel le nombre de connexions autorisées client/serveur est fonction dudit au moins un paramètre. 25 8. Procédé selon l'une quelconque des revendications 1 à 7, comportant la fourniture par le serveur de contenu à un client d'un programme à installer, notamment sous forme de plug-in au niveau du navigateur de ce client pour pouvoir récupérer le contenu en mode client/serveur avec un format P2P et recevoir la liste des clients du serveur de contenu. 30 9. Procédé selon l'une quelconque des revendications 1 à 8, dans lequel on détermine le mode de diffusion du contenu en temps réel, client/serveur ou P2P, en fonction de seuils prédéfinis, notamment QoS et QoE,- des clients récupérant le contenu. 10. Procédé selon l'une quelconque des revendications précédentes, dans lequel on permet la diffusion du contenu, en mode P2P, via les navigateurs des clients. 11. Produit programme d'ordinateur, comportant un programme informatique enregistré sur un support ou téléchargé, agencé pour, sur l'ordinateur d'un client : - installer sur l'ordinateur une application qui permet, à partir du navigateur du client, lors de la connexion à un serveur de contenu agencé pour mettre en oeuvre le procédé tel que défini dans l'une quelconque des revendications précédentes : télécharger le contenu depuis le serveur en mode client/serveur par pièces compatibles avec sa diffusion en mode P2P à d'autres clients s'étant connectés au serveur de contenu ou, si le serveur n'offre pas cette possibilité, - télécharger depuis le serveur une liste de clients disposant de pièces du contenu de façon à le récupérer dans un mode P2P auprès d'autres clients s'étant connectés au serveur de contenu.15