FR3079099A1

FR3079099A1 - Procede de diffusion d'un contenu

Info

Publication number: FR3079099A1
Application number: FR1852326A
Authority: FR
Inventors: Soufiane Rouibia; Imane MNIE-FILALI
Original assignee: Easybroadcast
Current assignee: Easybroadcast
Priority date: 2018-03-19
Filing date: 2018-03-19
Publication date: 2019-09-20
Anticipated expiration: 2038-03-19
Also published as: WO2019179855A1; FR3079099B1; EP3769535A1; US20210058651A1

Abstract

Procédé de diffusion d'un contenu, notamment multimédia, depuis un serveur de contenu (CDN) dans au moins un réseau privé comportant au moins trois terminaux pouvant échanger des données entre eux, la bande passante avec laquelle au moins un terminal peut se connecter au serveur de contenu étant insuffisante pour permettre la diffusion du contenu sur chacun des terminaux par une connexion de chacun de ceux-ci au serveur de contenu (CDN), le procédé comportant les étapes consistant à : d) Répertorier, notamment dans un serveur de gestion (EB), au moins l'un desdits terminaux comme client maître (SPV) et au moins deux autres desdits terminaux comme clients esclaves (SLV), e) transmettre au moins une partie du contenu à diffuser à ce client maître (SPV), notamment via la connexion au serveur de contenu (CDN), f) amener le client maître (SPV) à pousser au moins une partie du contenu à diffuser vers au moins l'un des clients esclaves (SLV) du réseau privé via les liaisons existant entre les terminaux au sein du réseau privé.

Description

La présente invention concerne un procédé de diffusion d’un contenu depuis un serveur distant vers une pluralité de terminaux d’un réseau privé, disposant pour certains d’une bande passante limitée.

Certaines organisations, avec différents sites éloignés géographiquement, sont souvent amenées à devoir diffuser un contenu vidéo à de nombreux terminaux.

Chaque organisation peut avoir un besoin différent quant à la diffusion d’un tel contenu. Il s’agit par exemple d’un message d’un dirigeant s’adressant à l’ensemble de ses collaborateurs ou d’une communication promotionnelle à l’égard d’un nouveau produit ou service dans une agence bancaire ou un magasin. Il peut s’agir encore d’un message personnalisé destiné aux clients d’un hôtel, d’une diffusion de service dans une administration ou d’un contenu éducatif, par exemple des cours diffusés en mode E-learning dans une école ou de mise à niveau dans différents domaines des compétences des collaborateurs d’une entreprise.

Ces messages n’ont pas de contrainte de temps réel. Si deux utilisateurs subissent une différence d’une seconde ou plus lors du visionnage du même contenu, ceci n’a pas d'importance tant que la qualité de la vidéo est maintenue et que l'expérience utilisateur demeure satisfaisante.

Les réseaux étendus ou WAN sont les plus répandus au sein de ces organisations. Or, ces réseaux ne sont pas toujours dédiés au transport de contenus multimédia, ce qui limite leur capacité à fournir une qualité de service de niveau professionnel ainsi qu’une latence appropriée pour garantir une expérience satisfaisante à l’ensemble des utilisateurs finaux.

De plus, la croissance du nombre de postes connectés au sein de l'ensemble des entités d’une organisation augmente continûment le besoin en bande passante, et ce d’autant plus que la taille des contenus vidéo est en pleine expansion.

Il existe par conséquent un besoin pour répondre au problème de la diffusion d’un contenu, notamment multimédia, depuis un serveur distant au sein d’au moins un réseau privé et l’invention vise à y répondre.

Elle y parvient grâce à un procédé de diffusion d’un contenu, notamment multimédia, depuis un serveur de contenu dans au moins un réseau privé comportant au moins trois terminaux pouvant échanger des données entre eux, la bande passante avec laquelle au moins un terminal peut se connecter au serveur de contenu étant insuffisante pour permettre la diffusion du contenu sur chacun des terminaux par une connexion de chacun de ceux-ci au serveur de contenu, le procédé comportant les étapes consistant à :

a) Répertorier, notamment dans un serveur de gestion (EB), au moins l’un desdits terminaux comme client maître et au moins deux autres desdits terminaux comme clients esclaves,

b) transmettre au moins une partie du contenu à diffuser à ce client maître, notamment via la connexion au serveur de contenu,

c) amener le client maître à pousser au moins une partie du contenu à diffuser vers au moins l’un des clients esclaves du réseau privé via les liaisons existant entre les terminaux au sein du réseau privé.

Le procédé peut également comporter en outre l’étape consistant à :

d) pour au moins un client esclave n’ayant pas reçu les paquets nécessaires du contenu à diffuser du client maître, recevoir les paquets manquants d’au moins un autre client esclave en utilisant les liaisons existant entre les clients esclaves au sein du réseau privé.

L’invention permet de maintenir une diffusion fluide du contenu tout en gardant l’architecture réseau initiale de l’organisation. Au sens de l’invention, les termes « client » et « terminal » sont synonymes. Par réseau public, il faut comprendre un réseau internet à large bande passante. L’accès au serveur de contenu et/ou au serveur de gestion peut s’effectuer par un réseau public, le cas échéant.

La diffusion du contenu peut s’effectuer selon un premier protocole de transmission lorsque la bande passante est suffisante, et selon un deuxième protocole lorsque la bande passante est insuffisante pour la mise en œuvre du premier protocole.

