Re: apt-proxy/rsync/proxy
On Thu, May 30, 2002 at 02:56:00PM +0100, aurelien naldi wrote:
> est-ce qu'il n'ouvrirais pas tout simplement les archives ?
> <brave new world>
> si un paquet est recompile pour changer un README ou une config par
> default alors on ouvre l'archive cote apt-proxy et cote serveur, on
> compare les date des contenus et on ne recupere que les changements, c
> le principe meme d'rsync il me semble.
> </brave new world>
Non, il ne fait ça que sur le fichier complet, coupé par
bouts (arbitraires, donc). rsync ne sait pas ce qu'il
transfère.
> mais quand on a une bonne connection est-ce qu'on ne pard pas en calcul
> le temps que l'on gagne en telechargement ?
À moins que tu ne connectes un 386/20Mhz sur du
gigaethernet, ça m'étonnerait :-)
> ceci dit il est vrai que leur explications sont pour le moins peu
> claires:
>
> apt-proxy was written to use rsync to transfer files. For large
> Packages files this is more efficient because only the changed parts
> need to be transfered. However, compressed files(.gz or .deb) are
> generally not rsyncable, resulting in no speedup. In addition, the
> rsync protocol puts more load on the backend server than http.
>
> on a donc un transfert des parties changeante des paquets uniquement,
> mais ce n'est pas possible avec des .gz ou .deb! j'avoue m'y perdre un
> peu :o)
Il y a 2 choses fondamentales ici:
- rsync marche sur un fichier, et l'algo ne dépend pas du
contenu (ie on envoie un jpg de la même façon qu'un txt ou
qu'un .tar.gz)
- Quand on compresse un fichier, changer juste un tout petit
bout change typiquement l'ensemble du fichier (pour
résumer et simplifier: la compression se base sur le
remplacement des octets courants par des chaines de bits
plus courtes, et les octets peu courants sont remplacés par
des chaines de bits plus longue. Si on compressait du texte
en français, on coderait le 'e' sur 2 bits et le 'w' sur 15
bits, comme ça en moyenne tu gagnes. C'est la base de tous
les compresseurs (pkzip, gzip, mpeg etc). Par conséquent,
quand tu changes juste un octet dans le fichier, la plupart
du temps la chaine de bit change de taille et TOUS les
octets qui suivent changent, même si la chaine de bit
restait la même. Une analogie serait un fichier d'image:
j'ai une photo en jpeg, je change la couleur des yeux d'une
personne (change quelques pixels), y'a toute les chances
pour que le nouveau jpg soit complètement différent.)
Si je me souviens bien du format .deb, il y a une partie
"configuration" puis une partie compressée pour le binaire.
Donc, si un seul des binaires change, il va falloir que
rsync recupere toute la partie compressée, qui se trouve
être la plus grosse. D'où, utiliser rsync pour ce genre de
chose n'est sans doute pas le mieux (d'un point de vue de
bande passante).
/Y
--
To UNSUBSCRIBE, email to debian-user-french-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: