| 
Il existe Trois grands algorithmes de compression : (ayant tous les trois comme axiome d'avoir un gain à la compression inversement proportionnel aux performances de votre système) - RLE (Run-Length Encoding) Cet algorithme consiste à remplacer les caractères répétitifs par une séquence, découpée comme suit: -un caractère identifiant le début d'une compression -le caractère répété -le nombre de fois où il est répété. Cette technique offre des taux de compression assez moyens (suivant le type de données à comprimer, estimé à 10, 20 %) mais des temps de compression avantageux. C'est cet algorithme qui permet de comprimer des fichiers (compression logiciel) lors d'une sauvegarde. |
|
- Codage de HUFFMAN Il s'agit ici d'attribuer à un alphabet donnée (ASCII,EBCDIC) une longueur pour chaque caractère fonction de sa fréquence d'utilisation,et non 8 bits. L'alphabet MORSE est basé sur ce principe la lettre "E", très utilisée, est représentée par un point les caractères d'utilisation peu fréquente, par des séquences beaucoup plus longues. Cet algorithme n'est pas employé par la compression APPC. - et ENFIN l'algorithme Liv-Zempel (LZ) qui est très utilisé dans le monde de la micro-informatique (PKZIP,...) et qui a été normalisé pour la compression par modem (hard), par le CCITT sous la recommandation V42bis. |
|
Il est basé sur la technique du dictionnaire: Le système se constitue un dictionnaire de syllabes et remplace chaque syllabe par sa clé correspondante dans le dictionnaire. - quelques remarques: l'envoi du dictionnaire doit être préalable à l'envoi des données. En cas d'erreur à la transmission du dictionnaire, il faut le retransmettre dans sa totalité. Le taux de compression peut être très avantageux (jusqu'à 70 %) mais très consommateur - en mémoire (stockage interne du dictionnaire) - en ressources (construction du dictionnaire) Il semble très intéressant pour une facturation au volume (X25) très peu intéressant pour une tarification à la durée (RTC) (la phase de compression va rallonger le temps de connexion) il peut être pénalisant avec des lignes très rapides (et AS saturé). Plus rentable sur un protocole fenêtré (paquets ou fenêtres TCP/IP): un paquet va être comprimé pendant que son prédécesseur est transmis. |
|
La compression APPC nous propose quatre solutions 1/ codage RLE 2/ codage LZ avec un dictionnaire sur 9 octets 3/ codage LZ avec un dictionnaire sur 10 octets 4/ codage LZ avec un dictionnaire sur 12 octets Les performances étant décroissantes ( de 1/ vers 4/) Le taux de compression croisssant. Mais tous cela pourra se négocier, et se négociera toujours dans le sens des performances. |
|
la valeur par défaut est donnée sur les attributs réseaux (CHGNETA) DTACPR: indique la valeur lorsque votre AS est Noeud terminal - *NONE aucune compression admise - *ALLOW compression admise (quand votre AS est cible) mais jamais demandée (quand votre AS est source) - *REQUEST la compression est admise et demandée en sortie - *REQUIRE la compression est exigée - <un débit est indiqué> Débit de la ligne <= au débit renseigné ici = *REQUEST " " " " > " " " = *ALLOW DTACPRINM indique la valeur quand votre AS est Noeud intermédiaire *NONE , *REQUEST ou un débit. (mêmes significations) |
|
Les algorithmes à utiliser sont indiqués au niveau du mode (CRTMODD) DTACPR demande de compression: - *NETATR tel que défini dans les attributs réseaux - *NONE --- - *ALLOW ! - *REQUEST > voir CHGNETA - *REQUIRE ! - <un débit> --- INDTACPR algorithme à utiliser en entrée OUTDTACPR algorithme à utiliser en sortie Pour ces deux paramètres les valeurs possibles sont - *RLE - *LZ9, *LZ10, *LZ12 |
|
En cas de négociation il faut rapprocher les paramètres INDTACPR du système local et OUTDTACPR du système distant et réciproquement. Avec DTACPR(*ALLOW) la compression n'est jamais demandée si elle est demandée par le système distant, elle est acceptée avec le taux de compression le plus faible de celui demandé (OUDTACPR local) et de celui indiqué dans INDTACPR distant. DTACPR(*REQUEST) la compression est demandée avec la valeur indiquée dans INDTACPR, OUTDTAPCR. (elle peut être rejetée par le système distant) Si elle est demandée par le système distant, le taux est choisi comme avec *ALLOW.(ci-dessus) DTACPR(*REQUIRE) La compression des données est exigée et les taux de compression indiqués par INDTACPR et OUTDTACPR ne sont pas négociables. |
|
DTACPR(*REQUIRE) et DTACPR(*ALLOW) ou DTACPR(*REQUEST) cible le paramètre INDTACPR du système distant doit être supérieur ou égal au paramètre OUTDTACPR local. le paramètre OUTDTACPR du système distant doit supérieur ou égal au paramètre INDTACPR local. DTACPR(*REQUIRE) et DTACPR(*REQUIRE) cible le paramètre INDTACPR du système distant et OUDTACPR doivent être égaux. idem OUTDTACPR local et INDTACPR distant. |
|
Modifier les attributs réseau (CHGNETA) Indiquez vos choix, puis appuyez sur ENTREE. # Nom de système . . . . . . . . . SYSNAME *SAME ID local du réseau . . . . . . . LCLNETID *SAME Nom du point de contrôle local LCLCPNAME *SAME Nom de lieu local par défaut . . LCLLOCNAME *SAME Mode par défaut . . . . . . . . DFTMODE *SAME Type de noeud . . . . . . . . . NODETYPE *SAME Compression des données . . . . DTACPR > *SAME Compression en intermédiaire . . DTACPRINM > *SAME |
|
Créer une description de mode (CRTMODD) Indiquez vos choix, puis appuyez sur ENTREE. Description de mode . . . . . . ######## Nom Nombre maximal de sessions . . . 8 1-512 Nb maximal de conversations . . 8 1-512 Sessions contrôlées en local . . 4 0-512 Nombre sessions pré-établies . . 0 0-512 Valeur régulation réception . . 7 0-63 Valeur régulation émission . . . 7 0-63 Longueur maximale de RU . . . . *CALC 241-16384, *CALC Compression des données . . . . > *NETATR 1-2147483647, *NETATR... Niveau compression en entrée . . > *RLE *RLE, *LZ9, *LZ10, *LZ12... Niveau compression en sortie . . > *RLE *RLE, *LZ9, *LZ10, *LZ12... Texte 'descriptif' . . . . . . . *BLANK Fin |