Un serveur de gestion est prévu, auquel peuvent se connecter les terminaux du réseau privé, avant de commencer à recevoir le contenu diffusé par le serveur de contenu. Ce serveur de gestion peut déterminer, lors de la connexion d’un terminal à celui-ci, avec quel protocole ce terminal pourra recevoir le contenu diffusé.

Pour cela, le serveur de gestion peut effectuer un test de bande passante lors de la connexion du terminal, ou en variante déterminer la bande passante en fonction de la localisation du terminal, par exemple son adresse IP, en s’aidant d’une base de données renseignant sur la bande passante en fonction de la localisation. L’utilisation d’une telle base de données et préférable car plus rapide que d’effectuer un test de bande passante. Le serveur de gestion peut être accessible par les terminaux du réseau privé via un réseau public par exemple, ou faire partie du réseau privé.

Un terminal opérant selon le premier protocole peut être configuré pour attendre une durée prédéfinie de recevoir un paquet d’autres terminaux avec lesquels il échange des données avant d’interroger le serveur de contenu. Cette durée peut dépendre par exemple de la taille des paquets, du nombre de clients esclaves et maîtres.

Le deuxième protocole ci-dessus est avantageusement un protocole de diffusion avec un contenu poussé depuis le client maître, sous un format autorisant une possibilité d’échange de type pair à pair entre les terminaux esclaves. Une partie au moins du contenu à diffuser peut être poussée par le client maître vers des clients esclaves du réseau privé, ces clients esclaves étant de préférence choisis de façon aléatoire par le client maître.

La diffusion d’une partie au moins du contenu à diffuser, entre les clients esclaves, s’effectue avantageusement par un mécanisme de diffusion de pair à pair en plus de recevoir les paquets poussés par le client maître.

Le procédé selon l’invention peut comporter l’étape consistant à répertorier au moins l’un des clients esclaves du réseau privé comme client esclave prioritaire, et à amener le client maître à pousser les paquets du contenu à diffuser en priorité vers ce client esclave prioritaire. Les paquets peuvent être poussés vers les autres clients esclaves en les choisissant de façon aléatoire.

Par « pousser » (« push » en anglais) il faut comprendre un mode de diffusion où le récepteur des paquets reçoit ceux-ci sans en avoir sollicité l’envoi, une fois qu’il s’est fait connaître de l’émetteur.

Chaque paquet, encore appelé « chunk », peut être un paquet vidéo ayant une taille comprise entre 256 ko et 2,56 Mo, par exemple de IM.

Le procédé peut également comporter l’étape consistant à amener les clients esclaves du réseau privé, autres que le client esclave prioritaire, à s’adresser au client esclave prioritaire pour recevoir les paquets du contenu à diffuser en cas de défaillance du client maître.

Le procédé peut comporter l’étape consistant à répertorier comme client maître le premier terminal du réseau privé à se connecter au serveur de gestion pour demander la réception du contenu à diffuser. De préférence toutefois, le serveur de gestion vérifie que la bande passante dont dispose ce terminal est suffisante pour recevoir les paquets vidéo selon le premier protocole depuis le serveur distant, avant de le répertorier comme client maître.

Le procédé peut comporter l’étape consistant à répertorier comme client esclave prioritaire le deuxième terminal du réseau privé à se connecter au serveur de gestion pour demander la réception du contenu à diffuser.

On peut répertorier dans le serveur de gestion au moins une information concernant la localisation des terminaux au sein du réseau privé et utiliser cette information pour décider, pour chaque terminal, de l’attribution des adresses des autres terminaux à interroger par ce terminal pour recevoir des paquets du contenu.

On peut répertorier dans le serveur de gestion au moins une information concernant les ressources dont disposent les terminaux au sein du réseau privé et utiliser cette information pour décider de l’attribution d’un profil à un terminal se connectant au serveur de gestion, notamment décider si ce terminal doit devenir client maître, client esclave prioritaire ou client esclave.

Le serveur de gestion peut ainsi transmettre à un terminal du réseau privé des informations relatives au protocole d’échange d’informations à mettre en œuvre avec les autres clients du réseau privé pour récupérer les paquets du contenu à diffuser, et/ou les diffuser.

Le serveur de gestion peut être agencé pour vérifier, lors de la connexion d’un terminal au serveur de gestion, si ce terminal dispose de ressources supérieures à celle du client maître avec lequel il est destiné à échanger pour recevoir les paquets du contenu. Par « ressources supérieures » il faut comprendre qu’en raison de la bande passante et/ou des performances matérielles, ce terminal pourra jouer le rôle de client maître d’une manière plus favorable pour les autres clients esclaves qui recevront leurs paquets de celui-ci, que le client maître actuel. Si c’est le cas, le serveur de gestion peut être agencé pour répertorier ce terminal comme nouveau client maître en substitution de l’ancien, et prévenir cet ancien client maître qu’il n’en a plus le statut. Le serveur de gestion peut basculer le statut de l’ancien client maître en client esclave prioritaire ou en client esclave, selon les ressources dont il dispose et celles des autres clients du swarm. Par « swami » on désigne l’ensemble des clients qui échangent entre eux des données pour recevoir des paquets d’un même contenu.

