FR2956271A1 - Procede et dispositif de calcul de l'espace disponible dans un paquet pour le transport de flux de donnees - Google Patents

Abstract

Le procédé de calcul de l'espace disponible dans un paquet pour le transport de flux de données comporte : - une étape de détermination des besoins de chaque module d'un gestionnaire de flux de données, en espace du paquet pour au moins deux types de données d'entête et/ou d'extension requis par chaque protocole et/ou service utilisé par ledit module, - une étape de détermination d'un besoin d'espace maximal dans le paquet pour répondre à l'ensemble de ces besoins, en mettant en œuvre des règles de combinaison de besoins d'espace différentes pour les différents types de données et une somme des besoins combinés pour les différents types de données et - une étape de calcul d'une différence entre l'espace du paquet et le besoin d'espace maximal dans le paquet pour déterminer l'espace disponible pour le transport du flux de données.

Description

Procédé et dispositif de calcul de l'espace disponible dans un paquet pour le transport de flux de données

La présente invention concerne un procédé et un dispositif de calcul de l'espace disponible dans un paquet pour le transport de flux de données. L'invention s'applique, en particulier, à la formation de paquets (« paquétisation ») de données applicatives, notamment multimédia, et, plus particulièrement, au calcul de l'espace disponible dans un paquet réseau pour y placer des données applicatives. Le domaine technique de l'invention est celui des réseaux de communications de paquets et du transport de données multimédia (audio, vidéo, texte) dans ces réseaux tel que l'Internet ou les réseaux locaux de type IP (« Internet Protocol »).

