The new on-disk cache implementaion

[Juli Mallett]

Transparent proxy support may be on my roadmap for this summer,
including both the option to mux/tunnel traffic and to be truly
transparent, as well as some targeting parameters (probably first by
address and/or port, and eventually by some amount of protocol
tasting.)  No built-in support at present, but that's what all the
libuinet work was/is towards.  The WANProxy codebase is used with
libuinet for some proprietary proxies to do transparent proxying, but
not in a way suitable for inclusion in WANProxy, which is why it has
not yet been supported.

On Sat, Apr 25, 2015 at 10:25 PM, Ahmed Al -Ghafri
<al-ghafri at hotmail.com> wrote:
> That's great Juli, let me try your new updated implementation then give you
> feedback. I am wondering if two WANproxy machines can be put  in between a
> WAN link so that they are doing optimization in a bridge mode, where there
> will be no need to touch the IP configurations in the existing network. Is
> that possible to be achieved?  By that we can have two great modes, proxy
> and bridge.
>
>> From: juli at clockworksquid.com
>> Date: Fri, 24 Apr 2015 23:20:07 -0700
>> Subject: Re: The new on-disk cache implementaion
>> To: al-ghafri at hotmail.com
>> CC: wanproxy at lists.wanproxy.org
>>
>> Ahmed,
>>
>> I went through several incomplete implementations that predate
>> Diego's, and I have plans to extend it beyond his work; I wanted to
>> start from a design that would extend to support the features and
>> functionality I intend to include, and some that were needed today,
>> including the ability to share a single on-disk cache between multiple
>> peers.
>>
>> Upload and download both go into the cache, but they do not share
>> data, at least not yet. So a segment from one peer will not be used
>> to deduplicate data from another peer. Whether this is done in the
>> future is an open question; it raises a lot of issues about
>> configurations with many-to-many relationships. It might be worth
>> having a configuration parameter to share a cache for local and remote
>> segments in one-to-one configurations.
>>
>> Let me know if your issue persists with the latest code.
>>
>> Thanks,
>> Juli.
>>
>> On Fri, Apr 24, 2015 at 10:09 PM, Ahmed Al -Ghafri
>> <al-ghafri at hotmail.com> wrote:
>> > Hello Juli,
>> >
>> > Excellent and great advance in WANProxy for this month. Finally, on-disk
>> > cache is in progress
>> > to be supported officially. I wanted to ask, what is the difference
>> > between
>> > your on-disk cache implementation
>> > and Deigo implementation? I mean why you started from scratch, and not
>> > build
>> > on what Deigo has done?
>> >
>> > Another thing, in the current implementation, is the on-disk cache works
>> > two
>> > ways direction, I mean upload/download both are considered to fill the
>> > cache?
>> >
>> > BTW, last time I faced a problem showing error:[/zlib/inflate_pipe] ERR:
>> > virtual void InflatePipe::consume
>> > If you can help I would be appreciated; here is the link:
>> >
>> > http://lists.wanproxy.org/pipermail/wanproxy-wanproxy.org/2015-January/001555.html
>> >
>> > Regards,
>> > Ahmed
>
> _______________________________________________
> wanproxy mailing list
> wanproxy at lists.wanproxy.org
> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>