Brevet FR3094164A1 — publié le 20200925

Description Titre de l'invention : Procédé d'obtention d'un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu Domaine technique 100011 La présente invention concerne un procédé d'obtention d'un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu. 100021 L'invention trouve avantageusement (mais pas exclusivement) application dans le cadre de la lecture d'un flux multimédia comprenant de tels segments de données. Technique antérieure [0003] De façon connue, un réseau de diffusion de contenu (Content Delivery Network, abrégé en CDN dans la suite) comprend un ou plusieurs serveurs reliés en réseau à travers Internet et qui coopèrent afin de mettre à disposition du contenu ou des données à des dispositifs clients détenus par des utilisateurs. [0004] Un même segment de données peut être disponible auprès de plusieurs CDNs concurrents. Autrement dit, un dispositif client peut avoir le choix entre plusieurs CDNs pour obtenir un ce segment de données. [0005] Il pourrait être envisagé de sélectionner parmi les différents CDNS disponibles le CDN offrant la meilleure qualité de transmission de contenu au dispositif client. [0006] Si cette approche est intéressante à court terme, elle l'est beaucoup moins à moyen ou long terme. En effet, la qualité de transmission offerte par un CDN est susceptible de varier fortement dans le temps, si bien qu'un CDN considéré comme optimal en termes de qualité de transmission à un instant donné peut devenir sous-optimal à un instant ultérieur. Exposé de l'invention [0007] L'invention vise à permettre à un dispositif client de choisir un CDN auprès de qui obtenir un segment de données parmi plusieurs CDNs disponibles, en tenant compte des conditions de transmission de données entre ces CDNs et le dispositif client, mais d'une manière plus flexible qu'avec l'approche évoquée en introduction. [0008] Il est donc proposé, selon un premier aspect de l'invention, un procédé d'obtention d'un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu, le procédé comprenant des étapes de : - pour chaque réseau de la pluralité de réseaux, calcul d'un score associé au réseau indicatif d'une qualité de transmission de données depuis le réseau au dispositif client, - tirage aléatoire d'un réseau dans la pluralité de réseaux, le tirage aléatoire étant 2 adapté pour qu'une probabilité de tirer un réseau dc la pluralité associé à un score indicatif d'une première qualité dc transmission soit supérieure à une probabilité de tirer un réseau dc la pluralité associé à un score indicatif d'une deuxième qualité de transmission inférieure à la première qualité de transmission, - sollicitation du réseau tiré pour que le dispositif client obtienne le segment de données du réseau tiré. [0009] Le procédé selon le premier aspect de l'invention peut également comprendre les ca- ractéristiques ou étapes suivantes, prises seules ou combinées entre elles lorsque cela est techniquement possible. [0010] Le tirage aléatoire peut dépendre d'un paramètre d'exploration, le tirage aléatoire étant alors adapté pour : - faire croître la probabilité dc tirer le réseau associé au score le plus élevé parmi tous les scores calculés relativement aux probabilités de tirer les autres réseaux de la pluralité, lorsque la valeur du paramètre d'exploration varie dans un premier sens, et/ ou - faire décroître la probabilité dc tirer le réseau associé au score le plus élevé parmi tous les scores calculés relativement aux probabilités de tirer les autres réseaux dc la pluralité, lorsque la valeur du paramètre d'exploration varie dans un deuxième sens opposé au premier sens. [0011] Le procédé peut comprendre en outre des étapes de - évaluation d'un risque de dégradation de conditions de traitement par le dispositif client d'un ensemble de données comprenant le segment de données, telles que des conditions de conditions de lecture par le dispositif client d'un flux multimédia comprenant le segment de données, - modification de la valeur du paramètre d'exploration d'après le risque de dégradation évalué. [0012] Au moins deux réseaux de la pluralité, voire tous les réseaux de la pluralité, ont de préférence des probabilités non nulles d'être tirés. [0013] Les étapes de calcul de score, de tirage aléatoire, et de sollicitation sont de préférence répétées pour plusieurs segments de données appartenant à un ensemble de données tel qu'un flux multimédia ou un fichier. [0014] De préférence, le segment de données appartient à un ensemble de données, et les scores sont initialisés à des valeurs initiales avant que le dispositif n'obtienne un quelconque segment de l'ensemble de données. [0015] Par exemple, la valeur initiale du score d'un réseau de la pluralité est déterminée en fonction d'informations indicative d'une qualité de transmission de segments de données depuis le même réseau à au moins un dispositif tiers différent du dispositif client. 3 [0016] Ces informations sont par exemple fournies au dispositif client par un serveur d'agrégation apte à communiquer avec chaque dispositif tiers. [0017] Si un premier réseau de la pluralité a déjà été sollicité par le dispositif client pour obtenir au moins un segment de données appartenant à l'ensemble de données depuis r initialisation, le score de cc premier réseau est de préférence mis à jour en tenant compte de la qualité de transmission effective d'au moins un segment transmis par le premier réseau au dispositif client. [0018] Si par ailleurs un deuxième réseau de la pluralité n'a pas encore été sollicité par le dispositif client pour obtenir de segment de données appartenant à l'ensemble de données depuis l'initialisation, le score de ce deuxième réseau est de préférence mis à jour en tenant compte de la valeur du score du premier réseau. [0019] Le procédé peut comprendre le calcul d'une heuristique de bande passante indicative d'une bande passante disponible pour la transmission de segments de données par un réseau de la pluralité au dispositif client, le score associé à cc réseau dépendant de l'heuristique de bande passante calculée. [0020] A titre alternatif ou complémentaire, le procédé peut comprendre le calcul d'une heu- ristique d'erreurs de transmission associée à un réseau de la pluralité, l'heuristique d'erreurs de transmission étant indicative d'erreurs de transmission de segments de données ayant préalablement été demandés par le dispositif client au réseau, le score associé à ce réseau dépendant de l'heuristique d'erreurs de transmission calculée. [0021] De préférence, l'heuristique d'erreurs de transmission associée à un réseau de la pluralité varie de manière à rendre moins probable le tirage aléatoire du réseau, lorsque le réseau échoue à transmettre un segment de données au dispositif client. [0022] De préférence, l'heuristique d'erreurs de transmission associée à un réseau de la pluralité varie d'une quantité qui elle-même croît avec un nombre d'erreurs de transmission de segments passées associé à ce réseau. [0023] De préférence, l'heuristique d'erreurs de transmission associée à un réseau varie de manière à rendre plus probable le tirage aléatoire du réseau, lorsque le réseau réussit à transmettre un segment de données au dispositif client. [0024] De préférence, l'heuristique d'erreurs de transmission d'un réseau varie de manière à rendre plus probable le tirage aléatoire du réseau, lorsqu'aucun segment de données n'est transmis depuis le réseau au dispositif client dans une période de temps prédéterminée. [0025] Le score associé à un réseau peut en outre dépendre d'un poids prédéfini propre à ce réseau, ce poids étant par exemple une constante. [0026] 11 est également proposé, selon un deuxième aspect de l'invention, un procédé de lecture par un dispositif client d'un flux multimédia comprenant une pluralité de segments de données, le procédé comprenant l'obtention d'au moins un des segments de données au moyen du procédé selon le premier aspect de l'invention. [0027] TI est également proposé, selon un troisième aspect de l'invention, un produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon le premier aspect ou le deuxième aspect de l'invention, lorsque ce programme est exécuté par un dispositif client. [0028] TI est également proposé, selon un quatrième aspect de l'invention, un support lisible par un dispositif client sur lequel est stocké un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon le premier aspect ou selon le deuxième aspect de l'invention. [0029] TI est également proposé, selon un cinquième aspect de l'invention, un dispositif client destiné à obtenir un segment de données, le dispositif client comprenant une interface de communication pour communiquer avec une pluralité de réseaux de diffusion de contenu, et une unité de traitement configurée pour commander la mise en oeuvre des étapes du procédé selon le premier aspect ou selon le deuxième aspect de l' invention. Brève description des dessins [0030] D'autres caractéristiques, buts et avantages de l'invention ressortiront de la des- cription qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels : [0031] [fig.1] [0032] La figure 1 représente de manière schématique un dispositif client selon un mode de réalisation de l'invention et plusieurs réseaux de diffusion de contenu. [0033] [fig.2] [0034] La figure 2 est un organigramme d'étapes d'un procédé d'obtention d'un segment de données selon un mode de réalisation de l'invention. [0035] Sur l'ensemble des figures, les éléments similaires portent des références identiques. Description des modes de réalisation 100361 On a représenté en figure 1 un dispositif client 1 apte à communiquer avec une pluralité de réseaux de diffusion de contenu (CDNs). Seuls deux CDNs référencés CDN1 et CDN2 sont représentés sur cette fleure, mais on considéra plus généralement dans la suite un ensemble de N CDNs indicés de 1 à N. 100371 Comme indiqué schématiquement sur la figure I, chaque CDN comprend au moins un serveur, étant entendu que ces CDNs peuvent comprendre plus qu'un seul serveur, comme évoqué en introduction. 100381 Chaque CDN stocke des segments de données appartenant à un même ensemble de données. Par exemple, tous les CDNs comprennent l'ensemble de données complet, c'est-à-dire tous les segments de cet ensemble de données. [0039] L'ensemble de données peut être un fichier de données, destiné à être référencé dans un système de fichiers en vue d'un accès à ce fichier. Alternativement, l'ensemble de données est un flux multimédia se présentant sous la forme d'un ou plusieurs fichiers. [0040] Les segments de l'ensemble de données considéré sont ordonnés entre eux. Dans le cas d'un ensemble de données de type fichier, les segments correspondent à différentes portions du binaire formant le fichier, chaque portion ayant une adresse relative (offset) qui lui est propre par rapport à l'adresse de début du fichier. [0041] Les segments d'un flux multimédia sont temporellement ordonnés : chaque segment est associé à ou comprend un horodatagc qui lui est propre. Les différents horodatages permettent de déterminer dans quel ordre les différents segments du flux multimédia doivent être lus par un lecteur. [0042] Dans le cas particulier d'un flux multimédia en direct (« live ») et plus généralement d'un flux DVR, seulement une fenêtre temporelle correspondant aux N dernière minutes, ou M dernières heures, est disponible sur les réseaux de contenus. Dans ce cas on entend par ensemble de données la collection des données multimédia qui forment cette fenêtre temporelle. Lorsqu'un nouveau segment vidéo est généré par un encodeur live, il est rajouté à l'ensemble de données alors que le segment le plus ancien expire et est retiré de l'ensemble de données. [0043] Quelle que soit la forme que revêt l'ensemble de données, on considère dans le présent texte qu'un segment de données désigne une portion de l'ensemble de données qui est susceptible d'être transmise au dispositif client 1 indépendamment des autres segments de données du même ensemble de données. [0044] Le dispositif client 1 comprend par ailleurs une interface de communication 2 pour communiquer avec les différents CDNs, et notamment recevoir de ces CDNs des segments de l'ensemble de données. [0045] Le dispositif client 1 comprend par ailleurs une mémoire 4 pour mémoriser des segments reçus via l'interface de communication 2, et une unité de traitement 6 configurée pour traiter les segments de données contenus dans la mémoire 4. [0046] L'unité de traitement 6 comprend par exemple au moins un processeur configuré pour exécuter un programme d'ordinateur comprenant des instructions de code implémentant ce traitement. [0047] Dans le cas où l'ensemble de données est un flux multimédia, l'unité de traitement 6 comprend un lecteur configuré pour lire les segments de données. De façon conventionnelle, un tel lecteur comprend un décodeur configuré pour décoder les segments, et une sortie agencée en sortie du décodeur pour restituer un contenu de segments, telle qu'un écran d'affichage dans le cas d'un segment vidéo, ou un haut-parleur dans le cas d'un segment audio. [0048] Dans le cas où l'ensemble de données est un fichier, l'unité de traitement 6 est 6 configure° pour assembler les différents segments qui forment ce fichier une fois ceux-ci reçus, de sorte à former une copie du fichier référencée dans un système de fichiers du dispositif client 1. [0049] L'unité de traitement 6 est par ailleurs configuree pour sélectionner parmi les différents CDNs un CDN à solliciter pour obtenir un segment de données à traiter. Cette sélection est par exemple implémentée dans le programme d'ordinateur comprenant des instructions de code implémentant le traitement ultérieur de ces segments, ou bien implémenté dans un programme de sélection à part. [0050] Le dispositif client 1 a connaissance des différents CDNs auxquels il peut accéder. Sont par exemple mémorisées dans la mémoire 4 du dispositif client 1 des adresses de ces CDNs. [0051] On a également représenté en figure 1 un serveur d'agrégation 8 avec lequel le dispositif client 1 est à apte à communiquer. Le serveur d'agrégation comprend une mémoire et une unité de traitement configurée pour appliquer des calculs à des données qu'il reçoit du dispositif client 1 ainsi que d'autres dispositifs clients la, lb, qui seront désignés dispositifs tiers par contraste avec le dispositif client 1. [0052] Les dispositifs la et 1h sont configurés de la même manière que le dispositif 1. [0053] L'un quelconque des dispositifs 1, 1 a, lb peut se présenter par exemple sous la forme d'un ordinateur de bureau, un téléviseur, un ordinateur portable, une tablette, un smartphone, etc. [0054] 11 va maintenant être décrit un procédé de traitement de l'ensemble de données discuté précédemment par le dispositif client 1. [0055] En référence à la figure 2, les étapes suivantes sont mises en oeuvre pour un segment de de l'ensemble de données à traiter. [0056] Pour tout i allant de 1 à N, l'unité de traitement 6 calcul un score xi associé au CDN d'indice i. Le score xi est indicatif d'une qualité de transmission de données depuis le CDN d'indice i au dispositif client 1 (étape 100). Ce calcul 100 sera plus amplement détaillé dans la suite. [0057] Bien que l'inverse puisse être envisagé, il est détaillé dans la suite un mode de réa- lisation dans lequel la valeur d'un score xi croît avec la qualité de transmission de données de ce CDN au dispositif client 1. Autrement dit, un score de 10 indique une qualité de transmission de donnée supérieure qu'un score de 5 par exemple. [0058] L'unité de traitement 6 met en oeuvre un tirage aléatoire d'un CDN parmi les différents CDNs (étape 102). [0059] Dans la suite, on note Pi la probabilité de tirer le CDN d'indice i parmi les N CDNs disponibles via ce tirage aléatoire 102. [0060] Le tirage aléatoire 102 est adapté pour que la probabilité de tirer un CDN associé à un score indicatif d'une qualité de transmission relativement élevée soit supérieure à la 7 probabilité de tirer un CDN associé à un score indicatif d'une qualité de transmission relativement petite. [0061] Ce tirage aléatoire 102 est par ailleurs tel que qu'au moins deux des N CDNs voire tous les CDNs, ont des probabilités non nulles d'être tirés. [0062] Dans le cas où la valeur d'un score x, croît avec la qualité de transmission de données de cc CDN au dispositif client 1, la propriété ci-dessus du tirage aléatoire se traduit de la manière suivante : [0063] [Math .1] V (14) e 100641 En pratique, l'étape 102 de tirage aléatoire peut comprendre les sous-étapes suivantes. L'unité de traitement 6 calcule les probabilités de tirage pi associées aux scores xi. L'unité de traitement 6 met ensuite en oeuvre un tirage aléatoire uniforme d'un nombre dans un intervalle dont la longueur est égale à la somme des probabilités P. Cet intervalle est l'union de N sous-intervalles distincts respectivement associés aux différents CDNs. Pour tout j allant de 1 à N, le sous-intervalle associé au CDN d'indice j est de longueur égale à la probabilité P. Le CDN tiré aléatoirement au cours de l'étape 102 est le CDN associé au sous-intervalle incluant le nombre tiré. [0065] Le tirage aléatoire 102 dépend de préférence d'un paramètre d'exploration C. Le tirage aléatoire est adapté pour faire croître la probabilité de tirer le réseau associé au score le plus élevé parmi tous les scores calculés relativement aux probabilités de tirer les autres réseaux de la pluralité, lorsque la valeur du paramètre d'exploration varie dans un premier sens, et/ou faire décroître la probabilité de tirer le réseau associé au score le plus élevé parmi tous les scores calculés relativement aux probabilités de tirer les autres réseaux de la pluralité, lorsque la valeur du paramètre d'exploration varie dans un deuxième sens opposé au premier sens. [0066] Par exemple, la probabilité Pi de tirer un CDN d'indice j parmi les N CDNs dis- ponibles est de la forme suivante : [0067] [Math.2] P.- - -I '1'xi [0068] Recourir au paramètre d'exploration C est avantageux car permet d'ajuster le caractère plus ou moins exploratoire du tirage aléatoire. Lorsque la formule ci-dessus est utilisée, si la valeur du paramètre C est élevée, le tirage aléatoire 102 aura tendance à privilégier un tirage du CDN considéré être de qualité maximale au détriment des 8 autres CDNs. Avec un C de valeur moindre, un tel avantage aura moins de poids, si bien que des CDNs suboptimaux en ternies de qualité de transmission auront davantage de chance d'être tirés au cours de l'étape 102. [0069] Le paramètre d'exploration C peut être fixe, mais peut également être ajusté dyna- miquement (le cas d'un tel ajustement dynamique est détaillé plus loin). [0070] Le réseau ayant été tiré aléatoirement est ensuite sollicité par le dispositif client 1 pour que le dispositif client 1 obtienne un segment de l'ensemble de données (étape 104). [0071] Cette sollicitation 104 comprend par exemple l'émission par le dispositif client 1 via l'interface de communication 2 d'une requête de segment à destination du CDN tiré, et la transmission par le CDN tiré du segment visé par la requête, en réponse à celle-ci. [0072] Une sollicitation 104 du CDN tiré par le dispositif client peut se solder par un succès ou par un échec. En effet, des erreurs peuvent survenir au cours de cette sollicitation : la requête peut ne pas parvenir au CDN tiré ; le CDN tiré peut ne pas émettre du tout le segment demandé en raison d'un bug interne ; enfin, le CDN tiré peut émettre le segment demandé par le dispositif client 1 mais cc segment peut ne pas être transmis correctement jusqu'au dispositif client I. [0073] Si le segment n'est pas reçu par le dispositif client 1, alors le dispositif client 1 peut répéter l'étape de sollicitation 104 jusqu'à obtenir le segment de données. Toutefois, il est préférable de ne pas répéter une telle sollicitation immédiatement : on va s'intéresser dans la suite à ce mode de réalisation. [0074] Si le segment est bien reçu par le dispositif client au cours de cette étape de solli- citation 104, le segment est mémorisé dans la mémoire 4 en vue d'être traité par l'unité de traitement 6. Par exemple, dans le cas où le segment de données venant d'être reçu fait partie d'un flux multimédia à lire, l'unité de traitement 6 peut commander la lecture du segment de données par un lecteur (le traitement du segment est une lecture). [0075] Dans le cas où le segment de données fait partie d'un fichier à référencer dans un système de fichiers, l'unité de traitement 6 vérifie si tous les segments qui forment le fichier sont été reçus. Si oui, l'unité de traitement 6 assemble tous les segments de sorte à reconstruire une copie du fichier et la référence dans un système de fichiers. Sinon, l'unité se met en attente d'autres segments de données du fichier. [0076] Par ailleurs, l'unité de traitement 6 évalue la qualité effective de la transmission du segment qui a été reçu du CDN préalablement tiré aléatoirement (étape 106). [0077] Cette évaluation peut comprendre le calcul d'une heuristique de bande passante in- dicative d'une bande passante disponible pour la transmission de données depuis le CDN tiré au dispositif client 1. [0078] Typiquement, l'heuristique de bande passage dépend d'une bande passante ins- 9 tantanée mise à disposition du dispositif client 1 pour obtenir le segment du CDN tiré au cours de l'étape 104. Cette bande passante instantanée se calcule typiquement sous la forme d'un rapport entre la durée prise pour obtenir le segment et la taille de ce segment. [0079] On a vu précédemment que la sollicitation 104 du CDN tiré peut se solder par un succès (un segment de données est obtenu par le dispositif client 1) ou par un échec (le dispositif client 1 ne reçoit pas le segment de données). Aussi, l'évaluation de la qualité effective de la transmission du segment peut comprendre le calcul d'une l'heuristique d'erreurs de transmission, cette heuristique de transmission étant indicative d'erreurs de transmission de segments de données ayant préalablement été demandés par le dispositif client au réseau (notamment le segment que le dispositif client a demandé auprès du CDN tiré, au cours de l'étape de sollicitation 104). [0080] De telles erreurs de transmission peuvent en pratique être mesurées par le dispositif client 1 au niveau d'une couche session (typiquement HTTP) ou au niveau d'une couche de niveau supérieur dans le modèle OST, telle qu'une couche applicative. [0081] Ces erreurs peuvent être de natures diverses : erreur 404 (ou 40X ou 50X), erreur de timeout (le segment n'a pas été obtenu dans le temps imparti donné par un module de téléchargement http du dispositif client 1), déconnexion réseau temporaire du dispositif client 1, erreur sur le handshakc HTTPS, erreur en rapport aux sécurités des navigateurs (CORS, mixed content HTTP/EITTPS), etc. [0082] Chaque heuristique calculée est mémorisée dans la mémoire 4 du dispositif client I. [0083] Par ailleurs, si les probabilités de tirages discutées précédemment dépendent du paramètre d'exploration C, l'unité de traitement 6 peut évaluer un risque de dégradation de conditions de traitement par le dispositif client 1 de l'ensemble de données comprenant le segment de données, et modifier la valeur du paramètre d'exploration C d'après le risque de dégradation évalué (étape 108). [0084] Ces conditions de traitement sont par exemple des conditions de lecture du segment de données par le dispositif client 1 lorsque cet ensemble est un flux multimédia à jouer, [0085] Concrètement, l'évaluation du risque de dégradation des conditions de lecture du flux multimédia à jouer mise en oeuvre au cours de l'étape 108 peut prendre en considération l'évolution du taux de remplissage d'un tampon en amont du lecteur du dispositif client 1. En effet, un tel taux de remplissage peut indiquer si la lecture du flux risque ou non de s'interrompre si le CDN tiré au cours de l'étape 102 n'est pas de qualité optimale et que le téléchargement d'un segment auprès de ce CDN tiré prend plus de temps que prévu (cette inten-uption survenant typiquement lorsque le lecteur a besoin de traiter un nouveau segment, mais que le tampon est vide). [0086] Si, par exemple, il a été détecté qu'il existe un risque de dégradation élevé de ces conditions de traitement, il peut être préférable par mesure de sécurité de rendre le tirage moins exploratoire en faisant varier la valeur de C. En l'absence de risque ou lors d'un risque de dégradation plus faible, on peut s'autoriser à solliciter d'autres CDNs que celui considéré de meilleure qualité ; autrement dit, la valeur de C peut être dans ce cas modifiée pour rendre le tirage davantage exploratoire. [0087] Une autre façon d'évaluer le risque de dégradation des conditions de traitement de l'ensemble de données est de consulter les résultats obtenus au cours de l'étape 106. Typiquement, si la transmission du segment que le dispositif a demandé au CDN tiré au cours de l'étape 104 a échoué, le risque augmente. [0088] Les étapes 100, 102, 104, 106, 108 représentées sur la figure 2 forment une itération du procédé. Plusieurs itérations du procédé sont mises en oeuvre au cours du temps, chaque itération visant à obtenir et traiter un nouveau segment de l'ensemble de données. Par exemple, une nouvelle itération est mise en oeuvre pour chaque nouveau segment que le dispositif client 1 doit obtenir et traiter. [0089] Au vu du caractère probabiliste de la sélection d'un CDN pour obtenir un segment de l'ensemble de données, il est quasi certain que plusieurs CDNs seront sollicités par le dispositif client 1 avant ou au cours du traitement de l'ensemble de données, surtout si le nombre de segment de cet ensemble est important. [0090] En particulier, lorsque le dispositif client 1 n'obtient pas un segment de données d'un CDN tiré au cours d'une mise en oeuvre de l'étape de sollicitation 104 d'une itération, un nouveau tirage aléatoire est mis en oeuvre au cours de l'étape 102 d'une itération suivante. Un autre CDN que celui ayant échoué à fournir le segment a des chances d'être tiré et sera ensuite sollicité par le dispositif client 1 pour fournir le même segment. [0091] Par ailleurs, la répétition de l'étape 100 implique que plusieurs calculs de score sont effectués au cours du temps pour un CDN donné. De préférence, est allouée en mémoire une seule variable de score pour un CDN donnée. Lors d'une nouvelle mise en oeuvre de l'étape 100, chaque score est mis à jour. Ainsi, le score de chaque CDN évolue au cours du temps. Un CDN peut voir son score de qualité diminuer ou augmenter, ce qui a bien évidemment une influence sur le tirage aléatoire ultérieur. [0092] Le dispositif client 1 peut envoyer au serveur d'agrégation 8 des informations in- dicatives d'une qualité de transmission de segments de données vers ce dispositif client 1, depuis l'un ou l'autre des CDNs (étape 110). Ces informations peuvent comprendre au moins une des données suivantes associées à un CDN donné : le scores calculé pour ce CDN au cours d'une mise en oeuvre de l'étape 100, une heuristiques calculée pour ce CDN au cours d'une mise en oeuvre de l'étape 106 (heuristique de bande passante et/ou d'erreurs de transmissions), ces informations étant plus granulaires que le score, 11 le nombre et/ou la taille de segments de l'ensemble de données qui ont été téléchargés avec succès par le dispositif client 1 depuis le CDN, le nombre et/ou la d'erreurs de téléchargement de segments qu'a rencontrées le dispositif client 1 en sollicitant le CDN, ces informations étant encore plus granulaires que les heuristiques des informations permettant d'identifier les ensembles de données auxquels les segments téléchargés appartiennent. [0093] Il n'est toutefois pas nécessaire que le dispositif client 1 mette en oeuvre cette étape d'envoi d'informations 110 au serveur d'agrégation à chaque itération. Il peut être également prévu de déclencher l'étape 110 de manière asynchrone par rapport aux autres étapes représentées en figure 2. En pratique, on prévoir d'agréger les informations les plus granulaire côté client et les envoie au serveur d'agrégation 8 périodiquement. [0094] Le procédé se termine une fois que tous les segments de l'ensemble de données ont été reçus par le dispositif client 1 et traités par ce dernier. [0095] Il va à présent être détaillé comment les scores associés aux différents CDNs sont calculés au cours du procédé dans différents situations. Ces situations dépendent de l'itération considérée et de la question de savoir si ces CDNS ont déjà été sollicités par le dispositif client 1. Initialisation des scores [0096] Lors de l'étape dc calcul 100 de la toute première itération du procédé, les scores des différents CDNs sont initialisés à des valeurs initiales. [0097] Ces valeurs initiales sont par exemple égales, auquel cas les CDNs auront tous les mêmes chances d'être tirés lors que du tirage aléatoire 102 mis en oeuvre au cours de la première itération. [0098] En variante, ces valeurs initiales sont différentes et proportionnelles à des poids respectifs associés à ces différents CDN. [0099] Les valeurs initiales peuvent être déterminées de manière autonome par le dispositif client 1. Elles sont par exemple mémorisées à l'avarice dans la mémoire 4. [0100] Toutefois, dans un mode de réalisation particulièrement avantageux, le serveur d'agrégation 8 fournit au dispositif client 1 des informations qui permettent de définir les valeurs initiales des scores associés au différents CDNs. [0101] Dans ce mode de réalisation, les valeurs initiales que fournit le serveur d'agrégation 8 au dispositif client 1 sont fonction d'informations ayant été préalablement remonté par au moins un dispositif tiers ayant mis en oeuvre le même procédé que le dispositif client 1 (on a en effet vu précédemment que le dispositif client 1 envoie lui-même toute ou partie des scores qu'il calcule au serveur d'agrégation 8 au cours de l'étape 110). 12 [0102] Il pourrait être envisagé que le serveur d'agrégation 8 fournisse directement la valeur initiale du score d'un CDN d'indice i au dispositif client I. Dans ce cas, le serveur d'agrégation 8 agrège les informations qu'il reçoit d'au moins un dispositif tiers tel que la ou 11,, et qui concerne le CDN d'indice i. [0103] Il est toutefois préférable que le serveur d'agrégation 8 fournisse au dispositif client des informations plus granulaires que des scores, par exemples les heuristiques discutées précédemment. Dans ce cas, les heuristiques gérées par le dispositif 1 sont elles même initialisées aux valeurs reçues du serveur d'agrégation 8. Ces valeurs initiales d'heuristiques permettent ensuite de calculer les valeurs initiales des scores au cours de la première mise en oeuvre de l'étape de calcul 100. En d'autres termes, dans ce mode de réalisation, l'étape de calcul 100 est mise en oeuvre de la même manière dans la première itération et dans les itérations subséquentes. [0104] Par ailleurs, il est préférable d'appliquer certains filtres avantageux sur les in- formations fournies par le serveur d'agrégation 8 au dispositif client 1. Ainsi, les informations agrégées peuvent ne comprendre que les informations suivantes : les informations se rapportant à une fenêtre glissante de durée prédéterminée, afin de ne considérer que des mesures récentes, les informations remontées seulement par des dispositifs tiers sélectionnés d'après un critère de proximité réseau avec le dispositif client 1 (même FAT, même pays, voire même ville, ou même même ASN). Les informations concernant le même diffuseur : en effet, les utilisateurs de TEl et MG n'obtiennent pas nécessairement les mêmes performances pour un même CDN. En effet chaque CDN a plusieurs sous-réseaux de serveurs plus ou moins performant. Les informations concernent le même ensemble de données que celui que doit traiter le dispositif 1 : En effet un contenu populaire va être caché sur beaucoup de serveurs du CDN, alors qu'un contenu peu populaire peut ne pas être caché du tout. Ceci peut avoir un impact conséquent sur les performances d'un CDN. [0105] Solliciter le serveur d'agrégation 8 permet d'initialiser les scores à des valeurs initiales plus pertinentes. En conséquence, le procédé sera plus efficace pour obtenir et traiter les premiers segments de l'ensemble de données considéré. [0106] Une fois la première itération terminée, tous les scores ont bien une valeur (une valeur initiale), et l'un des CDNs a été tiré sur la base de sa valeur initiale, puis sollicité pour que le dispositif obtienne un premier segment de l'ensemble de données. Toutefois, tous les autres CDNs (au nombre de N-1) n'ont pas encore été sollicités par le dispositif client 1 pour l'obtention d'un segment de l'ensemble de données. [0107] Mise à jour du score d'un CDN ayant déjà été sollicité 13 [0108] Supposons à présent que le CDN d'indice i a été sollicité par le dispositif client 1 au cours d'au moins une itération antérieure. Dans la suite, le terme « sollicité » se réfère implicitement à l'étape de sollicitation 104 et à l'ensemble de données discuté jusqu'ici. Autrement dit, un CDN « sollicité » a donc été tiré aléatoirement au moins une fois au cours d'une mise en oeuvre dc l'étape 102 et a fourni au moins un segment de l'ensemble de données considéré au dispositif client 1. L'étape d'évaluation 106 a donc été mise en oeuvre au moins une fois pour cc CDN d'indice i, pour au moins un segment transmis antérieurement par le CDN d'indice i et reçu par le dispositif client 1. [0109] Un nouveau segment de l'ensemble de données, dit segment de référence, doit à présent âtre obtenu par le dispositif client 1 en vue de le traiter dans une nouvelle itération, dite itération courante. [0110] Comme l'itération courante n'est pas la première itération, une valeur a déjà été dé- terminée pour le score Xiau cours de l'étape de calcul 100 d'une itération précédant l'itération courante. [0111] Lors de l'étape 100 de l'itération courante, l'unité de traitement 6 met à jour le score xi en fonction d'au moins une heuristique (heuristique de bande passante et/ou heuristique d'erreurs) associée au CDN d'indice i et antérieurement calculée. De cette manière, le nouveau score Xi tient compte des conditions dans lesquelles le dispositif client 1 a déjà reçu des segments du CDN d'indice i. [0112] Mise à jour du score d'un CDN non encore sollicité [0113] Une question qui se pose de savoir comment mettre à jour, lors de l'étape 100 d'une itération courante, le score d'un CDN n'ayant pas encore été sollicité. En effet, ce CDN n'a pas encore transmis de segment de l'ensemble de données au dispositif client. [0114] Une possibilité est de tout simplement ne pas mettre à jour le score d'un CDN non encore sollicité. Dans un tel mode de réalisation, la valeur du score d'un CDN reste à sa valeur initiale jusqu'à ce que ce CDN soit sollicité. [0115] Toutefois, ceci présente l'inconvénient de créer des écarts potentiellement grands entre les scores des CDNs déjà sollicités et les scores des CDNs non encore sollicités par le dispositif client 1. De tels écarts sont susceptibles de pénaliser de manière injuste les CDNs non encore sollicités lors d'un tirage aléatoire 104. [0116] L'apparition de tels écarts peut survenir lorsque le dispositif client 1 reçoit des valeurs initiales d'heuristiques qui dépendent d'heuristiques calculées par des dispositifs tiers bénéficiant d'une qualité de communication avec des CDNs très différente de celle vue par le dispositif client 1. Supposons par exemple que le dispositif client 1 bénéficie d'une bonne connexion aux CDNs (par fibre optique par exemple) tandis que les dispositifs tiers la, lb bénéficie d'une connexion moins performantes à ces CDNs (ADSL par exemple). Si le dispositif client 1 initialise ses 14 propres heuristiques à des valeurs dépendant de valeurs d'heuristiques remontées par les dispositifs tiers la ou lb, ces valeurs initiales d'heuristiques (et par conséquent les valeurs initiales de scores calculées sur leur base par le dispositif client 1) retlèteront mal les conditions réelles de communication entre les CDNs et le dispositif client 1. C'est pourquoi une mise à jour d'une heuristiques associée à un CDN par le dispositif client pourra faire apparaitre un écart important entre la valeur d'heuristique résultant de cette mise à jour et les heuristiques d'autres CDNS restées à leur valeur initiale. [0117] Pour éviter cet effet de bord, il est préférable, lors de l'étape de calcul de score 100 d'une itération courante différente de la première itération, de mettre à jour le score d'un CDN non encore sollicité en fonction du score mis à jour pour au moins un CDN ayant déjà été tiré lors d'une itération antérieure. [0118] Par exemple, supposons qu'un CDN d'indice i a été tiré lors de l'itération précédant l'itération courante. Lors de l'itération courante, le score du CDN d'indice i est mis à jour par l'unité de traitement 6 à l'aide d'heuristiques préalablement évaluées, comme indiqué précédemment. Cette mise à jour fait varier la valeur du score du CDN d'indice i d'un certain facteur (égal au rapport entre le score après mis à jour et le score avant mis à jour). [0119] L'unité de traitement 6 calcule un facteur de mise à jour d'un CDN d'indice j non encore sollicité, à partir du facteur de mise à jour du CDN d'indice i. Par exemple, le facteur de mise à jour calculé pour le CDN d'indice j, non encore sollicité, est proportionnel au facteur de mise à jour du CDN d'indice i déjà sollicité. En variante, le facteur de mise à jour calculé pour le CDN d'indice j, non encore sollicité, est proportionnel à une moyenne des facteurs de mise à jour respectifs de plusieurs CDNs ayant déjà été sollicités, par exemple tous les CDNs ayant déjà été sollicités pour obtenir des segments de l'ensemble de données. [0120] Ensuite, l'unité de traitement 6 met à jour le score du CDN d'indice j en multipliant sa valeur courante par le facteur de mise à jour qui vient d'être calculé pour le CDN d'indice j. [0121] Bien qu'intéressant pour éviter des écarts de scores importants injustifiés, il est préférable de limiter dans le temps ce mécanisme d'alignement de scores de CDNs non encore sollicités sur des scores de CDNs déjà sollicités. Pour cela, il est avantageux de faire varier le facteur de mise à jour calculé pour un CDN non encore sollicité avec l'indice de l'itération courante et/ou du nombre total de segments déjà obtenus par le dispositif client 1, de sorte à rapprocher le facteur de mise à jour del. Ainsi, l'effet d'alignement suscité par le facteur de mise à jour d'un CDN non encore sollicité décroît dans le temps. Mise à jour des heuristiques [0122] Les étapes de tirage aléatoire 102 et de sollicitation 104 décrites précédemment en relation avec la figure 2 sont mises en oeuvre au cours d'une itération courante quelconque. [0123] Par ailleurs, lors de l'étape d'évaluation 106 d'une itération courante différente de la première itération, l'unité met à jour les heuristiques existantes associées au CDN ayant été tiré au cours de l'étape de tirage aléatoire dc l'itération courante, dc sorte que ces heuristiques tiennent compte des conditions dans lequel le segment de référence a été reçu au cours dc l'étape de sollicitation 104 de l'itération courante du CDN tiré. [0124] Ainsi, l'heuristique de bande passante mise à jour au cours de l'itération courante tient compte de la bande passante instantanée qui a été utilisée au cours de la réception du segment de référence, mais également de la bande passage instantanée qui a été utilisée au cours de chaque autre segment de l'ensemble de données, transmis antérieurement par le CDN d'indice i au cours d'itérations antérieures. [0125] De préférence, l'heuristique de bande passante est calculée comme une moyenne glissante, par exemple exponentielle (exponential wcighted tnoving average » ou EWMA en anglais). De cette manière, il est fait en sorte que l'heuristique de bande passante accorde davantage de poids à un segment reçu récemment qu'à un segment reçu auparavant. [0126] Par ailleurs, l'heuristique d'erreurs de transmission est mise au cours de l'itération courante de sorte à évoluer selon certaines règles avantageuses. [0127] Si le CDN tiré au cours de l'itération courante a échoué à transmettre le segment dc référence au dispositif client 1 au cours de l'étape de sollicitation 104 de l'itération courante, l'heuristique d'erreurs associée au CDN tiré est mise à jour de manière à rendre moins probable le tirage aléatoire de ce CDN au cours d'une itération suivante du procédé. Par exemple, l'heuristique d'erreurs est mise à jour dans ce cas de manière à diminuer la valeur du score de ce CDN lors d'une mise en oeuvre suivante de l'étape 100. [0128] A l'inverse, si le CDN tiré au cours de l'itération courante a réussi à transmettre le segment de référence au dispositif client 1 au cours de l'étape de sollicitation 104 de l'itération courante, l'heuristique d'erreurs associée au CDN tiré est mise à jour de manière à rendre plus probable le tirage aléatoire de ce CDN au cours d'une itération suivante du procédé. Par exemple, l'heuristique d'erreurs est mise à jour dans ce cas de manière à augmenter la valeur du score de ce CDN lors d'une mise en oeuvre suivante de l'étape 100. [0129] Par ailleurs, l'heuristique d'erreurs du réseau tiré au cours de l'itération courante varie d'une quantité qui elle-même croit avec un nombre d'erreurs de transmission de segments passées associé à ce réseau. Ce mécanisme sanctionne ainsi de plus en plus fortement un CDN accumulant des erreurs de transmission de segments. [0130] L'heuristique d'erreurs associé aux autres CDNs (c'est-à-dire ceux n'ayant pas été 16 tirés au cours de l'itération courante) peut également être mise à jour, selon les modalités suivantes. [0131] L'unité de traitement 6 détermine quand le CDN non tiré au cours de l'itération courante a été sollicité pour la dernière fois. Pour déterminer cela, l'unité peut compter le temps, ou bien compter un nombre de segments ou d'itérations du procédé. [0132] Si l'unité de traitement 6 s'aperçoit qu'un CDN d'indice i non tiré au cours de l'itération courante n'a pas été tiré dans une période de temps donnée (par exemple, les K derniers segments reçus proviennent d'autres CDNs que le CDN d'indice i, ou bien aucun segment n'a été reçu du CDN d'indice i depuis X secondes), l'heuristique d'erreurs de cc CDN d'indice i est mise à jour de manière à rendre plus probable le tirage aléatoire du réseau d'indice i au cours d'une itération suivante du procédé. Cc mécanisme revient finalement à instaurer un principe de prescription : on accepte qu'un CDN n'ayant pas été sanctionné durant une période suffisamment longue ait davantage de chances d'être sollicité à et cc même si ce CDN avait été sanctionné avant cette période. [0133] Tous les principes évoqués ci-dessus peuvent être implémentés de manières très diverses. [0134] A titre d'exemple, l'encart ci-dessous illustre le pseudo-code d'un mode de réa- lisation possible des étapes de calcul des scores, des probabilités et des heuristiques susmentionnées. [0135] HANDICAP_BASE = 10 [0136] ERROR_PERCENTAGE_BASE = 10 [0137] CAUTIOUSNESS in [0, -FInf[ [0138] ALPHA in ]0, 1] # bandwidth smoothing EWMA factor [0139] BETA in IO, 1] # error rate estimation EWMA factor [0140] GAMMA in ]0, 1[ # handicap exponential decrease [0141] for each CDN: [0142] score = weight bandwidth / HANDICAP_BASE A hpw [0143] probability = score A CAUTIOUSNESS [0144] on success: [0145] // EWMA for bandwidth smoothing [0146] bandwidth = (1 - ALPHA) * bandwidth + ALPHA * measured_bandwidth [0147] // EWMA for enor rate estimation [0148] error_rate = (1 - BETA) error_rate [0149] on en-or: [0150] hpw = Min(100, hpw + ERROR_PERCENTAGE_BASE A (en-or_rate * 100)) [0151] // EWMA for enor rate estimation [0152] error_rate = (1 - BETA) error_rate + BETA 17 [0153] on tick: [0154] // hpw multiplicative decrease with timc [0155] hpw = (1. - GAMMA) * hpw [0156] Voici quelques explications sur ce pseudocode d'exemple, qui comprend une boucle qui itère sur chaque CDN : La branche on error est exécutée lors d'une erreur de transmission de segment par le CDN au dispositif client 1. La branche on success est exécutée lorsque le dispositif 1 reçoit avec succès un segment du CDN. La variable mcasured bandwidth est la bande passante instantanée mesurée pour le dernier segment reçu par le dispositif client 1 du CDN considéré. L'heuristique de bande passante associée à un CDN est ici la variable bandwidth. Comme on peut le constater, le score calculé pour un CDN dépend de cette variable. Cette heuristique de bande passante est revue à la hausse si measured bandwidth > bandwidth ; sinon, elle est revue à la baisse. L'heuristique d'erreurs associé à un CDN correspond ici au terme HANDICAP_BASE élevé à la puissance hpw. La valeur hpw est augmentée lorsque le dispositif client 1 détecte une erreur de transmission de segment en provenance du CDN considéré, et cette augmentation est elle-même croissante avec le terme error rate (voir le terme ERROR PERCENTAGE BASE élevée à la puissance errourate en cas de passage dans la branche on error). La branche on tick correspond au principe de prescription mentionné précédemment: elle est exécutée à l'expiration d'un compteur. En pratique cette branche est exécutée périodiquement pour chaque CDN. A chaque passage, la valeur hpw associée à un CDN donnée est réduite, par exemple de 1% à chaque seconde si GAMMA vaut 0.01. Le poids prédéfini pour un CDN donnée est la donnée weight. La variable probability ne correspond pas directement à une probabilité Pi discutée précédemment (de valeur comprise entre 0 et 1). Pour obtenir cette probabilité, peut par exemple diviser cette valeur par la somme des variables probability de tous les CDNs. [0157] Pour prendre un exemple concret, si par exemple juste avant une erreur, hpw vaut 0, et en-or_rate vaut 0.01, le paramètre (constant) BETA vaut 0.1, et HANDICAP_BASE et ERROR_PERCENTAGE_BASE valent 10. A l'itération suivante, hpw sera mis à jour et vaudra 10 ^1 = 10 (par ailleurs errourate vaudra (1-0.1)*0.01 + 0.1 = 0.109 après avoir été mis à jour). On obtient le score final avec la formule score = weight bandwidth / HANDICAP_BASE ^ hpw. Donc dans cet exemple le dénominateur vaudra 10110. 18 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4]