Please bear in mind that the messages you discuss below are all
FCP messages. The FCP protocol is localhost-only, so we won't
save any network bandwidth by compressing FCP data transfers.
I don't know whether doing node to node compression has been discussed,
but I'm skeptical whether it would be worthwhile. Consider that all
the data the nodes deal with is encrypted, so this data would be highly
random and therefore highly incompressible.
On Wed, Apr 25, 2001 at 11:08:32PM -0700, Aaron Voisine wrote:
> Hey guys. I haven't been around for a while, so if this has already been
> discussed, I apologize. The major performance consideration with freenet
> is network lag. I think it would be beneficial to integrate zlib
> compression into the freenet protocols, just like in HTTP 1.1.
>
> Specifically, I suggest adding an optional field named Compression to the
> DataFound message. Acceptable values for this field would initially be
> zlib and none, with none being the default if no Compression field is
> present. Then of course if zlib compression were specified, the data
> sections of following DataChunk messages would be zlib compressed. Other
> compression algorithms could be added in later versions.
>
> An alternative would be to have the Compression field in each DataChunk
> message instead, but this would create additional overhead.
>
> The problem of backwards compatibility with older clients that do not
> support compression or only support some of the compression algorithms,
> could be solved by having the ClientGet message also contain a Compression
> field with a comma separated list of supported compression algorithms:
> Compression=zlib,none
>
> For inserts the ClientInsert message could also have a Compression field.
> If the node receiving the insert does not support the compression being
> used, it could return a CompressionError. Unfortunately, current clients
> would not know to return this error. We could wait to implement insert
> compression until some other non backwards compatible change is made and
> implement them at the same time.
>
> It we decide to add this feature, I would like to do it.
>
> l8r
> Aaron
>
> _______________________________________________
> Devl mailing list
> [EMAIL PROTECTED]
> http://lists.freenetproject.org/mailman/listinfo/devl
--
# tavin cole
#
# "The process of scientific discovery is, in effect,
# a continual flight from wonder."
# - Albert Einstein
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
