Compression de flux de donnée temps réél

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.

Citation:

---

Envoyé par alpha_one_x86

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" ?

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?

Citation:

---

Envoyé par alpha_one_x86

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]

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.

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

C'est pour un protocole de mmorpg.

Pour justement bien géré la compression, les packets fréquent (ou prioritaire), j'ai écrit de le protocole pour justement suivre en gros les régles cités que j'ai du réinventé vu que j'avais pas les noms.

Le faire correctement coté protocole permet de supprimer la surcharge de la compression de petit packet (2 octet).

Par contre la compression est maintenu pour les choses externe imprévisible (je pense surtout au datapack transmit au client).
Le protocole est peu sensible au latence (compensation), donc des temps de compression peuvent être induit.
Elle est faite sur les fichiers (possibilité de mettre un cache dessus): compression lourde possible, type xz
Et la liste du datapack qu'as le client: zlib (dynamique, mais vu que c'été l'initialisation du client c'est pas génant).

Il n'y as pas des lois/topic/how-to pour la conception de protocole en stream?

Il y a le RTSP http://fr.wikipedia.org/wiki/Real_Ti...aming_Protocol mais c'est plutôt orienté multimédia.

Il y a pas mal d'implémentation du bouzin sous http://www.cs.columbia.edu/~hgs/rtsp...entations.html

Mais à mon avis, c'est un truc de bien plus bas niveau (OSI) et pas spécialement orienté multimédia dont tu aurais besoin

Le RTP/RTCP devrait assez sûrement être plus adapté à ton cas www.rap.prd.fr/pdf/technologie_streaming.pdf

D'après ce forum http://www.linuxquestions.org/questi...p-rtcp-819588/ ortp à l'air d'être relativement adapté à ce que tu cherches (implementer un protocole).

Si c'est sous Windows, il y a bRTP www.irisa.fr/temics/softwares/bRTPUserGuide.pdf où il y a un peu de code source

(j'ai encore jammais fait de dev sur du RTP/RTSP, mais une fois trouvé la bonne librairie/API, ça devrait grandement simplifier les choses :) )

C'est pour tourner sous Linux, Windows ou autres/multi-plateformes ?
(quoique ... je vois que ton code est du Qt, donc c'est sûrement pour du multi-plateformes)


@+
Yannoo