Dans le cadre de la transmission de flux de données multimédia sur Internet ou sur réseaux locaux ou « LAN » (de l'anglais « local area network »), un serveur de données multimédia doit délivrer un ou plusieurs flux de données (de type vidéo, audio, texte, par exemple sous-titres, ...) vers un ou plusieurs clients simultanément. Ces clients reçoivent et exploitent ces données au fur et à mesure de leur réception. Par exemple, le client affiche la vidéo et diffuse l'audio au fur et à mesure qu'il les reçoit. On parle alors de « multimedia streaming ». Généralement, les données constituant ces flux multimédia (vidéo, audio, texte) peuvent être stockées et, éventuellement, compressées à l'avance sur le serveur de données (exemple : disque dur multimédia) ou au contraire être capturées puis, éventuellement, compressées à la volée (par exemple dans le cas de caméras réseau). Ces données sont ensuite découpées en plusieurs morceaux de données applicatives (en anglais « payload data ») qui sont paquétisés par ajout d'un nombre variable d'entêtes (en anglais « header ») ou d'extensions. Ces entêtes et extensions contiennent notamment des informations de contrôle associées aux différentes couches de protocole (en anglais « protocol layer » ou aux services utilisés). Ils forment ainsi des paquets pouvant être transportés jusqu'à leurs destinataires à travers les réseaux. Un exemple de protocole adapté au transport de flux de données multimédia est le protocole « RTP » (de l'anglais « Real-time Transport Protocol ») au dessus des protocoles UDP/IP (de l'anglais « User Datagram Protocol »).

Pour des raisons d'efficacité, en évitant une fragmentation des paquets par des couches de protocoles inférieures, ces paquets réseaux RTP ont généralement une taille maximale utile fixée par le protocole de transport utilisé au niveau du réseau physique. Par exemple, sur un réseau de type « Ethernet », la taille maximale utile d'un paquet est généralement limitée à 1500 octets. Cette taille maximale utile se partage entre les données applicatives et l'ensemble des entêtes de données nécessités par les différentes couches de protocole. Par exemple, après ajout des entêtes UDP/IP, un paquet RTP est ainsi limité à 1472 octets. Afin de maximiser le débit utile du réseau du point de vue de l'application, il est important que les données applicatives soient découpées de manière à occuper la plus grande place possible dans un paquet réseau. Le découpage des flux multimédia en morceaux de données applicatives peut être dynamiquement adapté, soit au niveau de l'encodage, soit au niveau de la paquétisation. L'adaptation au niveau de l'encodeur est possible quand la compression est réalisée à la volée en modifiant, par exemple, la taille des portions d'images (« slices ») ou des portions de sons (« samples »). L'adaptation au niveau de la paquétisation est possible quand celle-ci permet de fragmenter ou de combiner plusieurs morceaux de données applicatives dans un même paquet réseau (par exemple comme avec la paquétisation « H.264 »). Une fois découpées, une technique, connue de l'homme du métier, consiste à placer les données applicatives dans une mémoire tampon directement à la bonne place en laissant suffisamment d'espace en début de mémoire tampon pour pouvoir y ajouter, par la suite, l'ensemble des entêtes.

Les entêtes sont ainsi ajoutés au fur et à mesure par les différentes couches de protocole sans avoir à copier ou déplacer les données applicatives. Cette

technique est ainsi efficace en termes de ressource mémoire et de ressource processeur. Le problème est de déterminer la taille disponible dans un paquet réseau pour les données applicatives et l'emplacement dans la mémoire tampon à partir duquel les données doivent être placées. Par ailleurs, le serveur est susceptible d'envoyer les mêmes flux de données multimédias vers plusieurs clients à la fois. Par exemple en multiunicast, une communication unicast différente est établie entre chaque client et le serveur. Chaque paquet réseau est donc envoyé séquentiellement à chacun des clients. Dans ce cas, la même donnée applicative est transmise à plusieurs clients différents et seuls les entêtes sont adaptés à chaque client. Pour déterminer la taille des données applicatives, on tient compte des contraintes d'entêtes de chacun des clients pour qu'une donnée applicative puisse être transmise à l'ensemble des clients sans être déplacée en mémoire.

De plus, chaque client peut négocier l'utilisation de différents services (service de contrôle de congestion, service de correction des erreurs de transmission basé par exemple soit sur un mécanisme de retransmission ou soit sur un mécanisme de redondance de données, par exemple). Ces services peuvent nécessiter la création de sous-flux de données dépendant du flux de données original (par exemple un flux de retransmission ou de redondance des données en complément du flux original). Ces services peuvent également nécessiter l'ajout d'informations supplémentaires sous la forme d'entête soit dans le flux original soit dans le sous-flux de données ou soit dans les deux à la fois. Par exemple, dans le cas d'une retransmission, en cas de perte d'un paquet dans le flux principal, le paquet perdu doit être retransmis dans un flux associé (qu'on désignera comme un sous-flux). Tel que décrit dans la RFC 4588 (« RTP Retransmission Payload Format », IETF, RFC 4588, July 2006) décrivant un mécanisme de retransmission sur RTP, un entête de deux octets supplémentaires doit également être ajouté à la donnée applicative originale pour décrire le numéro de séquence du paquet original perdu. Il est donc nécessaire de prévoir cette éventualité dès le découpage en morceaux des données multimédias. Dans le cas contraire la donnée multimédia ne pourrait pas être retransmise par manque de place dans le paquet réseau. De plus, certaines de ces informations supplémentaires peuvent présenter un caractère persistant d'un flux vers un autre sous-flux, c'est-à-dire qu'elles doivent être répétées à la fois dans le flux original et le sous-flux associé ou au contraire elles peuvent présenter un caractère local (dépendant du flux). Dans ce deuxième cas, il n'est pas nécessaire de les répéter d'un flux vers un sous-flux. Il faut donc également tenir compte de ces contraintes pour déterminer la taille disponible pour les données applicatives de manière à ce qu'elle puisse être envoyée à l'ensemble des clients, flux et sous-flux sans nécessiter de fragmentation ou recopie mémoire. Ainsi, déterminer à tout instant quelle est la taille optimale des données applicatives à placer dans les tampons mémoire afin de pouvoir être transmises à l'ensemble des clients de manière la plus efficace en terme de ressource mémoire et processeur et cela en adéquation avec les différents services utilisés par chacun des clients est particulièrement complexe. On connaît l'article « A driver-based approach to protocol stack design » (de Curt Schwaderer, Microware Systems Corp., publié dans Electronic Engineering Times-India (www.eetindia.co.in) en Septembre 1999) qui décrit une approche permettant de concevoir des piles de protocoles réseaux tout en améliorant leur efficacité. Il propose qu'un module de services réseaux détermine la taille maximale des informations devant être ajoutées en entête (« header ») et en queue (« trailer ») des paquets réseaux en interrogeant chacun des modules constituant la pile de protocoles. Il réalise cette opération à la création et à chaque changement de la pile de protocoles (en anglais « Protocol stack »). Ainsi, quand l'application envoie un message (par exemple, « hello world »), le module de services réseaux peut directement allouer deux mémoires tampons suffisamment grandes pour contenir l'ensemble des informations ajoutées respectivement en tête et en queue de paquets par chacun des modules constituant la pile de protocoles. Ces modules n'ont plus alors qu'à ajouter leurs informations dans ces mémoires tampons sans avoir à faire de nouvelle allocation mémoire ou copie. L'approche décrite dans cet article ne permet pas de gérer différents types d'entêtes (persistant ou local), la présence de sous-flux de données ou de plusieurs destinataires pour un même ensemble de données applicatives. On connaît aussi l'article « Full TCP/IP for 8-bit architectures » (de Adam Dunkels, Swedish Institute of Computer Science) publié dans Proceedings of MobiSys 2003, Mai 2003. Cet article décrit l'implémentation de deux piles de protocoles TCP/IP adaptées, en termes de taille de code et de consommation mémoire, à s'exécuter sur des plateformes matérielles 8-bits et 16-bits. Il décrit notamment en section 5 comment la gestion de la mémoire et des mémoires tampons a été optimisée pour ne nécessiter que quelques kilo-octets de mémoire vive (RAM). En particulier : - les paquets réseaux sont placés dans des mémoires tampons de taille fixe. La taille est déterminée par une option de configuration à la compilation, - les mémoires tampons contiennent suffisamment de place pour que la pile de protocole TCP/IP puisse rajouter les informations d'entête de paquets devant les données applicatives (aussi appelées « payload data »), celles-ci étant placées directement à la bonne place dans les mémoires tampons pour éviter une copie ultérieure et - chaque mémoire tampon contient un compteur de références (en anglais « Reference counter »). Il est incrémenté à chaque fois qu'une nouvelle référence sur la mémoire tampon est créée par un module et décrémenté à chaque fois que cette référence est libérée. La mémoire tampon proprement dite n'est libérée qu'une fois que son compteur de référence atteint la valeur « 0 ». Le compteur de référence permet ainsi de limiter le nombre de copies de la mémoire tampon. Cette implémentation ne permet pas de gérer des entêtes de tailles variables suivant les services effectivement activés par les différents destinataires ou la présence de sous-flux de données.

On connaît aussi la demande de brevet US 2009/0028142, « Streaming Data Content ln A Network » (de Brian K. Schmidt et al., Juillet 2007), qui décrit un système de transmission de flux de données encodées

dans lequel la génération du flux de données inclut la génération d'informations de résumé. Les informations de résumé sont ensuite associées à chacun des paquets réseaux en complément des données elles-mêmes. Ces informations de résumé permettent ensuite au récepteur des paquets réseaux de traiter, au moins en partie, les paquets reçus sans avoir à les décoder entièrement. Les informations de résumé sont de taille fixe et sont insérées dans chacun des paquets sous la forme d'un ou plusieurs entêtes situés entre l'entête RTP et les données applicatives. On évalue la place disponible dans un paquet réseau pour les données applicatives comme étant la taille maximale du paquet réseau UDP (1472 octets) moins la taille de l'entête RTP (12 octets) moins la taille des informations de résumé (par exemple une taille fixe de 88 octets). Ce système ne permet pas de gérer la taille des données applicatives disponible dans un paquet réseau de manière dynamique suivant les services effectivement activés par les différents destinataires ou la présence de sous-flux de données.

La présente invention vise à remédier à ces inconvénients. A cet effet, selon un premier aspect, la présente invention vise un procédé de calcul de l'espace disponible dans un paquet pour le transport de flux de données, qui comporte : - une étape de détermination des besoins de chaque module d'un gestionnaire de flux de données, en espace du paquet pour au moins deux types de données d'entête et/ou d'extension requis par chaque protocole et/ou service utilisé par ledit module, - une étape de détermination d'un besoin d'espace maximal dans le paquet pour répondre à l'ensemble de ces besoins, en mettant en oeuvre des règles de combinaison de besoins d'espace différentes pour les différents types de données et une somme des besoins combinés pour les différents types de données et - une étape de calcul d'une différence entre l'espace du paquet et le besoin d'espace maximal dans le paquet pour déterminer l'espace disponible pour le transport du flux de données. L'invention permet ainsi de gérer différents types d'informations additionnelles venant s'ajouter aux données applicatives lors de la génération d'un paquet réseau. Par exemple, les entêtes de données applicatives (« payload header ») de type persistants ou dépendantes d'un flux de données, les extensions à l'entête de base RTP de type persistantes ou purement dépendantes d'un flux de données et les entêtes de taille fixe (par exemple, les entêtes de base RTP). Grâce à la mise en oeuvre de la présente invention, il n'est plus nécessaire de dupliquer/copier les données du flux, par exemple les données applicatives, même si elles sont envoyées à plusieurs destinataires (cas du multi-unicast) ou si elles doivent être retransmises plusieurs fois au même client. Le système consomme ainsi moins de ressource mémoire et moins de ressource processeur. Selon des caractéristiques particulières, le procédé objet de la présente invention comporte : - une étape de détection d'un événement parmi les suivants : o arrivée d'un client destinataire du flux de données dans un réseau de transmission dudit flux de données, o départ d'un client destinataire du flux de données du réseau, o activation d'au moins un module du gestionnaire de flux de 20 données, et o désactivation d'au moins un module du gestionnaire de flux de données ; et - une étape de détermination du gestionnaire de flux de données concerné par ledit événement, ledit gestionnaire de flux de 25 données effectuant les étapes de détermination de besoins et de calcul. Ainsi, la taille disponible pour les données du flux de données dans un paquet réseau est toujours optimale. Elle est ré-estimée à chaque fois qu'un client se connecte ou se déconnecte au système et à chaque activation ou 30 désactivation d'un service par l'un des clients. Selon des caractéristiques particulières, au cours de l'étape de détermination des besoins de chaque module en espace du paquet pour au moins deux types de données, les types comportent au moins un type d'extension persistante et au moins un type d'extension dépendante du flux de données. Selon des caractéristiques particulières, au cours de l'étape de 5 détermination des besoins de chaque module en espace du paquet pour au moins deux types de données, les types comportent : - au moins l'un des types suivants : o extension d'entête RTP persistante (PHE) et o extension de données applicatives persistante (PPE), et 10 - au moins l'un des types suivants : o extension d'entête RTP dépendante du flux de données (SDHE) et o extension de données applicatives dépendante du flux de données (SDPE). 15 Selon des caractéristiques particulières, au cours de l'étape de détermination d'un besoin d'espace maximal dans le paquet pour répondre à l'ensemble de ces besoins, on met en oeuvre : - pour la combinaison de besoins d'espace de type d'extension persistante, une opération d'addition de besoins et, 20 - pour la combinaison de besoins d'espace de type d'extensions dépendante du flux de données, une opération d'extraction de valeur maximum de besoins. Selon des caractéristiques particulières, au cours de l'étape de détermination des besoins de chaque module, si ledit module est une source 25 d'un sous-flux du flux de données, on détermine le besoin en espace du paquet pour au moins deux types de données du sous-flux. Selon des caractéristiques particulières, au cours de l'étape de détermination d'un besoin d'espace maximal dans le paquet pour répondre à l'ensemble des besoins, on met en oeuvre, pour l'ensemble des sous-flux dudit 30 flux de données, une opération d'extraction de la valeur maximale des besoins des sous-flux pour chaque type de données.

Selon des caractéristiques particulières, au cours de l'étape de détermination d'un besoin d'espace maximal dans le paquet pour répondre à l'ensemble des besoins R, on met en oeuvre, pour l'ensemble des modules Mi qui composent le gestionnaire de flux S et les sous-flux Sj dont le gestionnaire de flux hérite, les équations suivantes : - pour les extensions d'entête persistantes PHE : modules de traitements Sous -flux RPHE(S) _ L RPHE(M) +max(RPHE(S,))

J - pour les extensions d'entête dépendantes du flux de données SDHE : ( modules de traitements Sous -flux RSDHE(S) =max L RSDHE (Mi),max(RSDHE (Sj)) - pour les extensions de données applicatives persistantes PPE : modules de traitements Sous -flux

R PPE (S) _ L R PPE (M ) + max (R PPE (S,)) et J Z j - pour les extensions de données applicatives dépendantes du flux de données SDPE : ( modules de traitements Sous -flux R SDPE (S) = max L R sDPE (M ) , max (R SDPE (S j ))

J puis, pour calculer le besoin total RE (S), ( modules de traitements sous-flux RE(Mi),max(RE(s1 )) M, s, équation dans laquelle « E » désigne le type d'information d'extension c'est-à-dire l'un des types PHE, SDHE, PPE ou SDPE, et OE 20 désigne une opération dépendant du type E, avec : - 0SDHE et 0SDPE correspondant à l'opération « max » qui extrait la valeur maximum d'un couple de valeurs et - OPHE et OPPE correspondant à l'opération « + » qui additionne les valeurs du couple de valeurs. 15 / RE(S)=OE Selon des caractéristiques particulières, le procédé objet de la présente invention comporte, en outre, une étape de réservation d'espace de paquet auprès d'une fabrique de mémoires tampons rattachée à la source du flux considéré, en indiquant le résultat de l'étape de calcul de différence, et une étape de calcul, par la fabrique, du maximum des demandes de réservation d'espace pour, lors d'une demande d'un nouveau tampon de mémoire pour y placer des nouvelles données du flux, retourner un tampon de mémoire avec un pointeur sur l'emplacement à partir duquel les données du flux peuvent être placées en fonction du maximum des demandes de réservation d'espace en début de mémoire tampon. Selon des caractéristiques particulières, le procédé objet de la présente invention comporte, pour chaque donnée du flux de données : - une étape d'écriture unique de ladite donnée dans la mémoire tampon, après ledit pointeur et, - pour chaque transmission de ladite donnée à un destinataire, une étape d'écriture de données d'entête et/ou d'extension pour chaque module du gestionnaire de flux de données associé à ladite transmission. Ainsi les données applicatives ne sont pas recopiées ou déplacées pour être transmises à différents destinataires, en réponse à une demande de retransmission ou lors de l'ajout de données de correction d'erreur. Selon des caractéristiques particulières, le procédé objet de la présente invention comporte une étape de transmission des données du flux selon le protocole de transport en temps réel RTP (« Real-time Transport Protocol »). Selon un deuxième aspect, la présente invention concerne un dispositif de calcul de l'espace disponible dans un paquet pour le transport de flux de données, qui comporte : - un moyen de détermination des besoins de chaque module d'un 30 gestionnaire de flux de données, en espace du paquet pour au moins deux types de données d'entête et/ou d'extension requis par chaque protocole et/ou service utilisé par ledit module, - un moyen de détermination d'un besoin d'espace maximal dans le paquet pour répondre à l'ensemble de ces besoins, en mettant en oeuvre des règles de combinaison de besoins d'espace différentes pour les différents types de données et une somme des besoins combinés pour les différents types de données et - un moyen de calcul d'une différence entre l'espace du paquet et le besoin d'espace maximal dans le paquet pour déterminer l'espace disponible pour le transport du flux de données. Selon un troisième aspect, la présente invention vise un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé objet de la présente invention, tel que succinctement exposé ci-dessus. Selon un quatrième aspect, la présente invention vise un support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé objet de la présente invention, tel que succinctement exposé ci-dessus. Les avantages, buts et caractéristiques particulières de ce dispositif, de ce programme et de ce support d'informations étant similaires à ceux des procédés objets de la présente invention, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite dans un but explicatif et nullement limitatif en regard des dessins annexés, dans lesquels : - la figure 1 représente, schématiquement, un cas d'utilisation de la présente invention, - la figure 2 représente, sous forme d'un schéma-bloc, d'un mode de réalisation particulier d'un dispositif objet de la présente invention, - la figure 3 représente, schématiquement, le contenu d'une mémoire tampon pour la mise en oeuvre d'un mode de réalisation particulier du procédé objet de la présente invention, 30 - la figure 4 représente, schématiquement, le contenu d'une mémoire tampon avec une extension de données applicatives ajoutée par rapport au contenu présenté en figure 3, - la figure 5 représente, schématiquement, le contenu d'une mémoire tampon avec un autre contenu additionnel, par rapport au contenu présenté en figure 4, - la figure 6 représente, schématiquement, le contenu d'une mémoire tampon pour finaliser un paquet par ajout d'un entête RTP, - la figure 7 représente, schématiquement, un premier exemple de gestionnaire de flux de données et de chaînage de modules de traitements, - la figure 8 représente, schématiquement, un deuxième exemple de gestionnaire de flux de données et de chaînage de modules de traitements, - la figure 9 représente, sous forme d'un logigramme, des étapes mises en oeuvre dans un premier mode de réalisation particulier du procédé objet de la présente invention pour calculer la taille maximale de l'espace réservé pour un flux de données, - la figure 10 représente, sous forme d'un logigramme, des étapes mises en oeuvre pour calculer la taille maximale des données applicatives par une fabrique de mémoires tampons et - la figure 11 représente, schématiquement, un mode de réalisation particulier du dispositif objet de la présente invention.

Dans toute la description, on utilise les définitions suivantes : « Mémoire tampon » (en anglais «memory buffer») : une mémoire tampon, couramment désignée par le terme anglais « buffer », est une zone de mémoire vive ou de disque utilisée pour stocker temporairement des données, notamment entre deux processus ou matériels ne travaillant pas au même 30 rythme ; « Paquétisation » : action de regrouper en paquets le flot de bits à transporter. Un certain nombre d'informations de contrôle est ajouté, sous forme d'entête par exemple, pour indiquer à qui appartient le paquet et à qui il est destiné ; « RFC » (acronyme de « requests for comment ») : littéralement, c'est une demande de commentaires, plus généralement, une série numérotée de documents électroniques documentant les aspects techniques d'Internet. Peu de RFC sont des standards, mais tous les standards d'Internet sont des RFC. D'une manière schématique, à chaque événement (départ/arrivée d'un client ou à chaque activation/désactivation d'un service par un client), chacun des gestionnaires de flux de données concernés par l'événement détermine l'espace maximal dont il aura besoin dans un paquet réseau pour y placer les entêtes et les extensions requis par les protocoles et services utilisés. Pour cela chaque module constituant le gestionnaire de flux de données est interrogé et communique ses besoins en espace mémoire en les différentiant selon plusieurs types. Lors de la paquétisation des données applicatives, chaque module peut ainsi ajouter des informations d'extensions correspondant aux types suivants : - extension d'entête RTP persistante (PHE), - extension d'entête RTP dépendante du flux de données (SDHE), - extension de données applicatives persistante (PPE) et - extension de données applicatives dépendante du flux de données (SDPE). Si un module est lui-même à l'origine d'un sous-flux, il détermine de manière récursive les besoins en espace mémoire liés à ce sous-flux.

Les différents types de besoins en mémoire exprimés par chacun des modules constituant le gestionnaire de flux de données sont ensuite combinés et le besoin d'espace réservé maximal est déterminé pour le gestionnaire de flux de données dans son ensemble. Les opérations spécifiques de combinaison sont ici dépendantes du type des informations à combiner. Le gestionnaire de flux enregistre ensuite son besoin d'espace réservé auprès d'une « fabrique de mémoires tampons » (en anglais « buffer factory ») rattachée à la source de données applicatives. Cette fabrique maintient la liste des demandes de réservation d'espace mémoire de chacun des gestionnaires de flux qui lui sont rattachés et calcule ainsi le maximum des demandes de réservation d'espace mémoire. Quand l'encodeur ou le paquétiseur (en anglais « Packetizer ») demande, à la fabrique, un nouveau tampon mémoire pour y placer des nouvelles données applicatives, la fabrique leur retourne le tampon mémoire avec un pointeur sur l'emplacement à partir duquel les données applicatives peuvent être placées en tenant compte du maximum des espaces réservés en début de mémoire tampon pour l'ensemble des gestionnaires de flux de données rattachés à la source de données applicatives. Comme illustré en figure 1, dans un cas d'utilisation de la présente invention, un dispositif émetteur ou serveur 10 transmet des paquets 16 de données applicatives 14 d'un même flux de données multimédia 14 vers plusieurs dispositifs récepteur ou clients 11, 12 et 13 par l'intermédiaire d'un réseau de communication de données 15. Par exemple, le serveur 10 peut retransmettre les flux multimédia (vidéo et/ou audio) capturés par une caméra. Le réseau de communication 15 est, par exemple, un réseau sans fil (par exemple WiFi / 802.11 a/b/g/n), ou un réseau local Ethernet, ou longue distance tel que Internet. Les données applicatives 14 sont transmises à l'aide de protocoles adaptés à la transmission de données temps-réels tels que le protocole RTP (protocole de transport en temps réel ou « Real-time Transport Protocol »). Ce protocole est typiquement mis en oeuvre au dessus du protocole UDP/IP. De plus, le dispositif récepteur peut fournir des retours d'information (« feedback ») au dispositif émetteur, par exemple en utilisant le protocole de contrôle RTCP éventuellement étendu à l'aide du profil AVPF (acronyme de « Audio-Visual Profile with Feedbacks » décrit dans la RFC 4585 (« Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) », IETF, RFC 4585, Juillet 2006)). Chaque paquet réseau 16 contient à la fois les données applicatives 14 et des entêtes de protocoles ainsi qu'éventuellement des extensions à ces entêtes de protocoles et/ou des extensions aux données applicatives qui dépendent des services mis en oeuvre par chaque couple serveur-client. Par exemple, le client 13 utilise un service de retransmission (RTX) tel que décrit dans la RFC 4588 (« RTP Retransmission Payload Format », IETF, RFC 4588, Juillet 2006). Si un paquet réseau est perdu, les données applicatives peuvent être retransmises à la demande du client. Dans ce cas, selon la RFC, le paquet contenant les données applicatives retransmises comporte également, en plus des entêtes usuels, une petite extension aux données applicatives de deux octets contenant le numéro de séquence du paquet perdu correspondant.

Dans un autre exemple, le client 12 utilise des services de correction d'erreurs (ou « FEC », de l'anglais Forward Error Correction) tel que décrit dans la RFC 5109 (« RTP Payload Format for Generic Forward Error Correction », IETF, RFC 5109, Décembre 2007) ainsi qu'un service de contrôle de congestion (CC) tel que par exemple TFRC (« TCP Friendly Rate Control (TFRC): Protocol Specification », IETF, RFC 5348, Septembre 2008). Comme pour le service de retransmission, le service de correction d'erreurs (FEC) nécessite l'ajout d'informations additionnelles de redondances dans les paquets et le service de contrôle de congestion peut nécessiter l'ajout d'extensions aux entêtes RTP. Ainsi pour une même donnée applicative envoyée à chacun des clients, les paquets réseaux 16 peuvent contenir des entêtes et extensions de tailles variables. Nous nous plaçons dans la suite de la description dans le cas d'une transmission d'un flux vidéo encodé à la volée, mais le cas de la transmission d'un flux vidéo pré-encodé ou d'un flux audio pourrait être traité par l'homme du métier d'une manière tout à fait similaire (Dans le cas de données pré-encodées, l'encodeur 211 décrit en regard de la figure 2 peut être remplacé par un lecteur de données pré-encodées). En figure 2, le schéma-bloc décrit un serveur de flux multimédia 10. D'une manière générale, les données brutes (images, en anglais « frame ») à transmettre 20 sont traitées par un bloc source 21. Le bloc source 21 est chargé de les traiter pour obtenir des données applicatives qui seront placées dans une série de mémoires tampons 214. Chaque mémoire tampon 214 est ensuite séquentiellement traitée par l'intermédiaire d'un gestionnaire de flux de données 23, 24, 25 et 27 correspondant à un destinataire réseau identifié par une combinaison « adresse IP/numéro de port » différente (respectivement dénommées client1, client2 et client3). Il peut s'agir d'adresse IP unicast et/ou multicast. Chaque gestionnaire de flux de données est chargé de transformer la donnée applicative d'une mémoire tampon 214 en un paquet RTP valide par l'ajout d'informations additionnelles, d'entêtes et, éventuellement, d'informations d'extension de données applicatives afin que ce paquet puise être transmis à son destinataire par le réseau de communication 15. Avant de pouvoir être manipulée par un gestionnaire de flux de données, le contenu de la mémoire tampon 214 est associé en mémoire avec un objet décrivant un paquet RTP virtuel (par exemple 22, 22', 22" ou 28) chargé de décrire le contenu de la mémoire tampon 214 pour un gestionnaire de flux de données particulier.

Les paquets RTP virtuels 22, 22', 22" et 28 contiennent notamment des pointeurs sur la mémoire tampon 214 désignant l'emplacement des données applicatives et de certains entêtes et extensions aux données applicatives présents dans la mémoire tampon 214. Chaque gestionnaire de flux de données est constitué d'un ou plusieurs modules de traitement (par exemple 231, 241, 242, 243, 251, 252 et 271). Chaque module de traitement (en anglais « handler ») est susceptible de compléter le contenu de la mémoire tampon 214 en y ajoutant des entêtes de données additionnelles ou de conserver pour un usage ultérieur une référence sur le paquet RTP virtuel (22, 22', 22" ou 28) (et donc par extension sur la mémoire tampon 214 associée).

Parmi les modules de traitements, il existe un module de traitement particulier, le module RTP 231, 242, 251 et 271, qui est chargé de finaliser un paquet RTP en ajoutant l'entête de protocole RTP au contenu d'une mémoire tampon 214 et de transmettre ce paquet RTP, ainsi formé en mémoire, vers son destinataire par l'intermédiaire du réseau de communication 15.

D'une manière plus détaillée, le bloc source 21 est constitué d'un encodeur 211, un paquétiseur 212 adapté au format d'encodage et d'une « fabrique » de mémoires tampons 213. Les données 20 sont composées d'images qui proviennent, par exemple, d'un périphérique de capture tel qu'une caméra vidéo. Ces données sont fournies à la fréquence correspondante à la fréquence d'échantillonnage du périphérique de capture. Ces images sont encodées par l'encodeur 211 dans un format de compression vidéo, par exemple MPEG4 ou H.264/AVC. Le paquétiseur 212 segmente et/ou ré-organise les données ainsi encodées pour former des morceaux de données applicatives qui sont destinées à être transmises dans des paquets réseau. La paquétisation des données encodées peut être réalisée tel que décrit dans « RTP Payload Format for MPEG-4 Audio/Visual Streams », IETF, novembre 2000, pour le format MPEG4, ou « RTP Payload Format for H.264 Video », IETF, RFC 3984, février 2005, pour le format H.264. L'encodeur 211 et/ou le paquétiseur 212 interrogent la fabrique de mémoires tampons 213 pour connaitre la taille maximale disponible pour les données applicatives dans un paquet réseau. Avec la réponse, ils adaptent respectivement l'encodage et/ou la paquétisation pour obtenir une taille de donnée applicative la plus proche possible de la taille maximale. Par exemple, l'encodage peut être adapté en modifiant la taille des portions d'images (« slices ») ou le pas de quantification. La paquétisation peut être adaptée en fragmentant ou en combinant les portions d'images, si le mode de paquétisation le permet. Les données applicatives générées par le couple encodeur/paquétiseur sont placées dans une mémoire tampon 214. Cette mémoire tampon 214 est préalablement allouée par la fabrique de mémoires tampons 213 à la demande de l'encodeur 211 ou du paquétiseur 212.

La fabrique de mémoires tampons 213 maintient en permanence l'ensemble des demandes de réservation d'espace mémoire pour chacun des gestionnaire de flux de données rattachés à la source 21 (Par exemple 23, 24 et 25). La fabrique de mémoires tampons 213 détermine ainsi l'espace mémoire maximal qui doit être réservé en début de paquets réseau. Avec cette information, les données applicatives sont positionnées directement à la bonne place dans la mémoire tampon 214. L'espace laissé libre en début de mémoire tampon 214 (en trait discontinu sur la figure 2) permet à chaque module de traitement de rajouter, par la suite, les informations d'entêtes et d'extensions sans avoir à recopier ou déplacer les données applicatives en mémoire. On suppose que la même donnée applicative doit être envoyée aux clients 11, 12 et 13. Pour ce faire, la mémoire tampon 214 est traitée séquentiellement par chacun des gestionnaires de flux de données 23, 24 et 25. Pour chacun des gestionnaires de flux de données, un objet « paquet RTP » virtuel différent 22, 22' et 22" est créé. Ces objets contiennent notamment plusieurs pointeurs sur la mémoire tampon 214 permettant de désigner son contenu : - un pointeur sur le début de la mémoire tampon, - un pointeur sur l'emplacement des données applicatives et - un pointeur sur l'emplacement des extensions d'entête. Initialement, les deux derniers pointeurs de chaque paquet RTP 22, 22', 22" sont égaux et désignent l'emplacement des données applicatives dans 15 la mémoire tampon 214 telles que placées par la source 21. Chaque gestionnaire de flux de données 23, 24 et 25 est composé d'au moins un module de traitement. Ces modules sont chargés de traiter la mémoire tampon 214 et l'objet « paquet RTP » virtuel associé (22, 22' ou 22"). Chaque gestionnaire de flux de données 23, 24, 25 manipule consécutivement 20 la même mémoire tampon 214 (la zone en trait discontinu devant les données applicatives pouvant être ré-écrites par chacun des gestionnaires de flux). Ainsi les données applicatives ne sont pas recopiées ou déplacées en mémoire quand elles sont envoyées à plusieurs clients. Par exemple, le gestionnaire de flux de données 23 associé au client 25 11 est seulement composé d'un module RTP 231. Le module RTP se charge de placer les 12 octets de l'entête RTP devant les données applicatives dans la mémoire tampon 214 à l'aide des pointeurs du paquet RTP virtuel 22 et envoie le paquet ainsi formé en mémoire, sur le réseau de communication 15. Après l'envoi sur le réseau, le paquet RTP virtuel 22 peut être détruit. 30 Ensuite, les mêmes données applicatives de la mémoire tampon 214 sont envoyées au client 12 à l'aide du gestionnaire de flux de données 24. Le gestionnaire de flux de données 24 associé au client 12 est, par exemple, composé de trois modules : un module de contrôle de congestion 241, un module RTP 242 (similaire au module 231) et un module de correction d'erreurs basé sur la redondance de données 243 (ou « FEC », de l'anglais, « forward error correction »). Dans cet exemple, le module de contrôle de congestion 241 peut insérer dans la mémoire tampon 214 des informations additionnelles sous la forme d'extension aux entêtes RTP (par exemple pour pouvoir calculer la durée d'aller retour d'un paquet (ou « RTT », de l'anglais « round-trip time »). Ces informations sont placées devant les données applicatives et les pointeurs du paquet RTP virtuel 22' sont repositionnés en conséquence.

Le paquet RTP virtuel 22' et la mémoire tampon 214 sont ensuite traités par le module RTP 242 qui finalise le paquet RTP dans la mémoire tampon 214 et l'envoie sur le réseau de communication 15. Le paquet RTP virtuel 22' et la mémoire tampon 214 sont ensuite traités par le module FEC 243. Ce module FEC 243 doit mémoriser plusieurs paquets RTP avant de pouvoir calculer un nouveau paquet de redondance. Ce module FEC 243 conserve donc une référence sur le paquet RTP virtuel 22'. Il est à noter que seules les données applicatives de la mémoire tampon 214 pointées par le paquet virtuel 22' sont exploitables pour calculer un paquet de redondance. Les informations d'entêtes et d'extensions placées dans la mémoire tampon 214 par les modules 241 et 242 sont susceptibles d'être écrasées lors de l'envoi des mêmes données applicatives par d'autres gestionnaires de flux de données. Si nécessaire, le paquet virtuel 22' référencé par le module 243 conserve donc suffisamment d'informations pour régénérer les entêtes et extensions telles qu'ils étaient lors de l'envoi initial par le module 242.

Après traitement par le gestionnaire de flux de données 24, la mémoire tampon 214 est finalement traitée par le gestionnaire de flux de données 25 pour que son contenu soit transmis au client 13. Un nouveau paquet RTP virtuel 22" est alloué. Ce paquet RTP virtuel 22" référence la mémoire tampon 214. Le gestionnaire de flux de données 25 associé au client 13 est ici composé de deux modules : un module RTP 251 (similaire aux modules 231 et 242) et un module de correction d'erreurs basé sur des retransmissions (« RTX ») 252. Comme pour le module FEC 243, le module RTX 252 peut conserver une référence sur le paquet RTP 22". En particulier, il conserve une référence sur le paquet RTP 22" pendant une durée prédéterminée pour pouvoir le retransmettre sur le réseau sur demande du client.

Le module RTX 252 se comporte, à la fois, comme un module de traitement dans un gestionnaire de flux de données comme décrit précédemment, et comme une nouvelle source de paquets RTP 26 pour l'envoi des paquets retransmis. Le module de traitement RTX 252 et la source RTX 26 sont ainsi deux aspects d'un même module RTX. Quand le serveur 10 reçoit une demande de retransmission en provenance du client 13, cette demande de retransmission est transmise à la source RTX 26. La source RTX 26 recherche parmi les paquets stockés par le module RTX 252 le paquet RTP 22" et sa mémoire tampon 214 associée correspondant à la demande de retransmission. Si le paquet est trouvé, il alloue un nouveau paquet RTP virtuel 28 qui décrira le paquet retransmis. Ce nouveau paquet RTP virtuel 28 référence la même mémoire tampon 214 que le paquet RTP virtuel original 22". Ainsi les données applicatives ne sont pas recopiées ou déplacées lors de la réponse à une demande de retransmission. Seule la partie en trait discontinu correspondant aux entêtes et extensions sont ré-écrites lors de l'envoi du paquet par le gestionnaire de flux de données de retransmission 27. Ce gestionnaire de flux de données 27 associé à la source RTX 26 fonctionne de manière similaire aux autres gestionnaires de flux de données 23, 24, 25. Il est ici composé d'un module de traitement RTP 271 qui place les entêtes RTP devant les données applicatives et envoie le paquet réseau ainsi formé au client 13. On note que le module de traitement FEC 243 est, lui-même, une source de données similaire à celle décrite pour le module RTX 252 pour l'envoi des paquets de redondances FEC générés à partir des paquets RTP originaux 22'. Cette source de redondances FEC n'a pas été représentée en figure 2, pour des raisons de clarté (voir représentation de la source FEC en figures 7 et 8).

On note aussi que la ré-écriture de la zone d'entête dans une mémoire tampon 214 pour y placer les informations additionnelles et entêtes spécifiques à un client est possible du fait que chaque flux et sous-flux de données est traité séquentiellement.

La figure 3 décrit le contenu d'une mémoire tampon 214, telle qu'alloué par une fabrique de mémoires tampons pour l'envoi d'un nouveau paquet réseau. Une mémoire tampon mise en oeuvre pour implémenter la présente invention est préférentiellement un bloc de mémoire contigu constituée de plusieurs parties. En tête de la mémoire tampon se trouve un compteur de référence 31. Ce compteur 31 est incrémenté à chaque fois que la mémoire tampon est référencée par un autre objet, par exemple un paquet virtuel RTP, un module de traitement ou une source de donnée. Ce compteur 31 est décrémenté à chaque fois qu'un objet relâche la référence qu'il a sur la mémoire tampon. Quand le compteur de référence 31 atteint la valeur « 0 », c'est-à-dire qu'il n'est plus référencé par aucun objet du système, la mémoire tampon est dé-allouée. Après le compteur de référence 31, se situe un espace 32 réservé qui peut être utilisé par les différents modules de traitements pour ajouter des informations d'entêtes et/ou d'extensions aux données applicatives de manière à fabriquer un paquet de données pouvant être transporté sur le réseau. Le calcul de la taille maximale de cet espace réservé est décrit plus loin. Après cet espace réservé 32, se situe une zone 33 disponible pour y placer les données applicatives obtenue par le couple encodeur-paquétiseur.

La taille des données applicatives effectivement placées dans cette zone 33 peut être inférieure ou égale à la taille de cette zone 33. Quand une mémoire tampon est allouée par une fabrique de mémoires tampons, cette fabrique détermine la taille de l'espace réservé 32 comme étant le maximum des demandes de réservation faites par les différents gestionnaires de flux de données associés à la source. La place restante est allouée aux données applicatives et constitue la zone 33. La fabrique de mémoires tampons retourne, à l'encodeur/paquétiseur, la mémoire tampon allouée avec plusieurs pointeurs permettant de définir les différentes zones : - un pointeur sur la mémoire tampon désignant le début de l'espace réservé, - un pointeur sur les données applicatives désignant l'emplacement à partir duquel les données applicatives peuvent être placées et - un pointeur sur les extensions d'entête RTP placées initialement au même endroit que le pointeur sur les données applicatives. La taille totale d'une mémoire tampon correspond à la taille maximale (en octets) du paquet pouvant être transmis en une seule fois (sans fragmentation) sur le réseau (ou « MTU », de l'anglais « maximum transmission unit ») plus la taille du compteur de référence 31. La figure 4 décrit l'ajout d'une extension de données applicatives. Quand un module de traitement ou une source ajoute une extension de données applicatives 41 dans une mémoire tampon, on soustrait la taille des informations additionnelles au pointeur de données applicatives et on place ces informations additionnelles à l'emplacement désigné par ce pointeur. Ainsi une partie de l'espace réservé 32 est utilisé pour stocker l'extension de données applicatives. Le pointeur sur les extensions d'entête RTP est également mis à jour pour pointer au même endroit que le pointeur sur les données applicatives. Les modules de traitement doivent être chaînés dans un gestionnaire de flux de données de manière à ce que toutes les extensions de données applicatives soient insérées dans la mémoire tampon avant de pouvoir insérer l'entête RTP et les éventuelles extensions à l'entête RTP. Si un module de traitement doit insérer différents types d'information dans une mémoire tampon, par exemple une extension aux données applicatives et une extension à l'entête RTP, le module de traitement peut être présent à différent endroit dans la chaîne de traitement. Un exemple d'extension aux données applicatives est l'entête de retransmission « OSN » (de l'anglais « original sequence number ») qui doit être placé par une source RTX devant les données applicatives originales quand un paquet doit être retransmis, tel que décrit dans la RFC 4588 section 4 (« RTP Retransmission Payload Format », IETF, RFC 4588, juillet 2006). Un autre exemple est l'entête FEC et l'entête de niveau FEC tels que décrits dans la RFC 5109 section 7 (« RTP Payload Format for Generic Forward Error Correction », IETF, RFC 5109, décembre 2007).

On note qu'on distingue deux types d'extension, les extensions aux données applicatives et l'extension à l'entête RTP. Le premier est décrit en regard de la figure 4 alors que le second est décrit en regard des figures 5 et 6. L'ajout des extensions à l'entête RTP se fait en deux phases : une première phase, illustrée en figure 5, consiste à placer les extensions à l'entête RTP eux- mêmes et une deuxième phase, illustrée en figure 6, consiste à ajouter un entête spécifique décrivant les extensions à l'entête RTP ajoutés et éventuellement un padding. La figure 5 représente un ajout d'un élément d'extension d'entête RTP par un module de traitement. Chaque module est susceptible d'ajouter des informations additionnelles au niveau de l'entête RTP. Par exemple, l'utilisation de certains services proposés par le serveur 10 peut nécessiter l'envoi d'informations additionnelles avec chaque paquet réseau. C'est, par exemple, le cas avec le service de contrôle de congestion TFRC tel que décrit dans le document (« RTP with TCP Friendly Rate Control », IETF, draft-ietf-avt-tfrc- profile-10, juillet 2007). Dans ce cas, ces informations peuvent être ajoutées dans une extension à l'entête RTP tel que définit par la section 5.3.1 de la RFC 3550 (« RTP: A Transport Protocol for Real-Time Applications », IETF, RFC3550, juillet 2003). Afin de pouvoir placer plusieurs extensions dans l'entête RTP, les différentes extensions d'entête RTP (qu'on nomme « éléments d'extension d'entête RTP ») sont organisés conformément à la RFC 5285 (« A General Mechanism for RTP header Extensions », IETF, RFC 5285, juillet 2008) qui définit comment plusieurs éléments d'extension d'entête RTP sont associés dans un paquet pour former une extension d'entête RTP au sens de la RFC 3550.

Les figures 5 et 6 décrivent l'ajout d'éléments d'extension d'entête RTP. L'extension d'entête RTP, illustrée en figure 6, se compose d'un entête d'extension (composé des champs ID 61 et L 62) suivi d'une série d'éléments d'extension RTP 64, avec éventuellement quelques octets de remplissage P 63 (en anglais « Padding bytes ») pour garantir l'alignement des données en mémoire. Dans des modes de réalisation, chaque module de traitement peut ajouter des données additionnelles à l'entête RTP. Pour cela, comme illustré en figure 5, ce module de traitement soustrait au pointeur sur les extensions d'entête RTP la taille de l'élément à ajouter et place le nouvel élément à l'adresse ainsi obtenue. Conformément à la RFC 5285, l'élément est composé d'un identifiant local 51, d'une indication de longueur 52 et des données additionnelles 53.

Tous les éléments d'extension d'entête RTP sont insérés dans la mémoire tampon après les extensions de données applicatives et avant le traitement par le module RTP qui finalise le paquet RTP pour transmission sur le réseau. La figure 6 décrit un paquet réseau tel qu'il est finalisé par le module 15 de traitement RTP. Si des éléments d'extensions à l'entête RTP ont été ajouté précédemment (c'est-à-dire si la différence entre le pointeur sur les données applicatives et le pointeur sur les extensions d'entêtes RTP est non nulle), le module de traitement RTP finalise le paquet RTP en déterminant d'abord que la 20 somme des éléments des extensions d'entêtes est un multiple de 32 (Il s'agit d'une contrainte de la paquétisation RTP telle que décrit dans la RFC 3550 section 5.3.1). Si ce n'est pas le cas, le module de traitement RTP ajoute des octets de remplissage 63 devant les éléments d'extension d'entête RTP 64. Le module de traitement RTP ajoute ensuite l'entête des extensions RTP composé 25 d'une indication de longueur 62 des éléments d'extensions RTP et d'un identifiant 61, par exemple « OxBEDE », dans le cas d'éléments d'extension à l'entête RTP de taille un octet, conformément à la RFC 5285. Le module de traitement RTP finalise ensuite le paquet en ajoutant l'entête RTP 65. En l'absence d'éléments d'extensions à l'entête RTP 64, c'est-à-dire 30 si les pointeurs sur les extensions d'entête RTP et sur les données applicatives sont égaux, alors le module de traitement RTP ajoute un entête RTP 65 devant le pointeur sur les données applicatives.

Le paquet ainsi formé est transmis sur le réseau 15. La figure 7 donne un premier exemple de gestionnaire de flux de données et de chaînage de modules de traitements. La figure 7 représente plusieurs flux de données 71, 72 et 73 destinés à un même client destinataire et introduit la notion de « persistance » ou de « dépendances à un flux » des données additionnelles et d'héritage entre flux de données. On observe que les flux de données 71, 72 et 73 sont de type « dépendants » car le module de traitement FEC 714 qui traite le flux de données 71 est, lui-même, une source FEC 721 pour le flux de données 72. Le module de retransmission RTX 724 qui gère le flux de données 72 est lui-même une source RTX 731 pour le flux de données 73. Suivant ce schéma, les paquets réseaux issus du flux de données 71 sont ainsi protégés des pertes de paquets sur le réseau par des paquets FEC issus du flux de données 72 qui sont, eux-mêmes, protégés par des paquets de retransmission issus du flux de données 73. Pour marquer la dépendance entre les flux, on dit que le flux de données 72 est un « sous-flux » de données du flux de données 71. De même, le flux de données 73 est un sous-flux de données du flux de données 72. D'une manière générale, quand un module de traitement est, lui-même, une source pour un autre flux de données, on dit qu'il s'agit d'un sous- flux de données par rapport au flux de données auquel est rattaché ce module de traitement. Le module de traitement hérite alors des contraintes d'espace réservé du sous-flux de données associé. On note que, suivant ce schéma, chacun des gestionnaires de flux de données utilise un service de contrôle de congestion, respectivement 712, 722 et 732. De même, chaque gestionnaire de flux de données comporte un module RTP, respectivement 713, 723 et 733. On détermine, dans un tel schéma, quelle doit être la taille maximale des données applicatives générées par la source 711 du flux de données 71, pour que chaque flux et sous-flux de données 71, 72 et 73 puisse transmettre ses paquets réseaux sans avoir à copier ou déplacer les données applicatives une fois qu'elles ont été générées par la source 711 et placées dans une mémoire tampon et sans fragmentation des paquets (chaque paquet étant égal, au maximum, à un MTU). Pour cela, chaque module de traitement détermine ses besoins maximum en espace réservé suivant différents types de réservation : suivant le type des informations additionnelles, extension aux données applicatives ou extension à l'entête RTP, et selon que l'ajout d'informations additionnelles a un caractère persistant ou non entre des flux dépendants (c'est-à-dire entre un flux de données et un sous-flux de données). De plus, il s'agit de distinguer si les informations additionnelles ajoutées au niveau d'un flux de données par un module de traitement doivent être répétées dans les sous-flux de données ou si les informations additionnelles ne s'appliquent qu'au flux de données auquel le module de traitement est rattaché. Par exemple, en référence à la figure 7, si le module de contrôle de congestion 712 est de type TFRC, il doit ajouter des informations additionnelles, par exemple, date à laquelle le paquet a été envoyé ou estimation de la durée d'aller-retour d'un paquet (RTT), dans une extension à l'entête RTP. Ces informations sont propres à un flux de données. Il n'est donc pas nécessaire de les répéter dans un sous-flux de correction. Elles sont donc dites de type « dépendant du flux de données ». Au contraire, le flux de données 72 protége les paquets réseaux produit par le flux de données 71 en créant et en envoyant des paquets FEC à partir des paquets originaux du flux de données 71. Pour cela, les paquets FEC sont produits par le module de traitement 714/source 721 FEC en ajoutant, entre autres, un entête FEC aux données applicatives ou équivalentes. Par ailleurs, le flux de données FEC 72 est lui-même protégé par un flux de données de retransmission 73. Pour cela les paquets de retransmission sont produits par la source RTX 731 à partir des paquets de FEC sauvegardés par le module de traitement RTX 724. C'est-à-dire que les paquets retransmis intègrent, à la fois, l'équivalent des données applicatives et l'entête FEC des données applicatives. L'entête FEC est alors de type « persistant ».

On remarque que les entêtes ajoutés par la source FEC 721 et la source RTX 731 présentent ici un caractère additif : un paquet retransmis par le flux 73 intègre, à la fois, l'équivalent des données applicatives originales du flux de données 71, l'entête FEC des données applicatives du flux de données 72, l'entête RTX des données applicatives du flux de données 73 et une extension à l'entête RTP pour le service de contrôle de congestion. On distingue ainsi les différents types de réservation suivants : - les extensions d'entête RTP persistantes (ou « PHE », de l'anglais « Persistent Header Extension »), - les extensions d'entête RTP dépendantes du flux de données (ou « SDHE », de l'anglais « Stream-Dependent Header Extension »), - les extensions de données applicatives persistantes (ou « PPE », de l'anglais « Persistent Payload Extension »), - les extensions de données applicatives dépendantes du flux de données (ou « SDPE », de l'anglais « Stream-Dependent Payload Extension »). La figure 8 montre un deuxième exemple de flux de données et de chaînage de modules de traitements. Ici, les flux de données 81, 82 et 83 sont à destination d'un même client destinataire. Suivant ce schéma, les paquets réseaux issus du flux de données 81 peuvent être protégés à la fois par des paquets FEC issus du sous-flux de données 82 et par des paquets de retransmission RTX issus du sous-flux de données 83. De plus, chacun des flux 81 et sous-flux 82 et 83 de données utilise un service de contrôle de congestion, respectivement 812, 822 et 832. Le gestionnaire du flux de données 81 reçoit des données d'une source 811 et comporte le module de contrôle de congestion 812, un module RTP 813, un module FEC 814 et un module de retransmission 815. Le gestionnaire du flux de données 82 comporte le module de contrôle de congestion 822 et un module RTP 823. Le gestionnaire du flux de données 83 comporte le module de contrôle de congestion 832 et un module RTP 833.

Contrairement au cas illustré en figure 7, les entêtes des données applicatives ajoutés par la source FEC 821 ou la source RTX 831 ne présentent pas ici de caractère additif.

La figure 9 montre un organigramme d'étapes pour calculer la taille maximale de l'espace réservé dans une mémoire tampon par un gestionnaire de flux de données pour transporter un flux de données comportant éventuellement au moins un sous-flux.

La demande de réservation d'un gestionnaire de flux de données est ré-estimée à chaque événement parmi les suivants : - un client se connecte au système, - un client se déconnecte du système, - un client active un service ou - un client désactive un service. Pour déterminer la taille de l'espace réservé requis par un gestionnaire de flux de données, on doit déterminer, pour chaque module de traitement, ses besoins en réservation suivant les types PHE, SDHE, PPE, et SDPE, en commençant par un premier module, au cours d'une étape 91. Cette détermination de besoin de réservation est détaillée plus bas. Au cours d'une étape 92, on détermine si le module de traitement est lui-même une source de données pour au moins un sous-flux. Si oui, au cours d'une étape 93, le module de traitement détermine les besoins en réservation de chaque sous-flux, également suivant les types PHE, SDHE, PPE, SDPE.

Ces besoins de réservation sont dits « hérités ». Sinon, ou après l'étape 93, au cours d'une étape 94, le gestionnaire de flux de données détermine si le besoin de réservation du dernier module de traitement du gestionnaire de flux de données a été déterminé. Sinon, on retourne à l'étape 91 pour traiter un nouveau module de traitement du gestionnaire de flux de données. Si le dernier module a été traité, au cours d'une étape 95, le gestionnaire de flux de données (noté « S ») détermine ses besoins de réservation (noté « R ») en prenant en compte les modules de traitements qui le composent (notés M;) et les sous-flux dont il hérite (notés « Si ») suivant les formules suivantes : modules de traitements Sous-flux RPHE(S) _ L RPHE(M) +max(RPHE(s,)) (1) ( modules de traitements Sous -flux RSDHE(S) =max L RSDHE (Mi),max(RSDHE (Sj)) Z j modules de traitements Sous -flux R PPE (S) _ L R PPE (M ) + max (R PPE (S,)) et z j ( modules de traitements Sous -flux R SDPE (S) = max L R sDPE (M ) , max (R SDPE (S j )) Ces équations peuvent être exprimées sous la forme d'opérations qui dépendent du type d'informations d'extensions. L'espace réservé « RE(S) » requis pour stocker un type donné d'information d'extension E pour un gestionnaire de flux de données S peut être exprimé en fonction de l'espace réservé par les modules Mi qui le composent (noté RE(M;)) et de l'espace réservé par les sous-flux Si dont il hérite (noté RE(Si)) sous la forme : ( modules de traitements sous-flux RE(s)=oE L RE(Mi),max(RE(S1)) M; S; On exprime ainsi les équations (1) à (4) données plus haut sous la forme d'une seule équation RE(S), où « E » désigne le type d'information d'extension c'est-à-dire l'un des types PHE, SDHE, PPE ou SDPE, et OE désigne une opération dépendant du type E, avec :

- 0SDHE et 0SDPE correspondant à l'opération « max » qui extrait la valeur maximum d'un couple de valeurs et

- OPHE et OPPE correspondant à l'opération « + » qui additionne les valeurs du couple de valeurs.

RE(M;) représente l'espace réservé pour un type de réservation E par l'un des modules de traitement noté Mi du gestionnaire de flux de données S. RE(Si) représente l'espace réservé pour un type de réservation E par l'un des sous-flux de données noté Si du gestionnaire de flux de données S. Une fois déterminés les besoins en réservation des différents types pour un flux de données, on détermine au cours d'une étape 96, la taille de (2) (3) (4) (5)

l'espace réservé total « ER » pour ce flux de données S à l'aide de l'équation suivante : ER(S) = align32(RPHE(S)+RSDHE(S)+HDR)+RPPE(S)+RSDPE(S) équation dans laquelle « HDR » est la taille de l'entête des extensions d'entête RTP tel que défini dans la RFC 5285 et à la figure 6, l'entête RTP 65 et « align32 (x) », l'alignement de la valeur x sur le multiple de 32 bits supérieur, soit quatre octets en pratique, car la valeur x est exprimé en octets. Le gestionnaire de flux de données peut ensuite enregistrer son besoin en espace réservé ainsi calculé auprès de la fabrique de mémoires tampons de la source à laquelle il est rattaché, au cours d'une étape 97. On note que le gestionnaire de flux de données peut dé-enregistrer le flux de données de la fabrique de mémoires tampons en envoyant une demande de réservation égale à « 0 ».

La figure 10 représente un organigramme d'étapes pour le calcul de la taille maximale des données applicatives effectué par la fabrique de mémoires tampons. La figure 10 détaille ainsi les étapes effectuées par la fabrique de mémoires tampons à la réception d'une demande de réservation en provenance d'un gestionnaire de flux de données, au cours d'une étape 101.

Au cours d'une étape 102, on détermine si la demande de réservation est égale à«0». Si oui, au cours d'une étape 103, on ajoute le flux de données et sa demande de réservation dans la liste des demandes de réservation. Sinon, on retire le flux de données de la liste des demandes de réservations, au cours d'une étape 104. A la suite de l'une des étapes 103 ou 104, la fabrique de mémoires dispose de l'ensemble des réservations de chacun des gestionnaires de flux de données qui lui sont rattachées. La fabrique de mémoires tampons détermine, au cours d'une étape 105 la taille maximale des données applicatives qui pourront être envoyées par l'ensemble des gestionnaires de flux de données, en soustrayant la valeur maximum des demandes de réservation à la taille maximale (en octets) du paquet pouvant être transmis en une seule fois (sans fragmentation) sur le réseau, MTU. Le mode de réalisation du dispositif objet de la présente invention illustré en figure 11 est basé, par exemple, sur un appareil 120, par exemple un micro-ordinateur, une station de travail, un assistant personnel, un téléphone mobile, une caméra réseau, un appareil photo, une télévision, un caméscope ou, plus généralement, tout périphérique (mobile ou non) muni d'une interface de communication permettant de se connecter à un réseau avec ou sans-fil 110. Cet appareil 120 peut être connecté à différents périphériques tels que, par exemple, une caméra numérique 121 (ou un scanner, ou tout autre moyen d'acquisition ou de stockage d'images) reliée à une carte d'entrée/sortie (non représentée) et fournissant à l'appareil 120 des données multimédia. L'appareil 120 comporte un bus de communication 131 auquel sont reliés : - une unité centrale de traitement 132 (microprocesseur) (notée « CPU » en figure 2), - une mémoire morte 133, amovible ou non, conservant des programmes exécutables dont les instructions sont lisibles par un processeur ou un ordinateur et permettent l'implémentation du procédé objet de la présente invention, - une mémoire vive 134, qui, après la mise sous tension, contient le code exécutable implémentant le procédé objet de la présente invention ainsi que des registres adaptés à enregistrer des valeurs de variables et paramètres nécessaires à la mise en oeuvre de ce procédé, - une interface de communication 135 connectée au réseau de communication 110, l'interface 135 étant apte à transmettre et à recevoir des données. Optionnellement, l'appareil 120 dispose également : - dans le cas de données audio, d'une carte d'entrée/sortie (non représentée) reliée à un microphone 124, - un écran 125 pour visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui peut interagir avec les programmes, à l'aide d'un clavier 126 complété ou non par tout autre moyen tel qu'un dispositif de pointage, par exemple une souris, un crayon optique ou encore un écran tactile (non représentés), - d'un disque dur ou d'une mémoire de stockage, telle qu'une carte 5 compact flash, 136 pouvant conserver les programmes et les données utilisées ou produites lors de la mise en oeuvre de ces programmes, - d'un lecteur de disquette (ou tout autre support de données amovible) 137 adapté à recevoir une disquette 122 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. 10 Un bus de communication 131 permet la communication et l'interopérabilité entre les différents éléments inclus dans l'appareil 120 ou relié à lui. La représentation du bus 131 n'est pas limitative et, notamment, l'unité centrale 132 est susceptible de communiquer des instructions à tout élément de l'appareil 120 directement ou par l'intermédiaire d'un autre élément de l'appareil 15 120. Les disquettes 122 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un 20 microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution des instructions permet la mise en oeuvre du procédé objet de la présente invention. Le code exécutable permettant la mise en oeuvre du procédé objet de la présente invention par l'appareil 120 peut se trouver indifféremment 25 stocké en mémoire morte 133, sur le disque dur 136 ou sur un support numérique amovible tel que par exemple une disquette 122. Selon une variante, le code exécutable des programmes est reçu par l'intermédiaire du réseau de communication 110, par l'intermédiaire de l'interface 135, pour être stocké dans un des moyens de stockage de l'appareil 120 avant d'être exécuté. 30 L'unité centrale 132 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile,

par exemple le disque dur 136 ou la mémoire morte 133, sont transférés dans la mémoire vive 134 (RAM) qui contiendra alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention.

On note que l'appareil 120 comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil 120 contient alors le code du ou des programmes informatiques, par exemple figé dans un circuit intégré à application spécifique (ou « ASIC », de l'anglais « application specific integrated circuit »).

On comprend, à la lecture de ce qui précède que l'invention permet de gérer différents types d'informations additionnelles venant s'ajouter aux données applicatives lors de la génération d'un paquet réseau, par exemple, les entêtes de données applicatives (« payload header ») de type persistants ou dépendantes d'un flux de données, les extensions à l'entête de base RTP de type persistantes ou purement dépendantes d'un flux de données et les entêtes de taille fixe (par exemple, les entêtes de base RTP). De plus, la taille disponible des données applicatives dans un paquet réseau est toujours optimale. Elle est ré-estimée à chaque fois qu'un client se connecte ou se déconnecte au système et à chaque activation ou désactivation d'un service par l'un des clients. Enfin, les données applicatives ne sont jamais dupliquées/copiées, même si elles sont envoyées à plusieurs destinataires (cas du multi-unicast) ou si elles doivent être retransmises plusieurs fois au même client. Le système consomme ainsi moins de ressource mémoire et de ressource processeur.25

Claims (14)

1. REVENDICATIONS1. Procédé de calcul de l'espace disponible dans un paquet pour le transport de flux de données, qui comporte : - une étape de détermination des besoins de chaque module d'un gestionnaire de flux de données, en espace du paquet pour au moins deux types de données d'entête et/ou d'extension requis par chaque protocole et/ou service utilisé par ledit module, - une étape de détermination d'un besoin d'espace maximal dans le paquet pour répondre à l'ensemble de ces besoins, en mettant en oeuvre des règles de combinaison de besoins d'espace différentes pour les différents types de données et une somme des besoins combinés pour les différents types de données et - une étape de calcul d'une différence entre l'espace du paquet et le besoin d'espace maximal dans le paquet pour déterminer l'espace disponible pour le transport du flux de données.
2. 2. Procédé selon la revendication 1, qui comporte, en outre : - une étape de détection d'un événement parmi les suivants : o arrivée d'un client destinataire du flux de données dans un réseau de transmission dudit flux de données, o départ d'un client destinataire du flux de données du réseau, o activation d'au moins un module du gestionnaire de flux de données et o désactivation d'au moins un module du gestionnaire du flux de données ; et - une étape de détermination du gestionnaire de flux de données concerné par ledit événement, ledit gestionnaire de flux de données effectuant les étapes de détermination de besoins et de calcul. 30
3. 3. Procédé selon l'une quelconque des revendications 1 ou 2, dans lequel, au cours de l'étape de détermination des besoins de chaque module en espace du paquet pour au moins deux types de données, les types comportent au moins un type d'extension persistante et au moins un type d'extension dépendante du flux de données.
4. 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel, au cours de l'étape de détermination des besoins de chaque module en espace du paquet pour au moins deux types de données, les types comportent : - au moins l'un des types suivants : o extension d'entête RTP persistante (PHE) et o extension de données applicatives persistante (PPE), et - au moins l'un des types suivants : o extension d'entête RTP dépendante du flux de données 15 (SDHE) et o extension de données applicatives dépendante du flux de données (SDPE).
5. 5. Procédé selon l'une quelconque des revendications 3 ou 4, dans lequel, au cours de l'étape de détermination d'un besoin d'espace maximal 20 dans le paquet pour répondre à l'ensemble de ces besoins, on met en oeuvre : - pour la combinaison de besoins d'espace de type d'extension persistante, une opération d'addition de besoins et, - pour la combinaison de besoins d'espace de type d'extensions dépendante du flux de données, une opération d'extraction de 25 valeur maximum de besoins.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel, au cours de l'étape de détermination des besoins de chaque module, si ledit module est une source d'un sous-flux du flux de données, on détermine le besoin en espace du paquet pour au moins deux types de données du sous- 30 flux.
7. 7. Procédé selon la revendication 6, dans lequel, au cours de l'étape de détermination d'un besoin d'espace maximal dans le paquet pour répondre àl'ensemble des besoins, on met en oeuvre, pour l'ensemble des sous-flux dudit flux de données, une opération d'extraction de la valeur maximale des besoins des sous-flux pour chaque type de données.
8. 8. Procédé selon l'une quelconque des revendications 6 ou 7, dans lequel, au cours de l'étape de détermination d'un besoin d'espace maximal dans le paquet pour répondre à l'ensemble des besoins R, on met en oeuvre, pour l'ensemble des modules Mi qui composent le gestionnaire de flux S et les sous-flux Sj dont le gestionnaire de flux hérite, les équations suivantes : - pour les extensions d'entête persistantes PHE : modules de traitements Sous -flux RPHE(S)= L RPHE(Mi )+max(RPHE(Sj)) Z j - pour les extensions d'entête dépendantes du flux de données SDHE : ( modules de traitements Sous -flux RSDHE(S) =max L RSDHE (Mi),max(RSDxE(Sj)) Z j - pour les extensions de données applicatives persistantes PPE : modules de traitements Sous -flux RPPE (S) _ L RPPE (M )+max(RPPE (Sj)) et J Z j - pour les extensions de données applicatives dépendantes du flux de données SDPE : ( modules de traitements Sous flux R SDPE (S) = max L R SDPE (M ),maxSDPE (Si) puis, pour calculer le besoin total RE (S), ( modules de traitements sous-flux 20 RE(S)=OE L RE(M1),max(RE(S1)) M, s, équation dans laquelle « E » désigne le type d'information d'extension c'est-à-dire l'un des types PHE, SDHE, PPE ou SDPE, et OE désigne une opération dépendant du type E, avec : 15 0SDHE et 0SDPE correspondant à l'opération « max » qui extrait la valeur maximum d'un couple de valeurs et - OPHE et OPPE correspondant à l'opération « + » qui additionne les valeurs du couple de valeurs.
9. 9. Procédé selon l'une quelconque des revendications 1 à 8, qui comporte, en outre, une étape de réservation d'espace de paquet auprès d'une fabrique de mémoires tampons rattachée à la source du flux considéré, en indiquant le résultat de l'étape de calcul de différence, et une étape de calcul, par la fabrique, du maximum des demandes de réservation d'espace pour, lors d'une demande d'un nouveau tampon de mémoire pour y placer des nouvelles données du flux, retourner un tampon de mémoire avec un pointeur sur l'emplacement à partir duquel les données du flux peuvent être placées en fonction du maximum des demandes de réservation d'espace en début de mémoire tampon.
10. 10. Procédé selon la revendication 9, qui comporte, pour chaque donnée du flux de données : - une étape d'écriture unique de ladite donnée dans la mémoire tampon, après ledit pointeur et, - pour chaque transmission de ladite donnée à un destinataire, une étape d'écriture de données d'entête et/ou d'extension pour chaque module de gestionnaire de flux de données associé à ladite transmission.
11. 11. Procédé selon l'une quelconque des revendications 1 à 10, qui comporte une étape de transmission des données du flux selon le protocole de 25 transport en temps réel RTP (« Real-time Transport Protocol »).
12. 12. Dispositif de calcul de l'espace disponible dans un paquet pour le transport de flux de données, qui comporte : - un moyen de détermination des besoins de chaque module d'un gestionnaire de flux de données, en espace du paquet pour au 30 moins deux types de données d'entête et/ou d'extension requis par chaque protocole et/ou service utilisé par ledit module, - un moyen de détermination d'un besoin d'espace maximal dans le paquet pour répondre à l'ensemble de ces besoins, en mettant en oeuvre des règles de combinaison de besoins d'espace différentes pour les différents types de données et une somme des besoins combinés pour les différents types de données et - un moyen de calcul d'une différence entre l'espace du paquet et le besoin d'espace maximal dans le paquet pour déterminer l'espace disponible pour le transport du flux de données.
13. 13. Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 11.
14. 14. Support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 11.