Discussion :

[alpha_one_x86]

Bonjour, j'ai un flux de donnée dons l'envoie ne doit pas être différé (temps réel).
J'envoie majoritairement des packets de 7 octets (mais des fois plusieurs mega) en upload, et majoritairement 5ko en download.
Si j'utilise zlib, je doit flush à chaque fois pour que les nouvelles données parte bien, hors ça rajoute 8 à 16 octets de donnée à chaque fois, ce qui fait une grosse surcharge, et donc au lieux de compresser les données, ça en rajoute.

J'aimerai donc savoir les algorithmes adapté pour mon usage (ceux ne rajoutant pas trop de données sur les petits packet). Le ratio m'importe plus que la vitesse de compression/décompression, mais ça n'importe peu.

J'ai pas trouver d'information pertinente sur internet, surtout concernant l'envoie en temps réél des packets, ni la surcharge pour les petit packets.

Merci d'avance si quelqu'un as des informations ou liens. Le but est de compresser ma liaison tcp.

[pseudocode]

Si j'utilise zlib, je doit flush à chaque fois pour que les nouvelles données parte bien, hors ça rajoute 8 à 16 octets de donnée à chaque fois, ce qui fait une grosse surcharge, et donc au lieux de compresser les données, ça en rajoute.

8 à 16 octets ? Tu ne ferais pas un "full flush" au lieu de faire un "sync flush" ?

[alpha_one_x86]

Apparemment si, mais j'ai pas de contrôle sur ça, j'ai du modifié la class QtIOCompressor, pour mettre Z_PARTIAL_FLUSH.
Dans mon projet:
https://github.com/alphaonex86/debug-devel
J'ai pour l'instant fait la compression lz4, lz4hc, mais je merde toujours sur la décompression avec zlib.
Quand je fait Z_PARTIAL_FLUSH après chaque packet envoyé, les packets sont compressé individuellement?

[pseudocode]

Quand je fait Z_PARTIAL_FLUSH après chaque packet envoyé, les packets sont compressé individuellement?

Z_PARTIAL_FLUSH termine la compression du bloc courant et pousse ce bloc dans le buffer de sortie. Ca permet d'avoir un buffer de sortie cohérent qui peut être envoyé au destinataire (= on peut faire un flush du stream). Le destinataire pourra alors décompresser les blocs reçus.

Data Stream ---ZLIB---> Output Buffer ---NETWORK--> Input Buffer ---ZLIB---> Data Steam

             [ bloc ]                   [packets]                 [ bloc ]
             [  in  ]                                             [  in  ]
             [memory]                                             [memory]

[alpha_one_x86]

Voila, j'en suis la:
https://github.com/alphaonex86/qtioc...compressor.cpp
Grace à mes modif ça décode le 1er packet reçu par le réseau, pas les autres...
Et j'utilie pour faire mes testes:
https://github.com/alphaonex86/debug-devel
Server en mode brute (raw), il me sert aussi à répété les packets.
Et le client en mode zlib, sans compressed by packet.

[yannoo95170]

Zlib est vraiment très "lent"
(enfin tout est relatif mais il est vraiment trop "pataud" pour pouvoir gérer très rapidement un assez grand nombre de petits messages en temps réel ...)

De quel type de données s'agit-il ?

Si ce sont très souvent les mêmes données (et/ou qu'il n'y a qu'un nombre très limité de "caractères" utilisés) un simple codage unaire (ou de Rice, Golomb ou autres) peut s'avérer avoir un ratio rapidité/compression bien plus intéressant.

L'idée étant d'utiliser des symboles de très petites tailles pour les valeurs les plus courantes, de tailles "moyennes" pour les symboles "assez courants", quitte à devoir utiliser de symboles d'assez grandes tailles pour les symboles qui n'apparaissent que très rarement (ce qui n'est pas bien grave vu qu'ils sont justement rares et seront donc rarement utilisés ...).
=> en gros, c'est exactement le même principe que le code morse avec ses points et ses tirets ...

Si tes messages de 7 octets n'utilisent qu'un nombre très limités de valeurs/caractères et que leur probabilité moyenne est connue à l'avance, tu peux utiliser une table d'association entre les deux.

Par exemple, la chaîne "AAAABBC" peut efficacement être compressé avec ces symboles :

Avec un code unaire :

A 1
B 01
C 001

ce qui fait 1 1 1 1 01 001 soit 9 bits, soit une compression d'environ 6x
(+ la table d'association a=1 B=01 et C=001 mais si c'est toujours la même table qui sera à utiliser, elle peut être mise en dure dans le code et n'a pas besoin d'être transmise)

Avec un code de Golomb :

A 1
B 010
C 011

ce qui fait 1 1 1 1 010 010 011 soit 13 bits, soit une compression d'environ 4x
(là aussi pas besoin de transmettre la table de correspondance si la fréquence d'apparation de chaque lettre/valeur est connue à l'avance et peut être mis directement en dur dans le code source)
[tu mets un 1 au milieu, la partie gauche représente le "groupe" et la partie droite l' "identifiant d'un élément dans ce groupe" => plus "le numéro/taille en bits du groupe" est gros et plus on peut mettre d'éléments dedans, c'est pour ça que ça scale s'ailleurs très bien]

La méthode unaire est interessante si tu n'utilise qu'un alphabet de quelques lettres mais dès que tu en utilise plus de 4, je pense qu'il vaut mieux utiliser un codage de Golomb qui scale beaucoup mieux avec des alphabets bien plus grands que 2 ou 3 lettres/symboles différents.

Si c'est souvent des valeurs qui se répêtent, tu peux aussi coder (valeur1, nombre d'occurences consécutives de la valeur 1), (valeur 2, nombre d'occurences consécutives de la valeur 2), (valeur 3, nombre d'occurences consécutives de la valeur 3) ... (valeur n, nombre d'occurences consécutives de la valeur n) ... (valeur m, nombre d'occurences consécutives de la valeur m)
=> c'est le codage RLE
(on peut même des fois faire un codage RLE suivi d'un codage de Golomb, si les données s'y prêtent bien sûr, pour avoir un ratio de compression encore plus important [voir même utiliser des tables de correspondance différentes pour les valeurs et les nombres d'occurences afin d'obtenir un ratio de compression encore plus important])


@+
Yannoo