Ainsi, le procédé peut comporter l’étape consistant à déterminer, lors d’une connexion au serveur de gestion d’un terminal du réseau privé, si ce terminal peut accéder directement, en raison de la bande passante disponible, aux paquets du contenu à diffuser, et dans l’affirmative amener ce terminal à recevoir directement lesdits paquets du serveur de contenu ou par une connexion de pair à pair avec d’autres terminaux sans recevoir de paquets poussés.

Il peut être avantageux qu’au moins un client esclave ou un client esclave prioritaire soit partagé entre deux swarms. Le choix du client partagé est effectué par le serveur de gestion de préférence en fonction du degré d’avancement dans le téléchargement de chacun des deux swarms, en choisissant de préférence au moins un client esclave ou esclave prioritaire parmi celui des deux swarms qui est le plus avancé dans son téléchargement.

Cela peut permettre, lorsqu’un swarm est en avance de téléchargement par rapport à un autre swarm, aux clients de cet autre swarm de récupérer plus facilement les paquets du contenu.

Dans un exemple de mise en œuvre, seul un client esclave ou esclave prioritaire est partagé entre deux swarms. Ce client partagé peut être choisi en fonction du décalage de temps entre les téléchargements du contenu, et peut notamment être choisi parmi les clients d’un swarm en avance de téléchargement par rapport aux clients de l’autre swarm.

Un client maître peut être agencé pour attendre une durée prédéfinie pour recevoir un paquet du contenu des autres terminaux, notamment clients maîtres, avec lesquels il échange des données, avant de contacter le serveur de contenu pour obtenir ce paquet.

En présence d’un ou plusieurs terminaux ayant une bande passante suffisante pour recevoir les paquets directement du serveur de contenu et échanger des paquets avec au moins un client maître, mais n’échangeant de paquets avec aucun client esclave, le ou les clients maîtres peuvent être agencés pour chercher en priorité à recevoir les paquets du contenu d’un ou plusieurs de ces terminaux qui sont les plus avancés dans le téléchargement du contenu. Si les paquets ne peuvent être obtenus de ces terminaux dans un délai prédéfini, alors le client maître peut contacter le serveur de contenu.

Le serveur de gestion peut être dédié à plusieurs réseaux privés distincts.

Le réseau privé comporte par exemple entre 3 et 10 000 terminaux, mieux entre 10 et 10000 terminaux.

Le nombre de terminaux esclaves vers lesquels un contenu est poussé par un client maître est par exemple compris entre 2 et 50.

Le contenu à diffuser est par exemple un contenu vidéo, notamment une intervention filmée en direct ou en léger différé.

L’invention a encore pour objet un produit programme d’ordinateur, notamment pour la mise en œuvre du procédé selon l’invention tel que défini ci-dessus, comportant, sur un support informatique ou à télécharger, un ensemble d’instructions lisibles par un serveur de gestion, ces instructions amenant lors de l’exécution du programme le serveur de gestion à :

- Lors de la réception d’une requête provenant d’un premier terminal d’au moins un réseau privé, la bande passante avec laquelle ce premier terminal peut se connecter à un serveur de contenu étant suffisante pour permettre la diffusion du contenu à ce premier terminal par une connexion directe de celui-ci au serveur de contenu, répertorier ce terminal comme client maître et amener ce terminal à recevoir le contenu à diffuser notamment via sa connexion au serveur de contenu,

- amener ce premier terminal à pousser au moins une partie des paquets du contenu à diffuser reçus, vers au moins un autre terminal du réseau privé,

- lors de la réception d’une requête provenant d’un autre terminal du réseau privé, la bande passante avec laquelle cet autre terminal peut se connecter au serveur de contenu étant insuffisante pour permettre la diffusion du contenu à cet autre terminal, répertorier ce terminal comme client esclave et amener ce terminal à recevoir le contenu à diffuser du client maître et/ou d’au moins un autre terminal esclave du réseau privé par échanges de données au sein du réseau privé.

L’invention pourra être mieux comprise à la lecture de la description détaillée qui va suivre, d’un exemple de mise en œuvre non limitatif de l’invention, et à l’examen du dessin annexé, sur lequel :

- La figure 1 illustre les liaisons pouvant exister entre différentes entités d’une organisation, un serveur de contenu distant et un serveur de gestion,

- la figure 2 donne un exemple d’attribution de profil de client, aux utilisateurs se connectant au serveur de gestion,

- la figure 3 illustre un exemple d’échanges de données au sein de deux terminaux du réseau privé, du serveur de contenu distant et du serveur de gestion, et

- la figure 4 illustre la mise en place de différents protocoles de diffusion au sein d’une même entité.

On a représenté à la figure 1 un exemple d’organisation comportant plusieurs entités cherchant à recevoir un contenu diffusé par un serveur de contenu CDN, encore appelée source de contenu ou serveur distant.

Un serveur de gestion EB est prévu pour assurer la mise en œuvre de l’invention.

Dans l’exemple considéré, le serveur de contenu CDN peut communiquer avec N branches de l’organisation, regroupant chacune plusieurs agences, pouvant se décomposer elles-mêmes en plusieurs divisions.

Chacune des branches regroupe par exemple plus de 1000 terminaux, encore appelés stations de travail, et communique avec le serveur CDN par une liaison à haut débit par exemple d’un réseau public, tandis que certaines agences communiquent avec leurs divisions par un réseau privé ayant une liaison à faible débit, par exemple 2,5 ou 3MB/s. Chaque agence regroupe par exemple entre 10 et 30 terminaux. Sur la figure 1 on a représenté une « division 1 » regroupant six terminaux. Le nombre de terminaux n’est donné qu’à titre illustratif et l’invention s’applique à tout type d’organisation indépendamment du nombre de terminaux et la répartition de ceux-ci au sein de l’organisation.

Chaque branche peut récupérer du serveur CDN le contenu multimédia à diffuser.

Les réseaux privés des différentes branches peuvent communiquer entre eux par exemple par le réseau public par une liaison à haut débit.

Le serveur de gestion EB est par exemple externe aux réseaux privés de l’organisation, comme illustré, et peut communiquer avec ceux-ci par le réseau public.

Chaque terminal de l’organisation peut se connecter au serveur de gestion EB, à l’aide de son navigateur internet.

Pour recevoir le contenu diffusé par le serveur CDN, les terminaux se connectent d’abord au serveur de gestion EB, lequel décide du protocole qui est mis en œuvre pour qu’un terminal reçoive les paquets vidéo du contenu diffusé par le serveur CDN.

Le choix de ce protocole s’effectue en fonction des ressources, notamment de la bande passante, dont dispose ce terminal.

Deux protocoles de transmission différents, appelés pour la suite EB_Protocol (encore appelé V2V) et EB_SPV_Protocol sont mis en œuvre selon la disponibilité de la bande passante.

Le protocole d’échange V2V est mis en œuvre pour faciliter la réception des paquets par les branches et soulager le serveur CDN. Ce protocole d’échange V2V est du type pair à pair et de préférence conforme à l’enseignement de la demande de brevet EP 3 156 920 Al au nom de la demanderesse. Il consiste à servir le contenu à au moins un client en mode client/serveur, sous un format permettant sa diffusion ultérieure en mode P2P.

Le serveur de gestion EB sélectionne pour chaque utilisateur, parmi tous ceux qui regardent le même contenu, la meilleure liste d’utilisateurs qui pourront récupérer le contenu avec la meilleure qualité de service. Cette liste est établie sur la base de plusieurs paramètres dont la géolocalisation, la qualité de connexion et le réseau de connexion, la machine et le navigateur utilisé, entre autres possibilités. En l’absence d’une contrainte forte de temps réel, contrairement à la diffusion en direct de chaînes de télévision, la politique protocolaire de récupération des paquets vidéo est beaucoup plus orientée vers une récupération entre utilisateurs avec des temps d’attente plus élevés.

Le protocole EB_SPV_Protocol est mis en œuvre pour tenir compte de la faible bande passante disponible et permet de diffuser une partie du contenu en mode poussé depuis un terminal maître vers un ou plusieurs terminaux esclaves, sous un format permettant de les échanger en mode P2P entre les terminaux esclaves.

Le serveur de gestion EB est agencé pour déterminer avec quel protocole chaque terminal de l’organisation peut ou doit opérer.

Il peut se fonder pour cela sur plusieurs techniques, dont la mesure de la bande passante du client à sa connexion. Si la bande passante est suffisante, le serveur de gestion amène ce client à opérer selon le protocole V2V.

Une autre méthode, préférée, est la géolocalisation du client, comme cela va maintenant être décrit en se référant à la figure 2.

Sur cette figure, l’étape 11 « Peers_connexion » correspond à la connexion d’un client, par exemple après le début 10 de la diffusion du contenu par le serveur CDN.

A l’étape 12 « Geolocalize_Viewers », le client est localisé, grâce à son adresse IP. Par interrogation d’une base de données DB représentée schématiquement à la figure 1, le serveur de gestion EB peut savoir à l’étape 13 si le client relève d’une zone à bande passante suffisante ou non, et peut comparer les ressources dont disposent les terminaux, de façon à privilégier dans le rôle de client maître ceux disposant des meilleures ressources.

Si la bande passante est suffisante, ce qui correspond à l’étape 14 « Join_swarm », le terminal en question peut rejoindre le « swami » et recevoir les paquets par le protocole V2V.

Si la bande passante n’est pas suffisante, ce qui correspond à l’étape 15 « Join_swarm », alors en fonction du nombre de terminaux du même réseau privé s’étant déjà connectés au serveur de gestion EB, le serveur de gestion EB détermine à l’étape 16 le profil du terminal dans le cadre de la mise en œuvre du protocole EB_SPV_Protocol.

Lorsque le terminal est seul, c’est-à-dire que le « swami » est réduit à un, il se voit attribuer le profil de client maître SPV à l’étape 17 « viewer=SPV ».

En présence d’un seul autre terminal déjà connecté, qui est donc client maître, c’est-à-dire que la taille du « swami » est égale à deux, ce terminal se voit attribuer à l’étape 18 le profil d’un client esclave prioritaire « Viewer=SPV’ », sauf s’il dispose de meilleures ressources.

En présence de plus de deux autres terminaux déjà connectés, c’est-à-dire d’un client maître et d’un client esclave prioritaire, ce terminal se voit attribuer le profil d’un client esclave à l’étape 19 « Viewer=SLV », sauf s’il dispose de meilleures ressources.

