<div dir="ltr">Thanks for the roadmap. Very exciting stuff. I hope to get some packaging done on Linux to make wanproxy more accessible for testing by a wider set of users. As soon as I can get HEAD compiled in Linux :)</div><div class="gmail_extra"><br><div class="gmail_quote">On 26 April 2015 at 15:44, Juli Mallett <span dir="ltr"><<a href="mailto:juli@clockworksquid.com" target="_blank">juli@clockworksquid.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Transparent proxy support may be on my roadmap for this summer,<br>
including both the option to mux/tunnel traffic and to be truly<br>
transparent, as well as some targeting parameters (probably first by<br>
address and/or port, and eventually by some amount of protocol<br>
tasting.) No built-in support at present, but that's what all the<br>
libuinet work was/is towards. The WANProxy codebase is used with<br>
libuinet for some proprietary proxies to do transparent proxying, but<br>
not in a way suitable for inclusion in WANProxy, which is why it has<br>
not yet been supported.<br>
<br>
On Sat, Apr 25, 2015 at 10:25 PM, Ahmed Al -Ghafri<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:al-ghafri@hotmail.com">al-ghafri@hotmail.com</a>> wrote:<br>
> That's great Juli, let me try your new updated implementation then give you<br>
> feedback. I am wondering if two WANproxy machines can be put in between a<br>
> WAN link so that they are doing optimization in a bridge mode, where there<br>
> will be no need to touch the IP configurations in the existing network. Is<br>
> that possible to be achieved? By that we can have two great modes, proxy<br>
> and bridge.<br>
><br>
>> From: <a href="mailto:juli@clockworksquid.com">juli@clockworksquid.com</a><br>
>> Date: Fri, 24 Apr 2015 23:20:07 -0700<br>
>> Subject: Re: The new on-disk cache implementaion<br>
>> To: <a href="mailto:al-ghafri@hotmail.com">al-ghafri@hotmail.com</a><br>
>> CC: <a href="mailto:wanproxy@lists.wanproxy.org">wanproxy@lists.wanproxy.org</a><br>
>><br>
>> Ahmed,<br>
>><br>
>> I went through several incomplete implementations that predate<br>
>> Diego's, and I have plans to extend it beyond his work; I wanted to<br>
>> start from a design that would extend to support the features and<br>
>> functionality I intend to include, and some that were needed today,<br>
>> including the ability to share a single on-disk cache between multiple<br>
>> peers.<br>
>><br>
>> Upload and download both go into the cache, but they do not share<br>
>> data, at least not yet. So a segment from one peer will not be used<br>
>> to deduplicate data from another peer. Whether this is done in the<br>
>> future is an open question; it raises a lot of issues about<br>
>> configurations with many-to-many relationships. It might be worth<br>
>> having a configuration parameter to share a cache for local and remote<br>
>> segments in one-to-one configurations.<br>
>><br>
>> Let me know if your issue persists with the latest code.<br>
>><br>
>> Thanks,<br>
>> Juli.<br>
>><br>
>> On Fri, Apr 24, 2015 at 10:09 PM, Ahmed Al -Ghafri<br>
>> <<a href="mailto:al-ghafri@hotmail.com">al-ghafri@hotmail.com</a>> wrote:<br>
>> > Hello Juli,<br>
>> ><br>
>> > Excellent and great advance in WANProxy for this month. Finally, on-disk<br>
>> > cache is in progress<br>
>> > to be supported officially. I wanted to ask, what is the difference<br>
>> > between<br>
>> > your on-disk cache implementation<br>
>> > and Deigo implementation? I mean why you started from scratch, and not<br>
>> > build<br>
>> > on what Deigo has done?<br>
>> ><br>
>> > Another thing, in the current implementation, is the on-disk cache works<br>
>> > two<br>
>> > ways direction, I mean upload/download both are considered to fill the<br>
>> > cache?<br>
>> ><br>
>> > BTW, last time I faced a problem showing error:[/zlib/inflate_pipe] ERR:<br>
>> > virtual void InflatePipe::consume<br>
>> > If you can help I would be appreciated; here is the link:<br>
>> ><br>
>> > <a href="http://lists.wanproxy.org/pipermail/wanproxy-wanproxy.org/2015-January/001555.html" target="_blank">http://lists.wanproxy.org/pipermail/wanproxy-wanproxy.org/2015-January/001555.html</a><br>
>> ><br>
>> > Regards,<br>
>> > Ahmed<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> wanproxy mailing list<br>
> <a href="mailto:wanproxy@lists.wanproxy.org">wanproxy@lists.wanproxy.org</a><br>
> <a href="http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org" target="_blank">http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org</a><br>
><br>
_______________________________________________<br>
wanproxy mailing list<br>
<a href="mailto:wanproxy@lists.wanproxy.org">wanproxy@lists.wanproxy.org</a><br>
<a href="http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org" target="_blank">http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org</a><br>
</div></div></blockquote></div><br></div>