Pour rester dans l'analogie, il faudrait déjà que j'utilise le format zip et le format mp3, ce qui est synonyme d'implémentation « naïve ».
Et justement, ce que je veux éviter, c'est cette naïveté. Si j'utilisais des cliquodromes, j'aurai la compression activée par défaut dans OpenVPN, et dans netJack.
Si j'ai posté un question, c'est que justement je veux faire des choses réfléchies et pertinentes.
Comme l'a écrit Yao Kuramoto, ce n'est pas seulement mon flux netJack qui sera compressé par lzo, mais tout ce qu'il y a autour. Ici on est dans des optimisations de bout de chandelles (1 octet de perdu dans le pire des cas non compressibles !) avec des contraintes très serrées : transmettre du son en temps réel avec faible latence sur un réseau ip inamical.
Une problématique liée, par exemple, c'est qu'avec netJack je peux définir une redondance d'émission, par exemple envoyer n fois chaque paquet. Puisque « un paquet en retard est un paquet inutile », sur un réseau pourri (wifi perturbé, par exemple), j'espère avoir au moins 1 paquet sur n à l'arrivée en forçant la liaison pourrie.
Si je compresse netJack, il est possible qu'OpenVPN me compresse ma redondance, ce qui est contre productif !
Si je m'embête à envoyer n fois chaque paquet mais que finalement, sur le fil, il ne passe qu'une fois avec une entête « recopier n fois à l'arrivée », ça ne sert à rien. Si je triple mes paquets, mais que je les perds trois par trois, ça ne sert à rien.
Merci de ne pas me prendre pour plus bête que je ne suis.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: compression de compression
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message Pertinence de la compression pour un VPN. Évalué à 2.
Pour rester dans l'analogie, il faudrait déjà que j'utilise le format zip et le format mp3, ce qui est synonyme d'implémentation « naïve ».
Et justement, ce que je veux éviter, c'est cette naïveté. Si j'utilisais des cliquodromes, j'aurai la compression activée par défaut dans OpenVPN, et dans netJack.
Si j'ai posté un question, c'est que justement je veux faire des choses réfléchies et pertinentes.
Comme l'a écrit Yao Kuramoto, ce n'est pas seulement mon flux netJack qui sera compressé par lzo, mais tout ce qu'il y a autour. Ici on est dans des optimisations de bout de chandelles (1 octet de perdu dans le pire des cas non compressibles !) avec des contraintes très serrées : transmettre du son en temps réel avec faible latence sur un réseau ip inamical.
Une problématique liée, par exemple, c'est qu'avec netJack je peux définir une redondance d'émission, par exemple envoyer n fois chaque paquet. Puisque « un paquet en retard est un paquet inutile », sur un réseau pourri (wifi perturbé, par exemple), j'espère avoir au moins 1 paquet sur n à l'arrivée en forçant la liaison pourrie.
Si je compresse netJack, il est possible qu'OpenVPN me compresse ma redondance, ce qui est contre productif !
Si je m'embête à envoyer n fois chaque paquet mais que finalement, sur le fil, il ne passe qu'une fois avec une entête « recopier n fois à l'arrivée », ça ne sert à rien. Si je triple mes paquets, mais que je les perds trois par trois, ça ne sert à rien.
Merci de ne pas me prendre pour plus bête que je ne suis.
ce commentaire est sous licence cc by 4 et précédentes