Le nombre de clients maîtres et de clients esclaves prioritaires peut varier selon la taille du réseau.

On va maintenant décrire de façon plus détaillée, en référence à la figure 3, un exemple d’échanges de données entre deux terminaux Viewerl et Viewer2 du réseau privé, le serveur de gestion EB, la base de données DB, et le serveur de contenu CDN.

L’étape 20 correspond à une demande de connexion « Join() » adressée par le terminal Viewerl au serveur de gestion EB « EB_Server_Manager ».

Le serveur EB interroge à l’étape 21 la base de données DB « geoloc_Database », ce qui correspond aux échanges « Check_localization() » « Send_Localization() », et détermine au vu de l’adresse IP ou d’un identifiant autre du client si, compte-tenu de la localisation de l’utilisateur, la bande passante est suffisante.

Si la bande passante est suffisante « Check_Ressources(sufficient) », le serveur de gestion EB en informe l’utilisateur à l’étape 22, et lui assigne dans cet exemple le profil de client maître SPV « Assign_Profile(SPV) » et l’informe qu’il va mettre en œuvre le protocole V2V « EB_Protocol(on) ».

L’utilisateur Viewerl répond en demandant au serveur de gestion EB une liste d’utilisateurs à l’étape 23 « Get_Viewer_List() », avec lesquels il va pouvoir échanger.

L’utilisateur Viewerl obtient en réponse du serveur de gestion EB à l’étape 24 la liste des utilisateurs avec lesquels il peut échanger des paquets du contenu par mise en œuvre du protocole V2V « Send_Viewer_list() ».

L’utilisateur Viewerl opère alors selon un mode V2V (« EB_Protocol»). Cela comprend l’obtention de paquets à l’étape 25 auprès du serveur de contenu CDN « Get_Chunk() », la réception de ceux-ci à l’étape 26 « Send_chunk() », ainsi que l’obtention de paquets auprès d’autres utilisateurs clients maîtres notamment.

Pour cela, chaque client maître attendra une durée prédéfinie pour recevoir un chunk manquant des autres clients maîtres, et dans le cas contraire, il le téléchargera directement du serveur de contenu.

A titre d’illustration, l’étape 27 correspond à une requête d’obtention d’un paquet manquant auprès de l’un des utilisateurs de la liste communiquée à l’étape 23, à savoir l’utilisateur Viewer2 sur la figure 3. Le paquet correspondant est communiqué à l’étape 28. L’utilisateur Viewerl peut également transmettre à d’autres clients de la liste des paquets manquants, ce qu’on a illustré par les étapes 29 et 30. L’étape 29 correspond à une demande par le terminal Viewer2 d’un paquet au terminal Viewerl (requête Get_Chunk(ID15)) et l’étape 30 à l’envoi par le terminal Viewerl de ce paquet (Send_Chunk(ID15)).

Si la bande passante dont dispose le terminal Viewer2 est insuffisante pour une mise en œuvre satisfaisante du protocole V2V ci-dessus, alors le serveur de gestion EB impose un mode de diffusion du contenu selon le protocole EB_SPV_Protocol, et en informe le terminal Viewer 2 par le message 32 (« EB_SPV_Protocol(On) »). Ce protocole implique l’existence d’au moins un terminal « maître », encore appelé « Super Viewer » (SPV) pour assurer un rôle de serveur interne vis-à-vis d’un ou plusieurs terminaux esclaves, encore appelés « Slave Viewer » ou SLV. Dans l’exemple illustré, il s’agit du terminal Viewerl. Son rôle sera de pousser les paquets vidéo reçus aux autres terminaux composant son « swarm». Ce terminal maître est ici supposé déjà exister lors de la connexion du client Viewer2 à l’étape 31 au serveur de gestion EB.

A l’étape 33 l’utilisateur Viewer2 demande « Get_Viewer_list() » la liste des utilisateurs composant le swarm au serveur de gestion EB et l’obtient à l’étape 34 « Send_Vlist(VL[], SPV(ID)) ». Cette liste contient également l’adresse du client maître.

Le serveur de gestion prévient à l’étape 35 le client maître Viewerl « Hello() ». Ensuite, le client maître pousse « Push_Chunk() » les paquets aux étapes 36i, 302, ... au terminal Viewer2, au fur et à mesure qu’ils sont disponibles et capables d’être reçus par ce client esclave Viewer2.

Si lors de la demande de connexion du terminal Viewer2 à l’étape 31, le serveur de gestion EB détermine que les ressources et en particulier la bande passante est suffisante, il informe le terminal Viewer2 de l’état du swarm à l’étape 37 et lui attribue un profil à l’étape 38, en l’espèce celui de client esclave prioritaire SPV’ « Assign Profile(SPV’) » et lui signifie que le protocole de diffusion est le protocole EB_SPV_Protocol « EB_SPV_Protocol(on) ».

On suppose ici que les ressources du terminal Viewer2 ne sont pas meilleures que celles du client maître Viewerl « Swarm_state(Res_V2= R_SPV).

Le terminal Viewer2 demande alors au serveur de gestion EB à l’étape 39 la liste des utilisateurs, qu’il obtient à l’étape 40.

Ensuite, le terminal Viewer2 peut se signaler au client maître à l’étape 41, et obtient aux étapes 42i, 422, ... les paquets du contenu (« chunks »), délivrés en mode « push » par le terminal Viewerl.

