<div dir="ltr">RK,<div><br></div><div>A very good question!  There isn't anything like that right now.  When integration of the transparent proxy stack finishes, we may want to care about something like that, but there's no such facility right now.  In theory it'd be useful in the SOCKS case, but not with how we implement that across a WAN at present.</div>

<div><br></div><div>Thanks,</div><div>Juli.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 12, 2014 at 11:20 PM, Ramakrishna Reddy Kunreddy <span dir="ltr"><<a href="mailto:rkreddy.559@gmail.com" target="_blank">rkreddy.559@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Juli.<div><br></div><div>Really useful write up on the Deduplication problems with UDP traffic.</div>

<div><br></div><div>One more question: In a cluster deployment scenario (multiple Wanproxy machines at client and server side), Is there a automatic peer(Server side Wanproxy with closer proximity with Destination IP) recognition mechanism?.</div>


<div><br></div><div>Sorry for asking these questions without exploring the code and trying out. I will do that soon.</div><div><br></div><div>-RK</div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">

On Wed, Mar 12, 2014 at 9:52 PM, 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"><div dir="ltr">RK,<div><br></div><div>No there isn't, and there's unlikely to be.  While it's possible, it doesn't make a lot of sense to do.  At least not for deduplication; for some other kinds of protocol-specific optimizations sometimes there's value in a UDP component, but not in the general case.</div>




<div><br></div><div>For instance, the only way deduplication works is that we know that the remote side has received what we've sent previously.  In fact, the protocol is even a little more stateful than that, as we need to send a UUID and some other information at the start of a connection.  Since UDP isn't connection-oriented, we can't treat the packets as part of a single stream, which means higher overhead per-packet, or the risk of producing the wrong data.  If we get a packet which has been deduplicated and says (basically) "just send the last chunk of data you extracted", and we missed the packet before it, we'll produce data from two packets ago, which is wrong.</div>




<div><br></div><div>So then the obvious thing is for the client-side WANProxy to listen on UDP, take the data, frame it, send it over TCP to the server-side WANProxy, which then connects via UDP upstream and sends the original packet.  That solves all of those problems, but creates a new one: why are you even using UDP?  You've now got all the problems and drawbacks of TCP, and in exchange you get deduplication, maybe you don't have all the problems of sending UDP across the Internet/WAN, etc.  But what's the point?  You've now got all the latency drawbacks of TCP.  And so on.</div>




<div><br></div><div>If there's a TCP version of the protocol you're using you should use it.  If there isn't a TCP version, there's often a good reason why.  (It's loss-tolerant; it's latency-dependent; etc.  And for many of those protocols, deduplication would be as big of a mistake as for a protocol like SIP.)</div>




<div><br></div><div>If you really want to, though, it's pretty easy.  Just run any TCP-based L2 or L3 tunnelling protocol through WANProxy without encryption, and then run your UDP sessions over the tunnel.  All the drawbacks of TCP for every protocol you're using, all the problems of connection muxing, and totally breaks congestion control for TCP sessions run over the tunnel, too.  Still, if you've got a really awful protocol to deal with, or even just want to deduplicate ARP over a long site-to-site link, it can be a useful way to bridge two sites with a lot of loss or latency between them.</div>




<div><br></div><div>Thanks,</div><div>Juli.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Tue, Mar 11, 2014 at 11:37 PM, Ramakrishna Reddy Kunreddy <span dir="ltr"><<a href="mailto:rkreddy.559@gmail.com" target="_blank">rkreddy.559@gmail.com</a>></span> wrote:<br>




</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><span style="font-size:13px;font-family:arial,sans-serif">Hi,</span><div style="font-size:13px;font-family:arial,sans-serif">




<br></div><div style="font-size:13px;font-family:arial,sans-serif">
I am just trying to understand Wanproxy functionality. Is there a optimization for UDP traffic in Wanproxy?.</div><div style="font-size:13px;font-family:arial,sans-serif"><br></div><div style="font-size:13px;font-family:arial,sans-serif">





<div>Regards,</div>RK</div></div>
<br></div></div>_______________________________________________<br>
wanproxy mailing list<br>
<a href="mailto:wanproxy@lists.wanproxy.org" target="_blank">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></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Regards</div>RK
</font></span></div>
</blockquote></div><br></div>