FR 2911234 A1 20080711 FR 0700059 A 20070105 Procédé d'envoi de paquets de données d'un serveur vers un client, le client utilisant simultanément à un débit constant D les données qu'il reçoit La présente invention concerne un procédé d'envoi de paquets de données d'un serveur vers un client. Le client utilise simultanément à un débit constant D les données qu'il reçoit. L'invention s'applique par exemple dans le domaine de la vidéo à la demande, où le client affiche simultanément les données vidéo qu'il reçoit. De nouveaux services de divertissement et de communication sont aujourd'hui offerts aux passagers des avions commerciaux ou d'affaire, ces services étant couramment rassemblés sous la dénomination anglo-saxonne de In Flight Entertainment (qu'on appellera services IFE par la suite). Il peut s'agir par exemple de l'accès à l'internet haut débit ou bien d'un service de vidéo à la demande pour chaque passager. Ainsi, chaque passager peut par exemple choisir de visionner individuellement un contenu vidéo quelconque, comme un film. Par une interface appropriée, chaque passager peut sélectionner ce qu'il souhaite visionner. Le film démarre quasiment instantanément, il n'est même pas nécessaire d'attendre le téléchargement du film, ce qui représenterait un temps assez long. Par la suite, il peut interrompre temporairement le visionnage puis le reprendre, ou revenir en arrière pour revoir une séquence, ou encore avancer pour sauter des séquences, ceci toujours avec la même instantanéité du démarrage de l'affichage. Pour le passager, tout se passe comme s'il était à la maison devant un téléviseur connecté à un lecteur de disques vidéo. Ce type de service est d'ores et déjà disponible à bord de nombreux avions. Les systèmes actuels utilisent notamment des modules d'affichage au niveau des dossiers des sièges, des modules de saisie au niveau des accoudoirs des sièges, des modules de lecture et de transmission au niveau de la tête de cabine, tous ces modules étant connectés entre eux par des liaisons filaires. Les systèmes IFE ont par conséquent fait exploser la quantité de câblage pour chaque siège, ceci au détriment de la configurabilité de la cabine. Or, la configurabilité de la cabine est un atout marketing important pour les avionneurs, notamment la possibilité pour les clients de choisir le nombre et la disposition des sièges. En effet, à quelques contraintes de sécurité près, les compagnies aériennes sont relativement libres quant à l'agencement intérieur de la cabine lorsqu'elles commandent un avion. Ceci afin qu'elles puissent adapter la cabine au type de clientèle sur la ligne qu'elles comptent exploiter. Le câblage IFE des sièges est donc devenu un frein de plus en plus lourd à la polyvalence des appareils. Mais de la même manière, un système IFE complet et performant est également devenu un atout marketing majeur pour les avionneurs. La concurrence accrue dans le domaine du transport aérien et la démocratisation des voyages en avion qui en a résulté, ont fait que les services IFE, qui ont pu sembler accessoires à leurs débuts, sont devenus indispensables pour conquérir des parts de marché. II convenait donc de réconcilier les contraintes techniques des systèmes IFE avec une configurabilité optimum de la cabine. Ainsi, ayant connaissance de l'essor des technologies de transfert d'information sans fil, certains avionneurs ont-ils, en accord avec les compagnies aériennes et les fournisseurs de systèmes IFE, purement et simplement supprimé certains des câbles IFE allant jusqu'aux sièges, parmi les plus gênants à la configurabilité de la cabine. N'ont été conservés que des câbles reliant les sièges par petits groupes de deux, trois ou quatre sièges. Charge aux fournisseurs de systèmes IFE de s'adapter, notamment en exploitant au maximum le câblage restant et en tirant le meilleur profit des technologies sans fil. Développer un protocole de communication sans fil dédié à la vidéo à la demande dans un système IFE aurait sans doute amené à une solution très performante, mais cela aurait sans doute coûté très cher également. C'est pourquoi l'utilisation d'un standard de communication a été préférée. Malheureusement, aucune des normes actuelles ne répond à l'ensemble de la problématique de la vidéo à la demande dans un système IFE. Cependant, compte tenu notamment de la maturité des différentes technologies, les normes IEEE 802.11a, IEEE 802.11b, IEEE 802.11g ou IEEE 802.11n plus connues sous la dénomination commerciale de liaisons WiFi semblent les plus adaptées. Elles ont par conséquent été retenues. En effet, les liaisons WiFi donnent des résultats tout à fait satisfaisants dans des applications vidéo grand public, mais sans contrainte de multi-diffusion ni contrainte d'instantanéité d'affichage. Par la suite, elles seront également rassemblées sous la désignation générique de 802.11. En effet, à bord d'un avion long courrier, plusieurs dizaines voire plusieurs centaines de passagers peuvent visionner simultanément des films différents, chaque passager pouvant interrompre, avancer ou reculer à sa guise dans le film qu'il visionne. Par conséquent, chaque film visionné par un passager constitue une session particulière, le flux de données vidéo correspondant devant être envoyés exclusivement vers l'écran d'affichage d'un seul passager. Par exemple, un système IFE peut diffuser simultanément 300 sessions. Une telle contrainte de multi-diffusion n'existe dans aucune application vidéo grand public actuelle de la liaison WiFi. De même, les applications vidéo actuelles de la liaison WiFi ne fournissent pas une quasi-instantanéité de l'affichage, notamment au démarrage du film. Des temps d'attente de plusieurs secondes, parfois masqués par des messages publicitaires ou d'avertissement, sont nécessaires avant qu'une commande de lecture ne soit réellement exécutée. Ainsi, les applications utilisant une liaison WiFi à la maison exploitent généralement les normes IEEE 802.11 b et IEEE 802.11g, qui fournissent 3 canaux aux alentours de 2,4 gigahertz pour un débit total pouvant aller jusqu'à 20 mégabits par seconde (Mbp:,). Un petit nombre (quelques unités) de flux vidéo peuvent être envoyés simultanément par canal. Ceci n'est pas suffisant dans le cadre de la vidéo à la demande dans un système IFE, pour laquelle la norme IEEE 802.11 a semble plus adaptée. Cette dernière fournit 23 canaux entre 5 et 6 gigaherlz pour un débit total pouvant aller jusqu'à 600 Mbps. Mais la norme IEEE 802.11 a n'est quand même pas parfaitement adaptée aux besoins de la vidéo à la demande dans un système IFE. En effet, la norme IEEE 802.11a ne garantit pas qu'un paquet soit reçu, ni même ne garantit qu'un paquet soit reçu à un coût raisonnable. Car les normes 802.11 sont basées sur un mécanisme d'accusé de réception : un message nommé ACK d'après la terminologie anglo-saxonne ACKnowledgement est envoyé à une borne WiFi émettrice pour chaque paquet de données reçu par une borne WiFi réceptrice. La borne WiFi émettrice renvoie le paquet à la borne WiFi réceptrice jusqu'à ce qu'elle reçoive le message ACK correspondant. Au bout d'un certain nombre de renvois, le paquet n'est plus renvoyé et il est définitivement perdu pour la borne WiFi réceptrice. Par ce mécanisme, outre le fait que de la bande passante est gaspillée pour envoyer les messages ACK, il faut remarquer que pour récupérer un premier paquet perdu, éventuellement de nombreux autres paquets peuvent être perdus par la suite ! Ainsi, si le taux d'erreur est important, c'est-à-dire si le nombre de paquets perdus par rapport au nombre de paquets envoyés est important, du retard peut facilement s'accumuler et des erreurs peuvent apparaître sur l'écran. Ce à quoi les normes 802.11 répondent en diminuant le débit, ce qui n'est pas acceptable dans le cadre de la vidéo à la demande multiple. C'est une caractéristique essentielle des liaisons WiFi standards que de fournir un compromis permanent entre le taux d'erreur et le débit. Si le taux d'erreur augmente, le débit diminue et vice-versa. II est d'ailleurs à noter que des paquets de données peuvent être définitivement perdus et que les données affichées au final peuvent contenir des erreurs, qui se manifestent dans la plupart des cas par des pixels noirs ou non rafraîchis. Certains terminaux d'affichage tentent d'atténuer l'inconfort visuel que peuvent provoquer ces erreurs résiduelles, par des procédés de lissage de l'image par exemple. Assurer un débit constant sur une liaison WiFi est l'un des problèmes techniques auxquels l'invention se propose de donner une solution. Dans la cabine relativement exiguë d'un avion, même de la taille d'un long courrier, les erreurs ne sont pas dues à la distance entre la borne WiFi émettrice et la borne WiFi réceptrice. Le problème vient d'un phénomène classique connu sous la terminologie anglo-saxonne de micro- fading : à très haute fréquence le niveau de réception peut varier dans le temps et dans l'espace. Dans le cas présent, le micro-fading s'explique d'une part par un phénomène de résonance des molécules d'eau à la fréquence utilisée, l'eau étant très présente dans le corps de chacun des nombreux passagers en mouvement permanent, et d'autre part par un phénomène de réflexion des ondes sur les objets métalliques, le métal étant omniprésent dans la cabine d'un avion. La technologie WiFi, initialement conçue pour faire de l'Internet à la maison, échanger des e-mails et télécharger des fichiers sans réelle contrainte de temps, n'a pas été conçue pour être robuste au phénomène de micro-fading et fournir un débit constant. Certaines normes 802.11 plus récentes prévoient de fournir une qualité de service en terme de latence, de taux d'erreur et de débit. Mais elles reposeront sur un mécanisme de mise en mémoire tampon d'au moins une dizaine de secondes de données, ce qui 1 o est incompatible de la quasi-instantanéité d'affichage exigée par la vidéo à la demande dans un système IFE, notamment au démarrage. Les besoins de la vidéo à la demande dans un système IFE ne correspondent donc définitivement pas aux contraintes de développement de la technologie WiFi. C'est une des raisons pour lesquelles il n'existe pas actuellement de vidéo à 15 la demande multiple dans un système IFE sans fil. Aujourd'hui, un module de lecture en tête de cabine est toujours relié aux écrans par une liaison filaire de bout en bout passant par les sièges. La présente invention se propose de résoudre le problème de débit non constant sur une liaison WiFi, afin de permettre la mise en oeuvre de la vidéo à la demande dans un système IFE 20 sans fil. Dans des domaines proches comme celui de la vidéo à la demande à la maison via une liaison RNA pour Raccordement Numérique Asymétrique , ou liaison ADSL en anglais pour Asymetric Digital 25 Subscriber Line , le problème de débit non constant a été résolu en mettant en place, au niveau TCP/IP des couches réseau, un mécanisme de mise en mémoire tampon d'une durée suffisamment longue de flux vidéo. Le volume de données contenu dans la mémoire tampon varie proportionnellement avec le débit de téléchargement. Si le débit de téléchargement se maintient à 30 un niveau suffisamment élevé pour que la mémoire tampon ne soit jamais vide, alors la continuité du flux vidéo affiché est assurée. Dans le cas contraire, l'image se fige lorsque la mémoire tampon est vicie, elle ne s'animera à nouveau que lorsque le débit remontera à un niveau suffisant pour que la mémoire tampon se remplisse à nouveau. Un avantage de cette 35 solution est que le contenu de la mémoire tampon ne contient aucune erreur et que l'affichage est parfait sans aucune correction du terminal d'affichage. Mais un inconvénient majeur de cette solution est que le débit peut varier et que l'image peut de figer lorsque la liaison est particulièrement mauvaise. L'invention a notamment pour but de fixer le débit de la liaison WiFi afin qu'il ne varie plus en fonction du taux d'erreur sur la liaison. L'invention permet de borner à la fois le débit descendant dans le sens serveur-client et le débit montant dans le sens client-serveur. L'invention est particulièrement efficace lorsque le taux d'erreur nominal sur la liaison est inférieur à 10-2. Ceci est très souvent le cas dans la pratique, grâce notamment aux mécanismes existants d'accusé de réception implémentés par les couches OSI de bas niveau. Utilisée dans le cadre d'une application multi-client comme la vidéo à la demande d'un système IFE, elle permet notamment d'éviter que les dégradations du niveau de réception que peut rencontrer un client particulier n'aient d'impact sur les autres clients, c'est-à-dire d'éviter que les mesures de récupérations des données perdues par un client ne ralentissent les liaisons des autres clients. A cet effet, l'invention a pour objet un procédé d'envoi de paquets de données d'un serveur vers un client, le client utilisant simultanément à un débit constant les données qu'il reçoit. Un flux de paquets de données du serveur vers le client est composé d'un flux principal, d'un flux de retransmission pour renvoyer les paquets n'ayant pas été reçus par le client et d'un flux de prise d'avance pour accumuler des données chez le client. Le débit du flux principal est fixé au débit constant auquel le client utilise les données. Le débit du flux de prise d'avance est fixé à une certaine valeur lorsque le débit du flux de retransmission est nul. Le débit du flux de prise d'avance est nul et la somme des débits du flux principal et du flux de retransmission est fixée au débit constant auquel le client utilise les données lorsque le débit du flux de retransmission n'est pas nul ou lorsque le client a accumulé des données au-delà d'un certain seuil. Un paquet envoyé par le serveur mais pas reçu par le client est renvoyé au client un certain délai après son premier envoi. Un paquet envoyé par le serveur mais pas reçu par le client n'est renvoyé au client que si celui-ci a déjà reçu précédemment un nombre donné de paquets envoyés par le serveur. Avantageusement, le serveur peut envoyer des paquets de données par ledit procédé à plusieurs clients en même temps. Par exemple, lorsque le débit du flux de retransmission R est nul, le débit du flux de prise d'avance peut être fixé à un pourcentage du débit 5 constant auquel le client utilise les données. Dans un mode de réalisation, le serveur peut numéroter les paquets de données qu'il envoie au client. Le client peut informer le serveur que, sur la base de la numérotation des paquets, il manque des paquets parmi les paquets de données qu'il a accumulés et pour lesquels le délai 10 s'est écoulé depuis qu'ils auraient du être reçus. Le client peut également informer successivement le serveur qu'il manque des paquets parmi les paquets de données qu'il a accumulés et pour lesquels des délais successifs se sont écoulés depuis qu'ils auraient du être reçus. Par exemple, le client peut estimer le temps moyen entre la 15 réception de deux paquets consécutifs. En multipliant la différence entre le numéro du dernier paquet reçu et le numéro de chaque paquet accumulé par le temps moyen, il peut déduire le délai écoulé depuis qu'a été reçu ledit paquet. Avantageusement, le client peut informer le serveur en lui 20 envoyant un message d'accusé de réception négatif. Le message peut indiquer des numéros de paquets manquant et le serveur peut renvoyer au client les paquets dont le numéro est indiqué dans le message. Dans un mode de réalisation, le client peut incrémenter un compteur d'une valeur positive r lorsqu'il reçoit un paquet du serveur et 25 n'envoyer un message d'accusé de réception négatif que s'il peut décrémenter le compteur d'une valeur positive supérieure à la valeur d'incrément, autant de fois qu'il y a de paquets manquant et sans que le compteur prenne une valeur négative. Le client peut envoyer les paquets de donnée au client par 30 l'intermédiaire d'une liaison WiFi ou de toute autre liaison avec ou sans fil susceptible de perdre des paquets, par exemple des paquets do données vidéo que le client affiche simultanément sur un écran. Eventuellement, la vidéo est visionnable par un passager d'un aéronef 35 L'invention a encore pour principaux avantages qu'elle n'a aucun impact sur les couches réseaux de plus bas niveau que sont la couche physique (PHY) et la couche liaison (MAC). Par conséquent, l'invention est complètement indépendante de la liaison WiFi à proprement parler, les normes 802.11 concernant ces deux couches exclusivement. Ainsi, si la technologie sans fil évolue, que ce soit la technologie WiFi qui soit utilisée ou une autre, la solution selon l'invention reste efficace sans aucune modification. Des solutions évidentes au niveau des couches réseaux PHY et MAC dépendent invariablement du matériel et du logiciel, par exemple d'une carte WiFi et de son pilote. Elles doivent donc être modifiées quand le standard évolue ou que le matériel change. Ce n'est pas le cas de la solution selon l'invention, qui, de plus, ne demande qu'un petit effort d'implémentation en comparaison avec les solutions au niveau des couches PHY et MAC, qui nécessitent une connaissance approfondie du standard sans fil utilisé et de l'architecture matérielle. La solution selon l'invention est donc moins chère. Enfin, puisqu'elle est capable de retarder une retransmission, la solution selon l'invention est capable d'attendre un meilleur moment pour retransmettre les paquets perdus, alors que les méthodes au niveau des couches basses fournissent seulement des moyens pour retransmettre immédiatement. D'autres caractéristiques et avantages de l'invention apparaîtront 25 à l'aide de la description qui suit faite en regard de dessins annexés qui représentent : la figure 1, une illustration par un diagramme d'architecture d'un exemple de mise en oeuvre de l'invention ; - la figure 2, une illustration par un graphe d'un mécanisme 30 d'accumulation d'avance mis en oeuvre dans l'exemple de la figure 1 ; la figure 3, une illustration par un graphe de l'avance accumulée dans l'exemple de la figure 1. 35 La figure 1 illustre par un diagramme d'architecture un exemple de mise en oeuvre de l'invention, pouvant par exemple être implémenté à bord d'un avion pour fournir de la vidéo à la demande dans un système IFE sans fil. Un module serveur 3 inclut notamment tout le matériel nécessaire au stockage et à la lecture de données vidéo, ainsi qu'à leur envoi vers un point d'accès 4 via une liaison filaire représentée en partie par un port 5. Le point d'accès 4 dispose par exemple d'une borne WiFi 1 qui renvoie sans fil les données vers une borne WiFi 2. Un module client 6 inclut tout le matériel nécessaire à la réception des données vidéo, par exemple la borne WiFi 2, ainsi qu'à leur affichage grâce à un écran qui n'est pas représenté sur la figure 1. Il s'entend que, dans l'exemple de la figure 1, le module serveur 3 peut s'adresser à un ensemble de modules identiques au module client 6. Mais pour faciliter la compréhension de l'invention, un seul module client est représenté sur la figure 1. L'invention propose par exemple de mettre en place un mécanisme d'accusés de réception négatifs connu sous la terminologie anglo-saxonne de Negative ACKnowledgement (NACK). Il s'agit pour le module 6 d'envoyer un message NACK par un port 7 lorsqu'il n'a pas reçu un paquet de données. Le message NACK est envoyé sans fil par la borne WiFi 2 à la borne WiFi 1, le point d'accès 4 renvoyant le message au module serveur 3 par la liaison filaire. Dans cet exemple, l'implémentation utilisée des 5 premières couches du modèle OSI est la suivante. La couche 1 ou couche physique (PHY) et la couche 2 ou couche liaison (MAC) implémentent la norme 802.11 a. La couche 3 ou couche réseau implémente le protocole IP. La couche 4 ou couche transport implémente le protocole UDP. La couche 5 ou couche session implémente le protocole RTP. Au vu des couches 1 et 2, cette implémentation du modèle OSI est bien adaptée à la liaison WiFi illustrée sur la figure 1 par la borne WiFi 1 et la borne WiFi 2. Pour que le module 6 puisse détecter qu'un paquet a été envoyé par le module 3 mais qu'il ne l'a pas reçu, le module 6 peut avantageusement consulter, dans chaque paquet de données, l'en-tête correspondant à la couche 5 implémentant le protocole RTP. En effet, cet en-tête RTP contient notamment un numéro de séquence inséré par le module 3 émetteur, obtenu par simple incrément de 1 d'un paquet au suivant. Avantageusement là encore, à partir de ce numéro de séquence, il peut être facile pour le module 6 récepteur de déterminer un numéro de paquet qu'il aurait du recevoir mais qu'il n'a pas reçu, auquel cas il peut par exemple renvoyer un message NACK au module 3 émetteur. Le message NACK peut contenir le numéro de séquence du premier paquet perdu et le numéro de séquence du premier paquet reçu après ce premier paquet perdu. Par exemple, si le module 6 client reçoit initialement des paquets numérotés 11, 12, 13, 14, 18, 19 et 20, alors il peut envoyer le message NACK(15,18) sur le port 7 et le module serveur 3 renvoie ultérieurement les paquets 15, 16 et 17 sur le port 5. Afin de décorréler temporellement le renvoi d'un paquet de son envoi initial raté, l'invention propose par ailleurs que le module 6 n'envoie pas immédiatement le message NACK , mais plutôt qu'il attende un certain délai. Dans notre cas, le délai commence à réception du paquet numéro 18. De cette manière, si la raison de la perte du paquet était temporaire, comme c'est souvent le cas avec le phénomène de microfading décrit précédemment, alors le deuxième envoi du paquet aura beaucoup plus de chance d'être effectivement reçu que si le renvoi était fait immédiatement après le premier envoi. II est préférable de choisir un délai d'envoi d'un message NACK relativement important à l'échelle d'un réseau informatique, c'est-à-dire plusieurs secondes, ceci afin de vraiment décorréler le moment du renvoi du paquet du moment du premier envoi, moment auquel le niveau de réception était trop faible. Par conséquent, il convient de recevoir les paquets de données quelques secondes avant de les afficher, afin de disposer du temps nécessaire pour éventuellement envoyer un message NACK lorsqu'un paquet est manquant et pouvoir recevoir le renvoi. Ainsi, puisque le film commence dès qu'un passager démarre le visionnage, au début il voit les images telles qu'elles sont reçues instantanément par la borne WiFi 2, avec un taux d'erreur nominal tW correspondant au taux d'erreur nominal de la liaison WiFi de base, sans le mécanisme d'accusés de réception négatifs retardés selon l'invention. Par exemple, tW peut valoir 10"4 en moyenne avec des pics à 10"3. Cela signifie que, en moyenne, pour 10000 paquets de données émis par le module 3 émetteur, 1 paquet n'est pas reçu par le module 6 récepteur, mas que cela peut monter jusqu'à 1 paquet non reçu pour seulement 1000 paquets envoyés. Puis, lorsqu'il avance dans le film le passager voit les images telles qu'elles ont été reçues il y a quelques secondes par la borne WiFi, avec un taux d'erreur corrigé ti correspondant au taux d'erreur selon l'invention, c'est-à-dire incluant éventuellement des paquets renvoyés une deuxième fois grâce au mécanisme d'accusés de réception négatifs retardés selon l'invention. Par exemple, ti peut valoir 10"6, c'est-à-dire que pour 1000000 de paquets de données émis par le module 3 émetteur, 1 paquet n'a pas été reçu par le module 6 récepteur. Il est important de noter qu'un but important du mécanisme de retransmission retardée décrit précédemment est de décorréler temporellement la retransmission d'un paquet de l'événement à l'origine du micro-fading et de la perte initiale du paquet. Il est à noter également qu'il ne s'agit pas d'une mise en mémoire tampon à proprement parler puisque, initialement au démarrage du film, il n'y a pas de données conservées en mémoire. Il s'agit plutôt d'un mécanisme d'accumulation d'avance, décrit en détails par la suite, obtenu notamment en démarrant une session avec un débit de téléchargement supérieur au débit de lecture. Il est à noter également qu'en permanence, l'écran inclus dans le module 6 peut éventuellement atténuer l'inconfort visuel que peuvent provoquer les erreurs résiduelles, ceci par des procédés de lissage de l'image par exemple. De tels procédés ne corrigent pas à proprement parler les erreurs, ils les rendent simplement moins visibles ou moins audibles. Ils permettent cependant d'atteindre un taux d'erreur visible ou audible ta,v tel quetw>ti>ta,v• La figure 2 illustre par un graphe le mécanisme d'accumulation d'avance mis en oeuvre par l'invention dans l'exemple de la figure 1, dans un système d'axes où l'axe des abscisses représente la durée d'une session en secondes et l'axe des ordonnées représente le débit en Mbps sur la liaison entre le serveur 3 et le client 6. Le serveur 3 envoie des paquets de données au client 6 pendant 1000 secondes à un débit nominal D égal à 10 Mbps, qui correspond au débit nécessaire à l'affichage instantané des données vidéo reçues. Le flux de données correspondant est décomposé en 2 parties. Une première partie P constitue un flux Principal de données. Le flux P est composé de paquets de données vidéo envoyées pour la première fois en vue d'être affichées instantanément. Une deuxième partie R constitue un flux de données de Retransmission . Le flux R est composé de paquets de données vidéo envoyées pour la deuxième, la troisième ou pour la n1ème fois en général, avec n>2. Le flux R correspond à un débit égal à 0 la plupart du temps, ce qui sera écrit sous la forme R=0 par la suite. Le flux R ne prend que ponctuellement des valeurs non nulles, quand un ou plusieurs paquets sont perdus. Un troisième flux A est un flux de données correspondant à une Avance accumulée. Le flux A est composé de paquets de données vidéo envoyées pour la première fois en vue d'être affichées ultérieurement. Le flux d'avance A peut par exemple avoir un débit égal à 10% au maximum du débit nominal D, ce qui sera écrit sous la forme A=DxO,1 par la suite, c'est-à-dire A=1 Mbps. Grâce au flux A, un débit de 10% au-dessus du débit nominal de données D peut être utilisé par le serveur 3, ceci afin de prendre de l'avance sur le flux de données affichées instantanément. En permanence P+R=D, c'est-à-dire que le flux principal P et le flux de retransmission R ne dépassent par le débit nominal D. Lorsque R≠0, c'est-à-dire lorsque des paquets de données sont perdus et que le client 6 envoie des messages NACK , le flux principal P diminue afin cle pouvoir renvoyer des paquets de données. C'est ce qui se passe à un instant t2 correspondant à un peu moins de 500 secondes de session, où P=9 Mbps et R=1 Mbps. Il faut noter que A=0 à l'instant t2. Le serveur 3 envoie alors les paquets de données à un débit de D=10 Mbps. En effet, le mécanisme d'accumulation d'avance que représente le flux A n'est utilisé que quand il n'y a pas de retransmission en cours, c'est-à- dire que quand R=0 et P=D. Dans ce cas, le serveur 3 ne reçoit aucun message NACK du client 6, il fait donc l'hypothèse que la qualité de la liaison est suffisante pour aller un peu plus vite et il augmente le débit d'émission des paquets de données. C'est ce qui se passe à un instant t, correspondant à un peu plus de 350 secondes de session, où R=0 et P=D=10 Mbps et A=DxO,1=1 Mbps. Le serveur 3 envoie alors les paquets de données à un débit de Dx1,1=11 Mbps, soit 10% au-dessus du débit nominal D correspondant au débit d'affichage par le client 6, qui accumule donc desdonnées vidéo d'avance. L'avance que le client 6 peut prendre est cependant limitée. Dans l'exemple des figures 1 et 2, l'avance est limitée à 60 secondes d'affichage. Ceci explique qu'à partir d'un instant t3 correspondant à un peu moins de 800 secondes ou environ 13 minutes de session, le flux A s'effondre et tend quasiment vers un débit nul. Il est important de noter qu'un but important du présent mécanisme d'accumulation d'avance, basé sur trois flux assurant un débit entre 100% et 110% d'un débit fixe D, est de limiter le débit descendant utilisé pour envoyer des paquets à chacun des nombreux clients simultanés, dont le client 6. Ainsi, la dégradation du niveau de réception sur la liaison entre le serveur 3 et le client 6 ne risque pas d'avoir des impacts négatifs sur les liaisons entre le serveur 3 et d'autres clients. Car quel que soit le nombre de retransmissions nécessaires du serveur 3 vers le client 6, le débit 1 o descendant total du serveur 3 vers le client 6 ne peut excéder 110% de D, quitte à ne pas retransmettre des paquets perdus. La figure 3 illustre par un graphe le phénomène d'accumulation de l'avance dans l'exemple de mise en oeuvre de l'invention de la figure 1, dans 15 un système d'axes où l'axe des abscisses représente la durée de la session en secondes et l'axe des ordonnées représente la durée d'avance cumulée en secondes. Une courbe 10 représente l'évolution de l'avance cumulée, c'est-à-dire l'intégrale de A par rapport au temps, que l'on notera fA par la suite. Au démarrage de la session, c'est-à-dire à l'instant 0, l'avance cumulée 20 fA est nulle. A un instant t4 correspondant à 500 secondes de session, l'avance cumulée fA est un peu inférieure à 40 secondes. A l'instant t3 déjà illustré par la figure 2, c'est-à-dire après environ 13 minutes de session, l'avance cumulée fA atteint 60 secondes, qui est la valeur maximale d'avance autorisée dans cet exemple de mise en oeuvre de l'invention. Ainsi, 25 à partir de l'instant t3, l'avance cumulée fA n'augmente plus et reste constante à 60 secondes. Ceci s'explique par le fait que le flux A a un débit voisin de 0 à partir de l'instant t3. Le serveur 3 envoie alors les paquets de données au client 6 au débit nominal D = P+R = 10 Mbps. II est à noter que, même après l'instant t3, la marge de 10% au-delà du débit nominal D doit 30 être réservée pour le client 6, même si cette marge n'est pas utilisée. En effet, à tout moment la qualité de réception peut se dégrader et entraîner des pertes de paquets de données. La part du flux de retransmissions R augmente alors au détriment de la part du flux principal P, auquel cas l'avance accumulée fA doit être entamée, puis reconstituée ultérieurement. 35 La reconstitution de l'avance accumulée fA pour la ramener à la valeur de 60 secondes nécessite de rétablir le flux d'avance A à un débit voisin de 1 Mbps. II est à noter également que la valeur optimale de l'avance autorisée dépend de nombreuses variables, comme de la quantité de mémoire disponible du coté du client 6 pour stocker des données vidéo. Dans le présent exemple de mise en oeuvre, le mécanisme d'accumulation d'avance selon l'invention permet en tout cas au client 6 d'afficher des données vidéo qu'il a reçues 60 secondes auparavant et ainsi de pouvoir retarder l'envoi d'un message NACK lorsqu'il lui manque un paquet de données dans les paquets reçus. Le client 6 reçoit les paquets de données dans l'ordre où ils arrivent à la borne WiFi 2. Certains paquets reçus sont des paquets envoyés pour la première fois. D'autres paquets sont des paquets retransmis. Par conséquent, le client 6 doit d'abord ré-ordonner ces paquets selon leur numéro de séquence RTP. Au bout d'un certain temps, grâce au mécanisme d'accumulation d'avance décrit précédemment, le client 6 accumule un segment ordonné de données vidéo d'avance. Eventuellement ce segment comporte des données manquantes qui constituent des trous. II peut contenir jusqu'à 60 secondes de vidéo, mais avec des trous. Dans le présent exemple de mise en oeuvre de l'invention, le client 6 met par exemple en oeuvre un mécanisme qui, par analogie et pour faciliter le présent exposé, sera désigné par le terme nettoyeur . Un nettoyeur est un mécanisme consistant à accéder dans l'ordre aux données du segment, mais un certain délai après qu'elles ont été reçues, ceci afin de nettoyer les erreurs. II s'agit de détecter les numéros de séquence absents dans le segment, c'est-à-dire les trous, en vue d'envoyer un message NACK pour ces numéros de séquence manquants. Chaque nettoyeur est caractérisé par un délai OT de retard par rapport au flux des données reçues. Par exemple, un premier nettoyeur peut accéder dans le segment aux données qui ont été reçues 2 secondes auparavant. Un deuxième nettoyeur peut accéder dans le segment aux données qui ont été reçues 20 secondes auparavant. Un troisième nettoyeur peut accéder dans le segment aux données qui ont été reçues 40 secondes auparavant. Le nombre de nettoyeurs et leurs délais respectifs (AT;) de retard peuvent varier. Ainsi, l'envoi d'un message NACK par le client 6 est décalé de 2, 20 ou 40 secondes par rapport: à l'envoi correspondant par le serveur 3. U est important de noter que ce sont les nettoyeurs qui permettent de retarder les retransmissions selon l'invention. Les nettoyeurs peuvent maintenir leur délai de retard par rapport au flux des données reçues par divers moyens. Par exemple, une fonction peut calculer toutes les secondes l'intervalle de temps moyen entre les paquets reçus durant la dernière seconde. Ce temps moyen sera appelé par la suite intervalle inter-paquets . Si aucun paquet n'a été reçu dans la dernière seconde ou si le dernier intervalle inter-paquets calculé est plus grand que le précédent, ce qui signifie que moins de paquets ont été reçus dans la dernière seconde écoulée que dans la précédente, alors c'est la dernière valeur calculée de l'intervalle inter-paquets qui est conservée. Grâce à l'intervalle inter-paquets, chaque nettoyeur peut par exemple calculer dynamiquement de combien de paquets il doit rester derrière le flux des données reçues. Par exemple, si la valeur courante de l'intervalle inter-paquets vaut 1 milliseconde, le nettoyeur à 2 secondes doit rester 2000 paquets derrière le flux des données reçues. Si le dernier paquet reçu par le client 6 est numéroté 200 000 et que le nettoyeur est au paquet 199 000, alors le nettoyeur sait qu'il a une seconde d'avance et attend une seconde afin de maintenir précisément 2 secondes d'avance sur le flux des données reçues. Quand le flux des données reçues se termine, parce-que le serveur 3 a fini d'envoyer le fichier vidéo par exemple, le nettoyeur va continuer et vérifier les dernières données reçues. Ceci assure qu'il n'y a pas d'erreur non plus à la fin du film. Le client 6 est également limité en nombre de requêtes de retransmission. Ceci peut être fait par exemple grâce à un mécanisme de crédit de retransmission implémenté par un compteur. Un crédit de retransmission est une valeur entière positive ayant une valeur maximum égale à 100000 par exemple. Le client 6 peut par exemple incrémenter le compteur de 1 chaque fois qu'un paquet est reçu. Pour pouvoir envoyer un message NACK lorsqu'un paquet manquant est détecté par un nettoyeur, le client 6 doit pouvoir décrémenter son compteur de 100 par exemple, sachant que le compteur ne peut être négatif. Dans l'exemple de message NACK(15,18) donné précédemment, le client 6 doit pouvoir décrémenter 16 son compteur de 300. Ceci limite le taux d'erreur récupérable par l'invention à environ 10-2 et limite à un maximum de 1000 retransmissions à la suite pour le client 6. II est important de noter qu'un but important du mécanisme de crédit de retransmission décrit précédemment est de limiter le débit ascendant utilisé par chacun des nombreux clients simultanés, dont le client 6, pour envoyer des messages NACK au serveur 3. Ainsi, la dégradation du niveau de réception sur la liaison entre le serveur 3 et le client 6 ne risque pas d'avoir des impacts négatifs sur les liaisons entre le serveur 3 et d'autres clients. Car quel que soit le nombre de retransmissions nécessaires, le débit ascendant total du client 6 vers le serveur 3 pour envoyer des messages NACK est limité, quitte à ne pas pouvoir obtenir la retransmission de paquets perdus. Malgré les retransmissions retardées, le flux vidéo peut être affiché au passager sans retard ou presque. En effet, si par exemple un délai imperceptible de seulement 3 secondes est autorisé entre le moment où le passager appuie sur le bouton de lecture et le moment où la vidéo est réellement affichée à l'écran, ceci est suffisant pour rendre l'invention efficace dès le début de session. II faut noter qu'un tel délai de 3 secondes est quasiment imperceptible par le passager et qu'il est bien inférieur au temps nécessaire pour télécharger une vidéo sur internet. Durant ces 3 premières secondes, les données vidéo peuvent être téléchargées sans être affichées. L'affichage peut commencer lorsque le segment de données contient 3 secondes de vidéo. A ce moment là, le premier netloyeur à 2 secondes a déjà pu demander des paquets éventuellement perdus dans la première seconde de téléchargement. Donc, la première seconde de vidéo affichée a subit une correction par retransmissions selon l'invention. Le premier nettoyeur corrige habituellement la plupart des erreurs. Si le taux d'erreur nominal tW, c'est-à-dire le taux avant retransmission selon l'invention, est inférieur à 10-3, alors environ 99% des erreurs sont corrigées par le premier nettoyeur à 2 secondes. Par référence au taux d'erreur t; corrigé selon l'invention, les taux d'erreur corrigés par retransmission grâce au nettoyeur à 2 secondes, grâce au nettoyeur à 20 secondes et grâce au nettoyeur à 40 secondes seront respectivement appelés t;2, t;20, et t40 par la suite. Ainsi, dans la première seconde le taux t;2 est inférieur à 10"5. Une très bonne qualité de vidéo peut donc être obtenue dès le début, même si la liaison est de mauvaise qualité. II faut noter que les nettoyeurs à 20 et à 40 secondes ne sont pas encore actifs quand l'affichage commence. Ils ne seront opérants qu'une fois que le segment aura été rempli suffisamment, c'est-à-dire quand il contiendra au moins 21 secondes de vidéo pour le nettoyeur à 20 secondes et au moins 41 secondes de vidéo pour le nettoyeur à 40 secondes. Or, d'après le graphe de la figure 3, il faut environ 4 minutes pour accumuler 20 secondes d'avance et 8 minutes pour accumuler 40 secondes d'avance. De plus, il a été mesuré expérimentalement que chacun des deuxième et troisième nettoyeurs permet de diviser par un fadeur 10 le taux d'erreur. Cela signifie que même dans un pire cas où le taux d'erreur nominal t, est égal à 10-3 avant toute retransmission selon l'invention, le flux vidéo affiché a un taux d'erreur t; corrigé selon l'invention qui est meilleur que 10"5 dans les 4 premières minutes, meilleur que 10-6 entre les 4èrne et Sème minute et meilleur que 10"' après la 8ème minute. Bien-sûr, les délais affectés aux nettoyeurs peuvent être changés s'ils sont considérés trop longs par rapport à l'ensemble des données vidéo à afficher. Mais il est à noter que plus un nombre important de nettoyeurs sont mis en oeuvre, plus la taille du segment augmente et plus l'espace mémoire nécessaire chez le client 6 augmente également. Enfin, les mécanismes d'accumulation d'avance et de retransmission retardée décrits précédemment sont efficaces en faisant l'hypothèse qu'aucune commande de retour en arrière pour revoir une séquence ou encore d'avance rapide pour sauter des séquences ne soit passée par le passager. Si le passager utilise de telles commandes, d'autres techniques complémentaires pour exploiter le segment existant doivent être implémentées, afin notamment d'éviter que le segment ne reparte à vide quand la lecture normale reprend. Mais cela va au-delà du cadre du présent exposé. L'exemple de mise en oeuvre de l'invention illustré par les figures 1, 2 et 3 implémente une norme 802.11 à titre d'exemple uniquement. En effet, il faut bien comprendre que l'invention est complètement indépendante de la liaison WiFi. L'invention peut être mise en oeuvre sur d'autres types de liaison, avec ou sans fil, et pour d'autres types d'application que des applications vidéo. L'invention décrite précédemment a encore pour principaux avantages que si le taux d'erreur est inférieur à 10"3 au début, alois il peut être garanti que par la suite il tombera en dessous de 10"6, c'est-à-dire un flux vidéo quasiment sans erreur et qui peut donc facilement être corrigé par le module d'affichage. REVENDICATIONS 1. Procédé d'envoi de paquets de données d'un serveur (3) vers un client (6), le client utilisant simultanément à un débit constant D les données qu'il reçoit, caractérisé en ce que : un flux de paquets de données du serveur vers le client est composé d'un flux principal P, d'un flux de retransmission R pour renvoyer les paquets n'ayant pas été reçus par le client et d'un flux de prise d'avance A pour accumuler des données chez le client, le débit du flux principal P étant fixé à D et le débit du flux de prise d'avance A étant fixé à une certaine valeur lorsque le débit du flux de retransmission R est nul, le débit du flux de prise d'avance A étant nul et la somme des débits du flux principal P et du flux de retransmission R étant fixée au débit D lorsque le débit du flux de retransmission R n'est pas nul ou lorsque le client a accumulé des données au-delà d'un certain seuil S ; - un paquet envoyé par le serveur mais pas reçu par le client est renvoyé au client un certain délai AT après son premier envoi, le délai AT vérifiant AT x D 2. Procédé selon la revendication 1, caractérisé en ce que le serveur envoie des paquets de données par ledit procédé à plusieurs clients en même temps. 3. Procédé selon la revendication 1, caractérisé en ce que, lorsque le débit du flux de retransmission R est nul, le débit du flux de prise d'avance A est fixé à p x D, où p est un nombre réel tel que 0 4. Procédé selon revendication 1, caractérisé en ce que le serveur numérote les paquets de données qu'il envoie au client, le client informant le serveur que, sur la base de la numérotation des paquets, il manque des paquets parmi les paquets de données qu'il a accumulés et pour lesquels le délai AT s'est écoulé depuis qu'ils auraient du être reçus.25 5. Procédé selon revendication 1, caractérisé en ce que le client informe successivement le serveur qu'il manque des paquets parmi les paquets de données qu'il a accumulés et pour lesquels des délais successifs (AT), i appartenant à {1,...n}, se sont écoulés depuis qu'ils auraient du être reçus, AT; vérifiant AT;xD 6. Procédé selon la revendication 4 ou 5, caractérisé en ce que le client estime le temps moyen entre la réception de deux paquets consécutifs, la ~o différence entre le numéro du dernier paquet reçu et le numéro de chaque paquet accumulé étant multipliée par le temps moyen afin de déduire le délai écoulé depuis qu'a été reçu ledit paquet. 7. Procédé selon la revendication 4, caractérisé en ce que le client informe 15 le serveur en lui envoyant un message d'accusé de réception négatif (NACK), le message indiquant des numéros de paquets manquant, le serveur renvoyant au client les paquets dont le numéro est indiqué dans le message. 20 8. Procédé selon la revendication 7, caractérisé en ce que le client incrémente un compteur d'une valeur positive r lorsqu'il reçoit un paquet du serveur et qu'il n'envoie un message d'accusé de réception négatif indiquant au serveur des numéros de paquets manquant que s'il peut décrémenter le compteur d'une valeur positive m, où m>r, autant de fois 25 qu'il y a de paquets manquant et sans que le compteur prenne une valeur négative. 9. Procédé selon la revendication 1, caractérisé en ce que le client envoie les paquets de donnée au client par l'intermédiaire d'une liaison conforme 30 à la norme 802.11 ou de toute autre liaison avec ou sans fil susceptible de perdre des paquets. 10. Procédé selon la revendication 1, caractérisé en ce que les données sont des données vidéo, le client affichant sur un écran les données vidéo qu'il 35 reçoit simultanément du serveur. 11. Procédé selon la revendication 10, caractérisé en ce que les données vidéo affichées sur l'écran sont visionnables par un passager d'un aéronef.5