Si, suite à la connexion à l’étape 31, le serveur de gestion EB détermine que les ressources du terminal Viewerl sont meilleures que celle d’un client maître existant « Swarm_state(Res_V2>R_SPV) », en l’espèce Viewerl, alors le serveur de gestion EB attribue à l’étape 43 au terminal Viewer2 le profil d’un client maître SPV « Assign_Profile(SPV) » et lance le protocole EB_SPV_Protocol à l’étape 44 « EB_SPV_Protocol(on) ».

Le client maître Viewer2 demande alors au serveur de gestion EB à l’étape 45 la liste des utilisateurs « Get_Viewer_list() ».

Le serveur de gestion EB informe à l’étape 46 le terminal Viewerl qu’il cesse d’être client maître et que le nouveau client maître est le terminal Viewer2 « New_SPV(ID=V2) ».

Le serveur de gestion EB adresse ensuite à l’étape 47 au terminal Viewer2 la liste des clients du swarm « Send_Viewer_List() ».

Le terminal Viewer2 requiert du serveur de contenu à l’étape 48 des paquets du contenu, qu’il obtient à l’étape 49.

Ensuite, le terminal Viewerl se signale à l’étape 49 au client maître Viewer2 et peut recevoir en mode « push » les paquets du contenu aux étapes 50i, 502, ...

La librairie avec les différents protocoles V2V et EB_SPV_Protocol peut être en Javascript et récupérée sur le navigateur du terminal au moment où il se connecte sur la page web pour récupérer le flux, à savoir celle du serveur de gestion EB. Le choix du protocole et le profil de l’utilisateur sont fixés après le premier échange avec le serveur de gestion EB. Le profil du terminal ainsi que le protocole utilisé peuvent changer durant le visionnage du contenu, en fonction des directives du serveur de gestion EB.

Selon les règles choisies, le choix par le serveur de gestion EB du ou des terminaux maîtres SPV peut se faire par ordre de connexion au réseau, comme illustré à la figure 2, ou selon ses ressources, comme décrit en référence à la figure 3.

La diffusion du contenu à plusieurs terminaux esclaves peut s’opérer le cas échéant via plusieurs terminaux maîtres SVP, en fonction de différents paramètres tels que la bande passante, la taille du réseau, le type d’encodage du contenu, entre autres.

Une fois que le ou les terminaux maîtres SPV sont déterminés, le profil de terminal esclave SLV est attribué à l’ensemble des terminaux constituant son swarm.

L’un de ces terminaux esclaves peut néanmoins se voir attribuer un profil de client esclave prioritaire SPV’ et devenir privilégié pour recevoir plus de paquets vidéo du client maître SPV que les autres clients esclaves, de manière à constituer une solution d’appui pour remplacer le terminal maître SPV en cas de « plantage » ou de déconnexion de celui-ci, assurant ainsi la continuité de la diffusion et évitant que la vidéo ne se fige chez les autres terminaux esclaves SLV.

Sur la figure 1, on a représenté le réseau privé correspondant à la « division 1 », formé d’un terminal maître SPV1 qui reçoit ses paquets du serveur CDN par le protocole V2V.

Il adresse les paquets selon le protocole EB_SPV_Protocol à un client esclave prioritaire SPV’ 1, et à quatre autres clients esclaves SLV1 à SLV4, ce qui est matérialisé par les flèches EB SPV. Entre les terminaux SLV1 à SLV4 et SPV’l, un échange selon le protocole V2V peut s’opérer, ce qui est matérialisé par les flèches V2V.

Selon la taille du réseau et la bande passante disponible, un réseau peut nécessiter la présence de plusieurs terminaux esclaves prioritaires SPV’.

Un exemple de mise en œuvre des différents protocoles et de distribution des profils au sein d’une même entité est illustré à la figure 4.

Au sein d’une même division, les terminaux maîtres SPV peuvent échanger les paquets entre eux à travers le protocole V2V, comme illustré par les flèches V2V pour les clients SPV1 àSPV3.

Le terminal maître SPV 1 opère selon le protocole EB_SPV_Protocol vis-à-vis de terminaux esclaves SLV1 à SLV5 et SPV’l et SPV’2 et pousse (« Push_packets ») ainsi les paquets du contenu vidéo à ces terminaux esclaves.

De même, le terminal maître SPV2 pousse (« Push_packets ») les paquets à un ensemble de terminaux comportant cinq terminaux esclaves SLV1 à SLV5 et deux terminaux esclaves prioritaires SPV’ 1 et SPV’2.

Le terminal maître SPV3 pousse (« Push_packets ») les paquets à un ensemble de terminaux comportant cinq terminaux esclaves SLV1 à SLV5 et un terminal esclave prioritaire SPV’ 1.

Au sein de chaque « swarm », les terminaux esclaves SLV échangent ce qu’ils ont reçu via le protocole V2V.

Chaque client maître SPV reçoit les paquets du contenu du serveur de contenu et des autres clients maîtres avec lesquels il échange des paquets.

Chaque client maître peut attendre une durée prédéfinie un paquet manquant des autres clients maîtres. Si au terme de cette durée, les paquets demandés sont toujours manquants, alors il peut le demander au serveur de contenu CDN.

Dans un exemple, la bande passante avec laquelle les clients maîtres échangent les paquets entre eux ou les reçoivent du serveur de contenu est par exemple de 60 Mb/s, et le contenu est découpé en paquets de IM. On a par exemple 60 utilisateurs de profil client esclave et trois clients maîtres qui partagent les paquets selon le protocole EB_SPV. Les clients maîtres devront recevoir un chunk en 12 s pour assurer la fluidité du visionnage. Pour cela, un client maître attendra 4s pour recevoir le chunk manquant des autres clients maîtres, et dans le cas contraire, il le téléchargera directement du serveur de contenu CDN.

On a illustré à la figure 4 la possibilité pour deux swarms de partager un utilisateur, par exemple un client esclave ou un client esclave prioritaire.

Ainsi, le client esclave prioritaire SVP’ 1 du swarm S2 échange des paquets à la fois des autres clients du swarm S2 et avec les clients du swarm S1, et le client esclave SLV3 du swarm S 3 échange des paquets à la fois des autres clients du swami S 3 ainsi que de ceux du swarm S2.

Le choix du client partagé est décidé dynamiquement par le serveur de gestion en fonction de l’avancement du téléchargement du contenu par chacun des swarms. Si parmi deux swarms, l’un d’entre entre est plus avancé dans son téléchargement, alors un client esclave ou esclave prioritaire de ce swarm est partagé avec un autre swarm.

On a également illustré à la figure 4 la possibilité d’un quatrième profil qui peut être présent sur le réseau, à savoir celui d’utilisateur ordinaire OV, qui correspond à un terminal ayant une bande passante suffisante pour obtenir le contenu du serveur de contenu CDN ainsi que pour échanger avec les clients maîtres SPV selon le protocole EB_SPV, mais qui ne sont connectés à aucun client esclave SLV.

De ce fait, et dans le cas où la bande passante est insuffisante, les clients maîtres auront la priorité pour recevoir les paquets des utilisateurs OV qui sont avancés dans le téléchargement, ainsi que du serveur de contenu CDN pour pouvoir servir à leur tour les clients esclaves qui leur sont connectés.

Ce fonctionnement a pour effet la présence de swarms plus avancés que d’autres. Les clients esclaves faisant partie de plus d’un swarm dissémineront ainsi les nouveaux chunks vers les swarms ayant du retard.

L’invention n’est pas limitée à l’exemple qui vient d’être décrit. Par exemple, le protocole V2V ou EB SPV peut prévoir un changement de résolution ou un basculement en mode audio selon la bande passante disponible.

Claims

REVENDICATIONS

1. Procédé de diffusion d’un contenu, notamment multimédia, depuis un serveur de contenu (CDN) dans au moins un réseau privé comportant au moins trois terminaux pouvant échanger des données entre eux, la bande passante avec laquelle au moins un terminal peut se connecter au serveur de contenu étant insuffisante pour permettre la diffusion du contenu sur chacun des terminaux par une connexion de chacun de ceux-ci au serveur de contenu (CDN), le procédé comportant les étapes consistant à :

a) Répertorier, notamment dans un serveur de gestion (EB), au moins l’un desdits terminaux comme client maître (SPV) et au moins deux autres desdits terminaux comme clients esclaves (SLV),

b) transmettre au moins une partie du contenu à diffuser à ce client maître (SPV), notamment via la connexion au serveur de contenu (CDN),

c) amener le client maître (SPV) à pousser au moins une partie du contenu à diffuser vers au moins l’un des clients esclaves (SLV) du réseau privé via les liaisons existant entre les terminaux au sein du réseau privé.
2. Procédé selon la revendication 1, dans lequel pour au moins un client esclave (SLV) n’ayant pas reçu les paquets nécessaires du contenu à diffuser du client maître (SPV), ce client esclave reçoit des paquets manquants d’au moins un autre client esclave en utilisant les liaisons existantes entre les clients esclaves au sein du réseau privé.
3. Procédé selon la revendication 1, la diffusion du contenu à diffuser entre les clients esclaves (SLV, SPV’) s’effectuant par un mécanisme de diffusion de pair à pair.
4. Procédé selon l’une des revendications 1 et 2, comportant l’étape consistant à répertorier au moins l’un desdits clients esclaves du réseau privé comme client esclave prioritaire (SPV’), et amener le client maître (SPV) à pousser les paquets du contenu à diffuser en priorité vers ce client esclave prioritaire (SPV’).
5. Procédé selon la revendication 3, comportant l’étape consistant à amener les clients esclaves (SLV) du réseau privé autres que le client esclave prioritaire à s’adresser au client esclave prioritaire (SPV’) pour recevoir les paquets du contenu à diffuser en cas de défaillance du client maître (SPV).
6. Procédé selon l’une quelconque des revendications précédentes, comportant l’étape consistant à répertorier comme client maître (SPV) le premier terminal du réseau privé à se connecter au serveur de gestion (EB) pour demander la réception du contenu à diffuser.
7. Procédé selon l’une quelconque des revendications précédentes, comportant l’étape consistant à répertorier comme client esclave prioritaire (SPV’) le deuxième terminal du réseau privé à se connecter au serveur de gestion (EB) pour demander la réception du contenu à diffuser.
8. Procédé selon l’une quelconque des revendications précédentes, comportant l’étape consistant à déterminer, lors d’une connexion au serveur de gestion (EB) d’un terminal du réseau privé, si ce terminal peut accéder directement, en raison de la bande passante disponible, aux paquets du contenu à diffuser, et dans l’affirmative amener ce terminal à recevoir directement lesdits paquets du serveur de contenu (CDN) ou par une connexion de pair à pair avec d’autres terminaux (OV1, OV2) sans recevoir de paquets poussés.
9. Procédé selon l’une quelconque des revendications précédentes, dans lequel le réseau privé comporte entre 3 et 10 000 terminaux, mieux entre 10 et 10000 terminaux.
10. Procédé selon l’une quelconque des revendications précédentes, dans lequel le contenu à diffuser est un contenu vidéo, notamment une intervention filmée en direct ou en léger différé.
11. Procédé selon l’une quelconque des revendications précédentes, dans lequel on répertorie dans le serveur de gestion (EB) au moins une information concernant la localisation des terminaux au sein du réseau privé et l’on utilise cette information pour décider, pour chaque terminal, de l’attribution des adresses des autres terminaux à interroger par ce terminal pour recevoir les paquets du contenu.
12. Procédé selon l’une quelconque des revendications précédentes, dans lequel on répertorie dans le serveur de gestion (EB) au moins une information concernant les ressources dont disposent les terminaux au sein du réseau privé et l’on utilise cette information pour décider de l’attribution d’un profil à un terminal se connectant, notamment décider si ce terminal doit devenir client maître (SPV), client esclave prioritaire (SPV’) ou client esclave (SLV).
13. Procédé selon l’une quelconque des revendications précédentes, dans lequel une partie au moins du contenu à diffuser est poussée par le client maître (SPV) vers des clients esclaves (SLV) du réseau privé choisis de façon aléatoire.
14. Procédé selon l’une quelconque des revendications précédentes, dans lequel le serveur de gestion (EB) transmet à un terminal du réseau privé des informations relatives au protocole d’échange d’informations (EB_Protocol() ; EB_SPV_Protocol()) à mettre en œuvre avec les autres clients du réseau privé pour récupérer les paquets du contenu à diffuser et/ou les diffuser.
15. Procédé selon l’une quelconque des revendications précédentes, dans lequel le serveur de gestion (EB) est dédié à plusieurs réseaux privés distincts.
16. Procédé selon l’une quelconque des revendications précédentes, le serveur de gestion (EB) étant agencé pour vérifier, lors de la connexion d’un terminal au serveur de gestion, si ce terminal dispose de ressources supérieures à celle du client maître avec lequel il est destiné échanger pour recevoir les paquets du contenu, et dans l’affirmative répertorier ce terminal comme nouveau client maître en substitution de l’ancien.
17. Procédé selon l’une quelconque des revendications précédentes, au moins un client esclave (SLV) ou un client esclave prioritaire (SPV’) étant partagé entre deux swarms, le choix du client partagé étant effectué par le serveur de gestion de préférence en fonction du degré d’avancement dans le téléchargement de chacun des deux swarms, en choisissant de préférence au moins un client esclave ou esclave prioritaire parmi celui des deux swarms qui est le plus avancé dans son téléchargement.
18. Procédé selon l’une quelconque des revendications précédentes, le client maître (SPV) étant agencé pour attendre une durée prédéfinie pour recevoir un paquet du contenu des autres terminaux, notamment des autres clients maîtres, avec lesquels il échange des données, avant de contacter le serveur de contenu (CDN) pour obtenir ce paquet.
19. Procédé selon l’une quelconque des revendications précédentes, dans lequel en présence d’un ou plusieurs terminaux (OV1, OV2) ayant une bande passante suffisante pour recevoir les paquets directement du serveur de contenu (CDN) et échanger des paquets avec au moins un client maître (SPV), mais n’échangeant de paquets avec aucun client esclave (SLV), le ou les clients maîtres (SPV) sont agencés pour chercher en priorité à recevoir les paquets du contenu d’un ou plusieurs de ces terminaux (OV1, OV2) qui sont les plus avancés dans le téléchargement du contenu.
20. Produit programme d’ordinateur, notamment pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes, comportant, sur un support informatique ou à télécharger, un ensemble d’instructions lisibles par un serveur de gestion (EB), ces instructions amenant lors de l’exécution du programme le serveur de gestion à :

- Lors de la réception d’une requête provenant d’un premier terminal d’au moins un réseau privé, la bande passante avec laquelle ce terminal peut se connecter au

5 serveur de contenu étant suffisante pour permettre la diffusion du contenu à ce premier terminal par une connexion directe de celui-ci au serveur de contenu, répertorier ce terminal comme client maître (SPV),

- amener ce premier terminal (SPV) à pousser au moins une partie des paquets du contenu à diffuser reçus, vers au moins un autre terminal (SLV ; SPV’) du réseau privé,

10 - lors de la réception d’une requête provenant d’un autre terminal du réseau privé, la bande passante avec laquelle cet autre terminal peut se connecter au serveur de contenu étant insuffisante pour permettre la diffusion du contenu à cet autre terminal, répertorier ce terminal comme client esclave (SLV) et amener ce terminal à recevoir le contenu à diffuser du client maître et/ou d’au moins un autre terminal esclave du réseau privé

15 par échanges de données au sein du réseau privé.