Date: Fri, 4 Nov 2005 19:19:57 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: babkin@users.sourceforge.net Cc: kamal kc <kamal_ckk@yahoo.com>, freebsd <freebsd-hackers@FreeBSD.org>, freebsd <freebsd-net@FreeBSD.org> Subject: Re: Re: allocating 14KB memory per packet compression/decompression results in v Message-ID: <20051104171957.GA1120@flame.pc> In-Reply-To: <29995980.1131124468471.JavaMail.root@vms062.mailsrvcs.net> References: <29995980.1131124468471.JavaMail.root@vms062.mailsrvcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2005-11-04 11:14, Sergey Babkin <babkin@verizon.net> wrote: >Giorgos Keramidas <keramida@ceid.upatras.gr> wrote: >>On 2005-11-03 22:56, kamal kc <kamal_ckk@yahoo.com> wrote: >>> since i am using the adaptive LZW compression scheme it >>> requires construction of string table for >>> compression/decompression. So an ip packet of size 1500 bytes >>> requires a table of size (4KB + 4KB + 2KB = 12KB). >> >> I may be stating the obvious or something totally wrong, but >> couldn't the string table be constructed once instead of each >> time a packet goes down? It is my intuition that this would >> perform much much better than re-doing the work of the string >> table each time a packet goes out. > > No, the table changes as data is compressed. It records the > knowledge about the strings that have already occured in the > data. > > Keeping the table between the packets would improve the > compression but the packets would have to be transmitted > through a reliable medium since to decompress a packet you > would have to decompress all the preceding packets first > (essentially you get a stream compression). Ah, yes, I see now. You're right of course. I was thinking of something resembling a "compressed tunnel" when I wrote the reply, but that doesn't work with IP very well, unless some other sort of encapsulation is at work. > To keep the packets separate, the compression state > must be reset between them. > > But of course resetting the compression state does not > mean that the memory should be deallocated. Very true :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051104171957.GA1120>