FR 2821454 A1 20020830 FR 0117087 A 20011231 préenregistrée. La présente invention concerne un procédé de gestion de données enregistrées dans une file d'une mémoire. Lorsque l'on inscrit des données d'une file d'attente dans un dispositif de destination, en particulier dans un dispositif à distance, il est s habituel d'inscrire les données dans une mémoire distincte de la mémoire qui contient la file jusqu'à la réception de la confirmation que les données ont été correctement reçues par le destinataire dans le système de gestion de file. Cela permet de libérer la mémoire contenant la file et permettre d'y inscrire les données reçues d'une source de données. o La présente invention concerne un procédé d'enregistrement d'un paquet de données dans une mémoire divisée en plusieurs blocs de mémoire, procédé caractérisé en ce qu'il comprend les étapes suivantes: - l'enlèvement de l'entête du paquet de données, s - la division du restant des données du paquet en des fragments de pa quet, - l'enregistrement de chaque fragment de paquet dans un bloc mémoire respectif avec une entête respective et on met un drapeau " début de paquet " dans l'entête du bloc mémoire contenant le fragment de paquet correspondant au début du restant du paquet de données. L'invention permet de stocker des données non confirmées sans prévoir de surfaces séparées de mémoire. De manière préférentielle selon le procédé, en l'absence de réception d'une confirmation ou d'une confirmation négative, indiquant que le transfert des données a été réussi, on met à jour l'emplacement du dernier pointeur lu pour prendre la place du pointeur lu, attribué. Suivant une autre caractéristique avantageuse, on enregis tre la dernière position du pointeur de lecture et la position du pointeur de so lecture attribué et on utilise le dernier pointeur de lecture et le pointeur de lecture attribué pour gérer la lecture suivante des données d'une seconde file. Suivant une autre caractéristique avantageuse, - on lit les secondes données de la tête de la file d'attente, s - on met à jour la position du second dernier pointeur lu à la position correspondant à la fin des secondes données, - on transfert les secondes données vers la destination et, - à la réception de la confirmation de la réussite du transfert des secon- des données, on enlève le second pointeur lu de l'emplacement corres- pondant à la fin des secondes données. Suivant une autre caractéristique du procédé, s - on inscrit les données à la queue de la file d'attente, - on met à jour la position du dernier pointeur d'inscription à l' emplacement corresp ondant à la fin des données et - à la réception de la confirmation que les données reçues sont correctes, on met à j our l'emplacement du pointeur d'écriture, attribué à o l'emplacement correspondant à la fin des données. La présente invention sera décrite ci-après à l'aide de modes de réalisation représentés à titre d'exemple dans le dessin annexé dans lequel: - l'unique figure montre un système gestionnaire de files d'attente pour s quatre utilisateurs de file d'attente. L'unique figure montre un système gestionnaire de files d'attente 10 reliée à quatre utilisateurs de files d'attente 11-14 (ler...4ème utilisateur) avec respectivement quatre interfaces 15-18. Le système ges- tionnaire de files d'attente 10 comporte un gestionnaire central cablé de o files d'attente 19. Ce gestionnaire central est commandé par programme par l'intermédiaire d'une interface de programme 20. Le gestionnaire cen- tral de files d'attente 19, est relié à chacune des interfaces de files d'attente 15-18 par l'un des quatre portails 21-24 et par un bus commun (non représenté). s L'interface de programme 20 est responsable de la création et de la destruction des files d'attente, du re-dimensionnement des fles d'attente et de l'envoi des blocs de mémoire dans les files d'attente. La tâ che principale du gestionnaire central de files d'attente 19 est de ré attribuer les " blocs utilisés " vers la partie arrière des files d'attente. Le gestionnaire central de files d'attente 19 comporte un arbitre de bus (non représenté) qui détermine comment et quand les fonctions de circuits pa- rallèles et de programmes peuvent accéder au bus (non représenté). Les portails de files d'attente 21-24 assurent l'accès aux fi- les d'attente. Chaque portail de files d'attente 21-24 se compose de deux 3s parties. Une partie peut servir à inscrire dans la file d'attente et l'autre partie peut servir à lire dans une file d'attente (chaque partie ac- cède à différentes files d'attente). Bien que l'on ait représenté quatre por tails de files d'attente 21-24, il n'y a pas de limite au nombre de portails que l'on peut utiliser. La contrainte principale du nombre de portails est celle du bus le plus mauvais pour la largeur de bandes. Chaque utilisateur de files d'attente 11-14 demande un portail de files d'attente 21-24. L'utilisateur de files d'attente 11-14 peut accéder à de multiples files d'attente et en même temps, il peut lire dans une file d'attente pendant qu'il écrit dans une autre file d'attente. Dans ce cas, les tâches sont simultanées mais les accès au bus se font séquentiel lement sous la commande de l'artitre de bus. Toutefois, chaque fois qu'un o utilisateur de files d'attente 11-14 veut lire ou inscrire dans une file diffé rente, il doit l'indiquer au portail de files d'attente 21-24 pour décharger les pointeurs courants de files d'attente et charger de nouveaux pointeurs. Chaque utilisateur de files d'attente 11-14 est un composant, une fonction normalisée avec une possibilité d'accès direct à la mémoire (DMA) . C'est pourquoi cet utilisateur de files 11-14 demande à son interface d'utilisateur de files d'attente 15-18 de traduire sa requete DMA et les si gnaux d'accusé de réception en enJeu normal de signaux reconnus par les portails de files d'attente 21-24. Dans certaines applications, il s'agit d'une simple traduction de signal alors que dans d'autres applications, o l'interface 15-18 ajoute ou supprime des données pour les traduire d'une application à une application avec un format de paquet de données spéci fique. Le bloc de construction de base des files asynchrones est un bloc de mémoire vive (RAM). Cette mémoire n'est pas représentée. La quantité de mémoire RAM disponible pour le système de gestion de files d'attentelO est divisée en des lots de petits blocs de mémoire de méme dimension pour éviter de surcharger le stockage de la taille de bloc de chaque bloc de mémoire. En variante, on peut utiliser différentes files d'attente avec différentes tailles de bloc de mémoire bien que cela compli querait le programme qui crée et redimensionne les files d'attente. Dans ce mode de réalisation, les blocs de mémoire ont une longueur de 64 octets. Chaque bloc de mémoire commence par une liaison de champ qui est un pointeur dirigé sur l'adresse de la liaison champ du bloc de mémoire sui vant. La mémoire utilisée par la file se compose d'un nombre de blocs de 3s mémoire que l'on peut répartir n'importe o dans la mémoire vive RAM et ces blocs sont liés par des champs de liaison. Le système de gestion de files d'attente 10 utilise seulement des champs de liaison unidirectionnels de sorte que le système de gestion de files QMS peut seulement chercher en avant à travers les blocs. Si le bloc courant est le dernier maillon de la chame, son champ de maillons ou de liaison contient des états (1=1). En variante, on peut utiliser des champs de maillons ou de liaison bidirec tionnels bien que cela augmente la complexité et réduise l'efficacité de la s mémoire. I1 y a également deux contraintes dépendant de la réalisa tion. La première est que tous les blocs de mémoire (et c'est pourquoi les champs de liaison) commencent à une limite paire d'octets. La seconde contrainte est que la taille maximale de la mémoire RAM est de 64 K oc o tets. Ces deux contraintes signifient que le champ de maillons ou de liai son peut étre lu ou recevoir une inscription dans un cycle de bus. Immédiatement après le champ de liaison, on a un champ K commande de bloc ". Il contient une indication de longueur de champ, c'est-à-dire le nombre d'octets d'informations stocké couramment dans les s blocs et quatre bits de commande. Les quatre bits les plus significatifs (MSB) du champ de commande de bloc constituent les bits de commande indiquant les limites du flux de données. Le champ de longueur est enre gistré dans les bits les moins significatifs (LSB) du champ de commande de bloc. zo Un bloc de mémoire est présenté dans le tableau 1 ci après: Champ de lien Commande (4 bits) | Longueur (12 bits) Donnces (Octets hauts, Octets bas) Tableau 1 s De nombreux systèmes de communication traitent les pa quets de données plutôt qu'un flux continu de données. Le système de gestion de file 10 identifie les multiples types de frontières de paquets en utilisant les quatre drapeaux de commande de chaque bloc de mémoire. Ces drapeaux de commande sont les quatre bits les plus significafs MSB so du champ de commande du bloc. Si le bit de commande le plus significatif est mis, cela signifie que le premier octet d'informations du bloc de mé moire commence un paquet. Les trois autres bits de commande restants s indiquent d'autres types de frontières. Le bit suivant le plus significatif MSB indique les frontières du paquet de transport et le bit suivant indique les frontières du paquet de l'application. Si l'on utilisait les trois bits les moins significatifs LSB sans les bits les plus significatifs MSB, le système s ne pourrait pas indiquer o se trouve la frontière du bloc mémoire. Si lorsqu'un utilisateur de files d'attente 11-14 inscrit dans son portail de files 21-24, il inscrit le bit MSB des drapeaux de commande et le portail de files d'attente arrête l'inscription du bloc de mémoire cou rant; il fait avancer ses pointeurs (non représentés) vers le champ de liai to son du bloc de mémoire suivant. Lorsqu'un utilisateur de files 1114 demande à un portail 21-24 combien d'octets de données sont disponi bles, l'utilisateur 11-14 fournit également le nombre requis d'octets et ap plique un masque au champ de commande. Le portail de files d'attente 21-24 cherche alors à travers la file jusqu'à ce qu'il atteigne le jeu des s drapeaux de commande identifié par le masque; il trouve le nombre re quis d'octets ou il se porte à la fn des données disponibles, quelles que soient celles qui arrivent en premier lieu. Le mécanisme permet d'inclure l'information de commande dans le flux de données du début et du paquet de données. L'interface o d'utilisateur de files 15-18 qui ensuite lit les données dans la file peut ex traire l'information de commande. Si le flux de données est un flux de données continu, les drapeaux de commande ne sont pas utilisés, c'est-à-dire qu'ils sont tous à l'état zéro. Une file asynchrone normalisce comporte un nombre défini de blocs de mémoire qui lui sont attribués. Si les données sont consom mées plus rapidement qu'elles sont ajoutées à la file d'attente, la file peut se vider. Les blocs attribués à la file ne sont pas utilisés mais disponibles pour d'autres files. Entre temps, une autre file d'attente peut recevoir trop de données. La file se remplira puis l'émetteur doit soit arrêter l'envoi, soit les données seront perdues. Ce type de file est appelé " unique ". L'avantage de ce type de file est que les ressources disponibles pour la file sont définies. Dans un système qui ré-attribue de manière dynamique les blocs de mémoire, à la demande, lorsqu'une file est lente à se vider, il peut 3s utiliser tous les blocs de mémoire disponibles. Dans ce cas, toutes les au tres files d'attente peuvent être arrêtées parce qu'il n'y a pas d'autres blocs de mémoire disponibles. Le système de gestion de file 10 assiste l'attribution dyna- mique de mémoire en utilisant des files d'attente groupées.. Une file d'attente groupée se compose d'un certain nombre " d'éléments de files " et une file de ressource. Les éléments de files sont les mêmes que les files s simples sauf qu'il y a une différence de nombres de blocs réservés attri- bués à chaque élément de file. Les données sont lues et inscrites dans les éléments de files. La file de ressource est en effet une liste liée de blocs de mémoire de réserve. Tous les éléments des files d'une file groupée servent de blocs de mémoire de même taille. o Lorsque des blocs de mémoire sont enlevés de la tête d'une file simple, ils sont ré-attribués à la queue de la même file sauf s'il y a une demande de réduction de taille pour cette file d'attente. Lorsque des blocs de mémoire sont enlevés de la tête d'un élément de file, ils sont générale ment attribués à la file de ressource. Lorsqu'un élément de file n'est pas is chargé pour l'enregistrement, il ne comporte pas de bloc vide. La queue de l'élément de hle pointe sur le même bloc de mémoire que le dernier pointe. Lorsqu'un portail de files 21-24 charge un élément de file pour inscrire, la file de ressource est liée à la queue de l'élément de file rendant disponibles tous les blocs de la file de ressource. Lorsqu'un portail de files 21-24 décharge un élément de file (à ce moment il élimine), tous les blocs de mémoire de réserve sont enlevés de l'élément de file et sont ré-attribués à la file de ressource. La contrainte principale de ce système est qu'un seul élé- ment d'une file groupée peut recevoir une inscription à la fois car toute la fe de ressource est ajoutée à l'élément actif. Dans la plupart des cas, un seul portail de files 21-24 inscrit dans la file groupée et c'est pourquoi il n'y a seulement pas touj ours un élément de la file qui est chargé pour l'inscription. C'est pourquoi, en théorie il n'y a pas de limite au nombre de files simples ou groupées que l'on peut créer. La contrainte principale est celle des ressources de mémoire nécessaire. L'autre type de file est une file isochrone (ISO). Une donnée isochrone est une donnée critique dans le temps telle qu'une donnée de conversation téléphonique. Une file ISO utilise différents mécanismes de commande gérés par différents circuits. Un mécanisme d'une file d'attente ss de commande ISO peut être un composant additionnel ou un composant alternatif d'un portail de files d'attente 21-24. Une file d'attente ISO utilise un unique bloc contiguë de mémoire plutôt que des blocs mémoire liés utilisés par des files asynchrones. Cette zone de mémoire est de manière caractéristique relativement petite, par exemple elle correspond à 32-256 octets. Une file ISO constitue un petit espace tampon pour isoler les utili- sateurs de files d'attente qui génèrent/ou utilisent des données de ma- nière non ordonnée. Lorsqu'une file iso est pleine, la donnée la plus s ancienne est disponible pour une surscription (pour étre effacée par une inscription qui la remplace). Ce type de files d'attente est le plus utilisé si l'intégrité des données est un facteur important. Lorsque la file d'attente est vide ou est effectivement vide, la donnée la plus récente lue dans la file est de nouveau lue. lO D'une manière caractéristique, une donnée asynchrone est une donnée à modulation par impulsions codées (un système PCM ou MIC) qui comporte des échantillons d'un signal analogique tel qu'un enre gistrement d'un signal vocal. Dans ce cas, la donnée est lue de nouveau dans la file d'attente, elle se compose d'un certain nombre d'octets de t5 données qui sont reconstruites sous la forme d'un signal audio ou de son, analogue ou identique aux sons qui viennent directement avant ou après ce signal. Un tel effet est moins perceptible qu'un blanc dans un signal audio. Si la donnée synchrone est une donnce telle qu'une donnée à modulation delta à pente variable continue (CVSD), on réalise un mon tage spécial pour assurer que la moyenne du signal reconstruit reste égale à zéro puisque sinon il y aurait saturation ou débordement numérique. Ce type de données ou des types similaires à celui-ci peut étre traités de l'une des deux façons. En premier lieu, la donnée lue est traitée de nouveau pour assurer un décalage zéro. I1 est à remarquer qu'il y a plusieurs fa çons de réaliser cela. En second lieu, on peut générer la donnée qui cor respond à une séquence d'incréments et de décréments alternés, c'est-à dire un signal sinusoïdal de faible amplitude que l'on génère à la place des données que l'on veut relire. Comme indiqué ci-dessus, de nombreux blocs de mémoire sont liés pour former une chane de blocs contenant une séquence de données. Un descripteur de files est un ensemble de pointeurs et de champs de commande qui détermine comment utiliser et gérer les chanes de blocs. Les descripteurs de files sont stockés à un endroit différent de la mémoire. Lorsque l'interface de programme va créer une file, elle crée également un descripteur de files. Une file est identifiée par l'adresse de départ du descripteur de files correspondant. Lorsqu'un utilisateur de files 11- 14 accède à une file d'attente par un portail de files d'attente 21-24, il fournit l' adre s s e de dép art du de s cripteur qui est ensuite mis s ou s la forme d'identificateur de files AID. Les files simples et les éléments de files utilisent des des- cfipteurs de files similaires. Ce type de descfipteur de files se compose d'un certain nombre de sous-descfipteurs et de bits de commande d'accès. La file de ressource utilise une version simplifiée d'un descripteur de files. Les bits de commande d'accès des descfipteurs de files assurent qu'à n'importe quel instant seulement un portail de files ou une interface de programme 20 est autofisé à modifier un champ dans le descfipteur. 0 Les tableaux de données ci-après explicitent les champs des descripteurs de files simples et d'éléments de files; le champ est enregistré en mémoire pour une file asynchrone: Tableau 2 Adresse Bit de ver- Octet haut Octet bas rouillage QID 0 | RmW Blocs à enlever Commande de verrou QID + 2 I KI du bloc (12 bits) QID + 4 Blocs de queue QID + 6 RmW Blocs non utilisés I Blocevides (seuil d'utilisation) QID + 8 1 Iype (simple = 1 éléme nt / élément = RID) QID + 10 1 Bloc de queue attribué QID + 12 1 --- | Décalage de queue attfibué (12 bits) QID + 14 2 Bloc de tête courant QID + 16 --- | Décalage de tête courant (12 bits) QID + 18 Bloc de tête attribué QID + 20 2 --- | Décalage de tête attribué (12 bits) QID + 22 2 --- | Bloc à évacuer s Le tableau 3 illustre les champs d'un descripteur de files de ressource dans lequel RID est l'identificateur de files de ressource. Tableau 3 Adresse Bit de ver- Octet haut Octet bas rouillage RID O | Blocs à enlever Commande de verrou RID + 2 2 Tête des blocs RID + 3 Queue des blocs RID + 4 RmW | Blocs vides (12 bits) Dans le descripteur de files de ressource, le champ de commande de verrouillage est un champ d'une largeur d'un octet conte s nant des bits pour commander la permission d'inscription dans les autres champs du descripteur. Le circuit comprend une séquence non interrup- tible, lecture-modification-inscription qui assure que seulement une fonc- tion (portail 21-24 ou interface de programme 20) peut changer la valeur de verrouillage à l'instant donné. La colonne de bits de verrouillage dans o les deux tableaux indique les bits qui commandent les accès et les champs concernés. Le bit de verrouillage zéro concerne le champ des difié lorsque le bit zéro est mis. Le champ " bloc à éliminer >, est un champ d'une largeur s d'un octet indiquant le nombre de blocs de mémoire qu'il faut enlever de la file d'attente. Cela nécessite un accès de commande de verrou puisqu'il y a deux fonctions qui peuvent modifier la valeur. L'interface de programme peut modifier la valeur pour demander la longueur de file à re- dimensionner et la fonction de ré-attribution décrémente alors la valeur lorsque les blocs élirninés. Le champ " blocs à éliminer,, est seulement valable pour les files simples et les files de ressource, c'est-à-dire que pour les descrip- teurs d'éléments de queue, ce champ n'est pas utilisé. Si les blocs sont enlevés d'une file groupée, l'interface de programme 20 demande qu'ils 2s soient enlevés de la file de ressource plutôt que des éléments de queue. Si le champ > est mis sur l'état 255, tous les blocs de la file sont à enlever et passent par une ré-attribution. Ainsi la valeur " blocs à enlever >. ne sera pas réduite. Le champ " KI de bloc " est un champ à 12 bits, c'est-à-dire so excluant les quatre bits de commande qui indiquent combien d'octets d'informations peuvent être inscrits dans les blocs de mémoire utilisés par la file. Le champ Lorsque la file est active, le champ deux octets. Le champ " tête de blocs " contient l'adresse du bloc de mé- moire à la tête de la chane des blocs non utilisés. Lorsqu'un portail de o files 21-24 charge un élément de file, il verrouille le champ est vide, le portail de file libère immédiatement la file de ressource en dé- verrouillant le champ " tête de blocs ". Si la file de ressource n'est pas vide, lorsque l'élément de la file est chargé, un portail de files 21- 24 met à jour le champ a tête de blocs " et libère le verrouillage lorsqu'il décharge une o file. Lorsque la file est déchargée, le champ N tête de blocs " est chargé avec des états 1 (=1) s'il n'y a pas de blocs de mémoire de réserve. Le champ " queue de blocs " dans une file simple est un champ d'une largeur d'un mot contenant l'adresse du dernier bloc de mé- moire ajouté à la file. La fonction de ré-attribution de bloc utilise ce champ 2s pour identifier o les blocs dégagés doivent étre accrochés de nouveau sur la queue de la file. Le champ " queue de blocs " pointe sur le champ de liaison dans le bloc de mémoire à la queue de la file d'attente. Comme la fonction de ré-attribution est la seule fonction qui modifie le champ Comme toutes les files simples doivent contenir au moins un bloc de mé- moire, le champ " queue de blocs " est toujours valide. Le champ " queue de blocs >' est une queue de ressource analogue à celle de " queue de blocs " dans une queue simple. Toutefois une queue de ressource peut se vider, ce qui rend invalide le champ " queue de blocs ". Le descripteur de queue de ressource inclut pour cela un bip de commande d'accès pour le champ " queue de blocs ". Lorsqu'un portail de files d'attente 21-24 veut décharger un élément de queue, il ver- rouille d'abord le champ " queue de blocs " dans un descripteur de la file de ressource associée, puis il poursuit par la procédure de déchargement. Si la procédure de déchargement ne comporte pas de blocs de réserve pour repasser dans la file de ressource, elle inscrit des états 1 partout (=1) à la fois pour la " queue de blocs " et pour la " tête de blocs ". Puis le por tail de files d'attente déverrouille à la fois les champs " tête de blocs " et champ " queue de blocs " avant de ré-attribuer des blocs à la file de res- source. Le champ " bloc vide " est un champ d'une largeur d'un oc o tet indiquant le nombre de blocs de réserve (non utilisés) à la queue d'une file simple (bien que certains des blocs puissent étre utilisés par un procé- dé d'inscription non attribué qui est touj ours chargé). Une file simple con- tient au mammum 255 blocs autorisant l'accès ensemble au champ " blocs vides " et " blocs utilisés ". La valeur de " bloc vide " multipliée " taille de blocs " donne une vague approximation de la capacité de stock- age RAM couramment disponible bien que cela exclut toute place disponi- ble dans le bloc qui pointe vers " bloc de queue attribué ". Les champs " blocs vides " et " blocs utilisés ", sont modifiés en utilisant une séquence non interruptible lecture - modification - écri ture, plutôt qu'un bit de verrouillage. Lorsqu'un portail de file d'attente 21-24 attribue une inscription, il augmente la valeur du champ " blocs utilisés " par le nombre de blocs attribués et il diminue la valeur du champ " blocs vides " du méme montant. Si la fonction de réattribution ajoute un bloc à une file, elle incrémente la valeur dans le champ " blocs 2s vides ". Le champ " blocs vides " des descripteurs d'élément de file est appelé " seuil de blocs utilisés ". Lorsqu'un élément de file est chargé du mot écriture, la file de ressource est habituellement liée à l'élément de file. Toutefois, si la valeur du champ " blocs utilisés " est supérieure à la valeur du champ " seuil de blocs utilisés ", la file de ressource n'est pas accrochée à l'élément de file d'attente. Le champ " seuil de blocs utilisés " peut servir pour éviter qu'un élément de file groupée n'utilise tous les blocs mémoire de réserve. Le seuil est uniquement appliqué lorsque la file d'attente est 3s chargée. Si un élément de file d'attente est chargé avec la file de ressource, il peut attribuer un nombre quelconque de blocs jusqu'au nombre de blocs de la file de ressource. Les blocs attribués sont ajoutés au champ blocs utilisés,. Dans les files d'attente groupées, un comptage unique " blocs vides '> est maintenu dans la file de ressource. Le champ " blocs s vides,, dans un élément de file est utilisé pour enregistrer le champ " seuil de blocs utilisés >. Comme la file groupée peut avoir besoin de garder une trace de plus de blocs de réserve pour répondre à de multiples éléments de files d'attente, le champ " blocs vides >, des descripteurs de files de res source a une longueur de 12 bits au lieu de 8 bits. o Le champ " blocs vides >, est mis à jour en utilisant une sé quence non interruptible lecture - modification - écriture. Lorsqu'un por tail de files d'attente attribue une inscription, il augmente la valeur du champ " blocs utilisés, du descripteur de l'élément de file du nombre de blocs attribués et il diminue le champ " blocs vides,' du descripteur de fi s les de ressource, de la méme valeur. Si la fonction de ré-attribution ajoute un bloc à une file, elle incrémente la valeur dans le champ " blocsvides >> du descripteur de files de ressources. Le champ " blocs utilisés " est un champ d'une largeur d'un octet qui indique le nombre de blocs de mémoire de la file d'attente conte nant des données à lire et à attribuer. Lorsqu'un portail de file d'attente attribue une inscription il augmente l'état de comptage du champ " blocs utilisés >, du nombre de blocs supplémentaires ajoutés (en utilisant une séquence non interruptible lecture - modification - écriture). Lorsqu'un portail de file d'attente attribue une lecture, le nombre de blocs libérés est 2s soustrait de la valeur du champ " blocs utilisés >. L'état de comptage " blocs utilisés >> n'est pas utilisé directement par le système gestionnaire de files d'attente 10. L'état de comptage " blocs utilisés >, est maintenu pour que les fonctions de commandes externes puissent commander et contrôler le nombre de données stockées dans une file d'attente. Avec les éléments de files, on rencontre une complication en ce que la file de res source peut fournir plus de 255 blocs à un élément de file. Cela produit le dépassement de l'état de comptage " blocs utilisés " dépassant le max- mum autorisé. Le champ " type >, est un champ d'une largeur d'un mot qui 3s se distingue entre les files simples et les éléments de files. Le champ " types " pour les files simples est avec par tous les états 1 (=1), n'importe quelle autre valeur du champ " type ', indique que la file d'attente est un élément de file d'attente Pour les éléments de files, le champ " type >> con- tient l'adresse de l'identificateur de ressource associée (RID). Le champ. type >, traité comme faisant partie du sous des- cripteur " écriture >>, n'a de sortie verrouillée lorsqu'un portail de files d'attente 21-24 charge la fle pour l'écriture. I1 y a deux cas dans lesquels le champ reçoit une inscription. Lorsque la file d'attente est créée, l'interface de programme 10 met à jour le champ " type >. Si l'interface de programme 20 veut détruire une file groupée, elle détruit tous les élé- ments de files sauf l'un des éléments. Puis avec le dernier élément de file, to il rattache la file de ressource à l'élément de file et transmet cet élément de file en une file simple. La file de ressource n'existe plus et la nouvelle file simple créée peut étre détruite de la même manière que l'on détruit les autres files simples. Le champ " bloc de queue, attribué,' est un champ d'une is taille d'un mot qui fait partie du pointeur identifiant l'endroit de la der- nière inscription attribue. Le champ. bloc de queue, attribué À' contient l'adresse de départ du bloc de mémoire dans lequel se trouve l'écriture at- tribuée. Le champ est verrouillé lorsqu'un portail de files d'attente 2124 charge une file pour l'écriture. Le portail de files d'attente 21-24 charge le o pointeur attribué dans un registre courant de pointeur de quene qui est seulement valide pendant le chargement de la file d'attente. Pendant que s'effectue l'écriture, le pointeur de queue, courante est mis à jour mais le pointeur de queue attribué n'est pas affecté. Si le portail de files d'attente doit effectuer une attribution donnée inscrite, il charge le pointeur de s queue courante dans le pointeur de queue attribué. Si le portail de files d'attente doit éliminer les données inscrites, il charge le pointeur de queue attribué dans le pointeur de queue courant. Lorsque le portail de queue transfert un sous descripteur d'écriture, il effectue touj ours d'abord une opération d'attribution ou d'élimination. Puis, lorsque le sous descripteur d'écriture est déchargé, le bit de commande d'accès d'écriture est déver- rouillé. Le champ partie du pointeur de queue attribué est un champ à 12 bits correspon- dant à un décalage par rapport au début du " bloc de queue attribué >, ss sauf définition autre, il s'agit des quatre bits les plus significatifs MSB qui sont annulés. Le champ commande au début du bloc de mémoire. L'adresse o se trouve la der- nière écriture attribuée est donnée par: champ a bloc de queue attribué " + quatre, + champ position d'écriture suivante en état statique. Le champ À bloc de tête courant >' a une largeur d'un mot o qui fait partie du sous-descripteur de lecture. Contrairement au sous- descripteur d'écriture, le sous descripteur de lecture peut être déchargé sans opération d'attribution/élimination puisqu'il ne participe plus à la réaction pour indiquer les données transférées avec succès hors du sys- tème de gestion de files d'attente 10. Ainsi l'information reçue est écrite dans le système de gestion de file d'attente 10, le contrôle d'intégrité des données fait généralement partie du flux des données et ainsi le contrôle se fait immédiatement après la réception du bloc de données. C'est pour- quoi le pointeur de tête, courant, est enregistré ainsi que le pointeur de tête attribué. Le champ a bloc de tête courant contient l'adresse de dé part du bloc de mémoire dans lequel s'est faite la dernière lecture. Lorsqu'un portail de files charge une [ile pour la lecture, il verrouille le bit de commande d'accès de lecture au sous-descripteur. Puis, il charge le pointeur de tête, courant, dans un registre. Toutes les opérations de lecture remettent à jour seulement la valeur du registre et non la valeur stockée dans la mémoire RAM. Lorsqu'une attribution de lecture est faite; les contenus du registre de pointeur de tête, courant, sont copiés dans le pointeur de tête attribué dans la mémoire RAM. Lors- qu'on élimine une lecture, le pointeur de tête attribué dans la mémoire RAM est copié dans le registre de pointeur de tête courant. Si la file est déchargée, le registre de pointeur de tête, courant, est copié dans le poin- teur de tête courant dans la mémoire RAM et le bit de commande d'accès au sous-descripteur de lecture est débloqué. Une attribution de lecture se fait lorsque la confirmation est recue indiquant la réussite du transfert des donnces; dans le cas contraire, on élimine la lecture. Le champ " décalage de tête courant " est la seconde partie du pointeur de tête courant. I1 s'agit d'un champ d'une largeur de 12 bits décalé par rapport au début du. . Le champ de dé- calage peut être courant avec une résolution de l'ordre de l'octet. Quatre octets de l'information de commande au début du bloc de mémoire sont éliminés. L'adresse correspondant à la dernière opération de lecture est donnée par: champ N bloc de tête courant >' + quatre, + champ " décalage s de tête courant.. Le champ " bloc de tête attribué " est un champ d'une lar- geur d'un mot faisant partie du sous-descripteur de lecture. Le champ a bloc de tête attribué >, contient l'adresse de départ du bloc de mémoire à laquelle se produit la dernière lecture attribuée. Lorsqu'un portail de files o d'attente attribue une lecture, au moins un bloc de mémoire peut étre li- béré et la procédure de libération est déclenchée. La procédure de libéra- tion charge l'identificateur de files d'attente et la valeur dans le nombre de blocs du champ à libérer au début de la section de données du bloc mé- moire désigné par le champ du bloc de tête attribué. L'adresse du champ s du bloc de tête attribué rejoint alors la file des blocs libérés, préte pour étre ré-attribuée. La procédure d'attribution de lecture se termine alors par la copie du pointeur de tête, courant, dans le pointeur de tête attribué. Lorsqu'une lecture a été éliminée, le pointeur de tête attribué est copié dans le pointeur de tête courant. Le chanp décalage de tête attribué est la seconde partie du pointeur de tête attribué. Ce champ a une largeur de 12 bits décalé par rapport au début du bloc de tête attribué. Le champ a une résolution de l'ordre de l'octet et contient quatre octets d'information de commande au début d'un bloc de mémoire. L'adresse à laquelle a été attribuée la der nière lecture est donnée par: champ a bloc de tête attribué " plus quatre, plus champ blocs à libérer, dans la mémoire RAM. Le mécanisme de segmentation et de ré-assemblage dans le gestionnaire (9MS) 10 comprend un moyen pour indiquer les frontières du paquet à la différence du niveau du protocole de communication. En enre- gistrant l'information sous un format générique efficace, les dispositifs s utilisant les fils d'attente permettent de prendre des décisions concernant la réunton et la division des paquets sans connaître les différents formats des paquets. Les quatre bits les plus significatifs (MSB) du champ commande de bloc " servent pour indiquer les frontières du flux des données. Ces bits seront désignés ci-après comme guide de commande ou lO drapeaux. La fonction principale du gestionnaire QMS 10 transférer d'un dispositif vers un autre, par exemple d'une interface hôte (non repré- sentée) de bus série universelle USB vers un module émetteur-récepteur radio (non représenté). L'interface hôte USB peut constituer l'utilisateur de file A,11 et le module radio peut constituer l'utilisateur de file d'attente B. 12. Un ordinateur PC, hôte (non représenté) ou un quelconque dispositif hôte sont relié à l'interface hôte USB 11. A l'interface hôte USB 11, la donnée arrive sur la section de chargement payant du paquet L2CAP ayant le format suivant: | Protocole 2 octets / multiplex heure de service | | O à 65533 octets de données de chargement payant | Le paquet L2CAP est mis par l'interface hôte USB 11 dans un ou plusieurs paquets " interface contrôleur hôte.' à HCI, et le paquet HCI a le format suivant: 2s poignce de connexion 12 bits, + frontière paquet 2 bits, + type d'émission 2 bits Champ de longueur 2 octets O à 65533 octets de données de chargement payant Chaque paquet HCI est transformé en un ou plusieurs pa- quets USB et chaque paquet USB comprend: 1 jeu de transfert de données à 8 bits indiquant la di rection des données Adresse 7 bits + point final 4 bits pour identifier la con nexion des données "dans le dent le bleu" Centre de contrôle 5 bits Déclenchement transiert de données 8 bits (pour garan tir l'absence de perte de données) Données à chargement payant (frament HCI) _ Somme de contrôle 16 bits L'information extra USB estutilisée pour garantir le trans- fert des données correctes à partir de l'hôte. Mais cette information n'est pas mémorisée. L'information USB extra est extraite par l'interface hôte USB ll qui transfert le chargement payant USB restant dans l'interface d'utilisateur de file 15. Si le chargement payant USB est le début d'un pa- quet HCI, l'interface d'utilisateur de file 15 extrait des quatre premiers octets de l'entête du paquet HCI puis transfère le restant de la charge payante dans le gestionnaire QMS 10. Si un paquet USB est le début d'un o paquet HCI, les deux premiers octets du paquet HCI sont utilisés par l'interface d'utilisateur de file 11 pour décider la file qui doit recevoir les données à enregistrer. Les deux des premiers octets ont 2 bits indiquant si le paquet HCI est le début ou la suite d'un paquet L2CAP. S'il s'agit du début du paquet L2CAP, le bit 2 du champ du drapeau à 4 bits maintenu s par le gestionnaire QMS 10 est mis par l'interface d'utilisateur de file 11. Le gestionnaire QMS 10 est informé du debut de paquets différents par l'interface hôte USB en utilisant des codes d'instruction prédéfinis. Si le paquet USB contient le début du paquet HCI, le bit 3 du champ de dra- peau à 4 bits maintenu par le gestionnaire QMS 10 est mis à l'écart. Si le o paquet USB contient une continuation d'un paquet HCI, aucun drapeau n'est mis. Les drapeaux sont formés de 4 bits adUacents aux champs de tailles de blocs dans les blocs mémoire qui forment la file. Pendant le transfert des paquets USB, la charge payante (contenant les 4 octets de chaque entête de paquet HCI) est stockée dans :5 la file. A la fin de chaque transfert de paquet USB, réussi, la donnée de la file est attribuée. Si le transfert de données n'est pas réussi, la donnée est éliminée. Du côté du module radio 12 de la file, le départ d'un mes sage L2CAP est le début d'un paquet radio. Toutefois, les limites du pa quet HCI n'ont pas à étre maintenues. C'est pourquoi un paquet radio peut être informé par un fragment d'un paquet HCI, ou encore il peut s contenir des multiples paquets HCI. Un paquet radio commence par un champ à 2 bits qui indique s'il s'agit du début ou de la poursuite d'un pa quet L2CAP. On a ensuite un débit 2 bits (indiquant si la radio peut rece voir les données) et un champ de 5 ou de 9 bits de longueur suivant le type de paquet utilisé. Bien que le module radio 12 ne soit pas concerné o par les frontières du paquet HCI, il compte le nombre de paquets HCI qui ont été envoyés avec succès et informe le PC hôte par le gestionnaire 9MS en lui indiquant combien de paquets en plus peuvent être transférés. Du fait des drapeaux à la limite des paquets, gérés par le système de ges tion de file 10, le module radio ne nécessite pas de moyens pour décoder les paquets HCI et L2CAP. Lorsque le module radio 12 reçoit des paquets, il met le bit 3 du champ du drapeau à 4 bits maintenu par le gestionnaire QMS 10 pour indiquer le début d'un paquet radio générant le code d'instruction approprié. Si l'entête du paquet indique qu'il s'agissait du début d'un pa quet L2 CAP, le bit 2 est également mis. Le champ de longueur du paquet radio est éliminé par le module radio. La donnée de chargement prépayé est stockée dans la file associée au lien ou au canal par lequel a été reçu le paquet. Le côté hôte de la file d'attente ignore les frontières entre les paquets radio et crée des paquets HCI jusqu'à une frontière de paquets L2CAP. Pour cela, l'hôte a une taille de paquet maximale préréglée HCI. L'hôte demande au gestionnaire QMS 10 combien de données le séparent du pointeur courant, soit vers la fin de la queue, soit vers le point suivant auquel est mis le bit 2 du champ à 4 bits ou risque d'avoir suffisamment de données pour remplir la taille du paquet HCI. Puis l'hôte construit une en tête de paquet HCI en utilisant une poignée de connexion associée à la file d'attente et des drapeaux L2CAP de début ou de continuation, en fonction des drapeaux de commande et de la longueur du champ reposant sur la donnée maintenant la plus disponible. Pour une interface USB, les paquets HCI sont en outre clas sés en paquets USB et tous les paquets de données utilisent la même adresse USB et le même point final. REVEND I CATI O NS 1 ) Procédé de gestion de données enregistrées dans une file d'attente dans une mémoire caractérisé en ce que s - on lit les données de l'entête de la fle d'attente, - on met à jour l'emplacement du dernier pointeur de lecture vers l'emplacement correspondant à la fin des données, - on transfert les données à destination et - à la réception de la confirmation indiquant la réussite du transfert de o données, on met à jour l'emplacement du pointeur de lecture attribué à l'emplacement correspondant à la fin des données. 2 ) Procédé selon la revendication 1, caractérisé en ce qu'en outre s lors de la réception d'une non-confirmation ou d'une confirmation né gative indiquant la réussite du transfert des données, on met à jour l'endroit du dernier pointeur de lecture pour prendre la position du pointeur de lecture attribué. o 3 ) Procédé selon la revendication 1, caractérisé en ce qu'en outre on enregistre la dernière position du pointeur de lecture et la position du pointeur de lecture attribué et on utilise le dernier pointeur de lecture et le pointeur de lecture attribué pour gérer la lecture suivante des données 2s d'une seconde file. 4 ) Procédé selon la revendication 1, caractérisé en ce qu'en outre - on lit les secondes données de la tête de la file d'attente, - on met à j our la position du second dernier pointeur lu à la position correspondant à la fin des secondes données, - on transtert les secondes données vers la destination et, - à la réception de la confirmation de la réussite du transfert des secon des données, on enlève le second pointeur lu de l'emplacement corres ss pondant à la fin des secondes données. ) Procédé selon la revendication 1, caractérisé en ce qu'en outre - on inscrit les données à la queue de la file d'attente, - on met à jour la position du dernier pointeur d'inscription à l'emplacement correspondent à la fin des données et - à la réception de la confirmation que les données reçues sont correctes, on met à jour l'emplacement du pointeur d'écriture, attribué à