tag:blogger.com,1999:blog-834134852788085492.post4630996975042771853..comments2024-03-02T07:59:30.808+01:00Comments on RealTime Data Compression: Compressed data transmissionCyanhttp://www.blogger.com/profile/02905407922640810117noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-834134852788085492.post-46089592695772265202013-01-22T23:51:41.024+01:002013-01-22T23:51:41.024+01:00Thanks for pointing towards these documents. They ...Thanks for pointing towards these documents. They are very interesting to read and watch.Cyanhttps://www.blogger.com/profile/02905407922640810117noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-20441090797236861282013-01-22T20:47:38.448+01:002013-01-22T20:47:38.448+01:00(Sorry I'm not a French speaker, I think I del...(Sorry I'm not a French speaker, I think I deleted my post.)<br /><br />Nice article. The dictionary synchronization is interesting. A paper titled ("EndRE an end-system redundancy elimination service for enterprises") implemented an end-to-end network deduplication layer and touches on dictionary synchronization a bit.<br /><br />Another interesting idea for unordered decompression is "Non-Linear Compression" (https://www.usenix.org/conference/hotstorage12/non-linear-compression-gzip-me-not), though it's just an idea and suffers from performance challenges.Fitzhttps://www.blogger.com/profile/14698511981146756298noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-73186972967742908682013-01-22T20:43:30.565+01:002013-01-22T20:43:30.565+01:00This comment has been removed by the author.Fitzhttps://www.blogger.com/profile/14698511981146756298noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-37423987591660769662012-06-11T19:08:36.702+02:002012-06-11T19:08:36.702+02:00Good point. This is pretty similar.Good point. This is pretty similar.Cyanhttps://www.blogger.com/profile/02905407922640810117noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-20209434852105701782012-06-11T11:43:55.343+02:002012-06-11T11:43:55.343+02:00These guys do this --> http://research.microsof...These guys do this --> http://research.microsoft.com/en-us/projects/coconet/Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-40284733586783955402012-05-30T22:58:21.215+02:002012-05-30T22:58:21.215+02:00Yes, i think it is a good description.
I'm not...Yes, i think it is a good description.<br />I'm not too familiar with Java's GZipStreams, so cannot comment on the comparison.<br /><br />Regarding FAST : i don't know this protocol, and it seems complex enough to not provide an evaluation overnight. However, the method you seem to imply is a kind of "static but selectable dictionary", specially optimized for each protocol.<br /><br />This is a valid way to improve compression. And moreover, it is compatible with "stateless request" properties, which may be especially suitable for scalability.<br /><br />However, it is also "protocol dependent", and cannot take advantage of values similarities. This first point is the most limiting one.<br />For specific applications though, such as banking transactions, it may not be a problem at all.Cyanhttps://www.blogger.com/profile/02905407922640810117noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-55702999155251410542012-05-30T22:12:58.156+02:002012-05-30T22:12:58.156+02:00Do you mean to create a protocol-agnostic compress...Do you mean to create a protocol-agnostic compression layer that could be plugged at both ends of a TCP connection (eg. as GZipOutputStream/GZipInputStream allows to perform in java)?<br /><br />When the protocol is known in advance, some systems use a "data dictionary" giving hints on how messages can be compressed most effectively. For example, you can check out the FAST protocol <br /><br />http://en.wikipedia.org/wiki/FAST_protocol<br /><br />The Masked Cucumber :)Anonymousnoreply@blogger.com