Principaux algorithmes d’AMRHy

• AMRHy est un protocole de transport multicast fiable basé sur les services actifs. Ces derniers sont invoqués uniquement pendant les sessions multicast, l’invocation se fait à travers l’arbre de distribution multicast. Une fois que les services sont invoqués, chaque entité (source, routeurs actifs et récepteurs) se comporte de la manière suivante :

• a. Comportement de la source

−−−− Lors de l’envoi d’un paquet de données :

@IPsource @IPMulticast Numseq Ind Idsa Orgadr Données

Figure 4.2 : Structure d’un paquet de données du protocole AMRHy

@IPsource @IPdestination Numseq Type

80

- Initialisation d’un délai de garde. En pratique ce délai de garde est supérieur ou égal au RTT du récepteur le plus éloigné du groupe de la source et sera ajusté au fur et à mesure que la source reçoit les acquittements.

- Stockage du paquet de données dans un buffer du cache.

- Emission du paquet de données à une adresse multicast, adresse d’inscription de tous les récepteurs d’un groupe.

− A la réception d’un ACK :

- Libération du buffer de cache associé au paquet de données acquitté. - Ajustement de la fenêtre en émission de la source.

−−−−

- Retransmission du paquet de données à l’adresse multicast ; - Réinitialisation du délai de garde ;

b. Comportement du récepteur

−−−−

- Initialisation d’un délai d’attente aléatoire ; - Mise à jour de la liste des paquets reçus ;

−−−−

- Mise à jour de la liste des paquets reçus ;

- Se comporter comme s’il a envoyé un ACK à l’ascendant dans l’arbre de distribution multicast ;

−−−−

Si le numéro de séquence n’existe pas parmi la liste des paquets reçus alors /* Détection de

la perte par le récepteur */

- Initialisation d’un délai de garde avec une valeur égale au RTT entre le récepteur le plus éloigné du groupe et son routeur actif ;

- Envoi d’un NAK au routeur actif ;

- Enregistrement de l’adresse du répondeur ; /* Pour une réparation future */

Sinon

- Si le délai d’attente du récepteur est armé alors désarmer le délai d’attente fsi.

- Se comporter comme s’il a envoyé un ACK ; /* suppression locale des ACKs */

81

−−−−

recevoir un NAK */

- Envoi du paquet de réparation au récepteur l’ayant demandé ;

- A l’expiration du délai d’attente : /*Le délai d’attente expire avant que le récepteur ne

reçoit un ACK portant le même numéro de son ascendant */

- Envoi d’un ACK vers l’ascendant dans l’arbre de distribution multicast ;

−−−−

- Initialisation du délai de garde avec une valeur égale au RTT entre le récepteur en question et le répondeur ;

- Envoi d’un NAK au répondeur ;

c. Comportement du routeur actif

−−−−

- Stockage du paquet de données dans un buffer du cache ;

- Expédition du paquet de données aux fils directs dans l’arbre de distribution multicast ;

- A la réception d’un paquet de réparation : /* ce paquet sera traiter de la même manière

qu’un paquet de données original dans cette partie de l’arbre multicast */

−−−−

Si l’ACK provient d’un fils alors

- Subcast de l’ACK aux autres fils ;

- Initialisation d’un délai d’attente avec une valeur égale au RTT entre le routeur actif et son fils direct le plus éloigné dans l’arbre de distribution multicast ;

- Ignorance des ACKs qui arrivent des fils pendant la durée d’attente ; /*agrégation des ACKs au niveau du routeur actif */

Sinon /* l’ACK provient d’un fils */

- Si le numéro de l’ACK ne figure pas parmi la liste des paquets reçus alors

- Envoi d’un NAK à son nœud père dans l’arbre de distribution multicast ;

- Initialisation d’un délai de garde avec une valeur égale au RTT entre le routeur actif père et son fils direct le plus éloigné dans l’arbre de distribution multicast ;

- Enregistrement de l’adresse du répondeur ;

- sinon /* le paquet de données a été déjà reçu */

- Désarmement du délai d’attente ;

82

Fsi ; Fsi ;

−−−−

- Ajout de l’adresse du fils à la liste des fils n’ayant pas reçu le paquet de données ;

−−−−

- Expédition du NAK vers le répondeur ;

- Initialisation d’un délai de garde égal au RTT du routeur actif au répondeur ;

−−−−

- Subcast du paquet de données aux fils ayant effectivement envoyé un NAK ;

- Libérer le cache ;

- Envoi d’un ACK au nœud père ;

5. Conclusion

Dans ce chapitre, nous avons proposé un nouveau protocole de transport multicast fiable basé sur le concept des réseaux actifs. Celui-ci adopte une approche hybride, qui combine les différentes approches et les différentes classes, nous menons ainsi de le nommer AMRHy pour “Actif

Multicast Reliable Hybrid protocol”. Les protocoles de la classe “receiver-initiated” attribuent

la responsabilité de la détection de perte aux récepteurs, indépendamment des liens sur lesquels les pertes se sont produites, entrainant une répartition inefficace de la charge de recouvrement des pertes. Contrairement à ces protocoles, notre protocole, en combinant les deux classes “sender-initiated” et “receiver-initiated”, répartit d’une manière équitable la responsabilité de la détection des pertes entre la source et les récepteurs. Dans cette approche hybride, le lien sur lequel la perte s'est produite est pris en considération, où la source détecte les pertes qui se produisent sur les liens proches d’elle (liens source), tandis que les récepteurs se chargent de ceux qui se produisent sur leurs liens proches d’eux (liens terminaux). L'approche hybride adoptée par notre protocole permet l'héritage des avantages de chacune des classes, offrant les mécanismes efficaces pour résoudre les problèmes de la scalabilité qui surgissent à grande échelle tels que : l'implosion des acquittements en feedback, l'équilibrage de la charge de réparation, l'isolement du recouvrement ou l'exposition des récepteurs, et le problème (drop to

zero) avec les récepteurs ayant des capacités limitées. Cependant, il est clair que les avantages

présentés ne sont que théoriques et seule une analyse du protocole permettra de vérifier la véritable potentialité du protocole AMRHy. Ainsi et, afin de dégager des études comparatives

83

avec les protocoles de multicast fiable actif, une analyse des performances en termes de bande passante et débit sera détaillée dans le chapitre.

84

Chapitre 5

Analyse du protocole