<div dir="ltr"><div>Hi,</div><div><br></div><div>We've been testing WANProxy for a while.</div><div>I happen to ran into this today - <a href="http://en.wikipedia.org/wiki/SPDY">http://en.wikipedia.org/wiki/SPDY</a></div>
<div><br></div><div>And thought of this thread, and if this could help in any way to improve the speed.</div><div>I'm not to technical, but just thought it's worth to share.</div><div><br></div><div>All the Best,</div>
<div>Roy</div><div><br></div><div class="gmail_quote">On Fri, Feb 3, 2012 at 2:29 AM, Diego Woitasen <span dir="ltr"><<a href="mailto:diego@woitasen.com.ar">diego@woitasen.com.ar</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Jan 31, 2012 at 3:22 PM, Juli Mallett <<a href="mailto:juli@clockworksquid.com">juli@clockworksquid.com</a>> wrote:<br>
> Hi Diego,<br>
><br>
> A connection pool is indeed good and desirable, but I'm not sure about<br>
> the overhead — I think we would need just as many roundtrips to<br>
> establish the new session on an existing connection as to establish a<br>
> new one; the thing which really saves is to put multiple proxied<br>
> streams onto a single connection, but as you likely know, that breaks<br>
> TCP's semantics somewhat — but it's still worth doing in some<br>
> scenarios.<br>
<br>
</div>Why do you think that there is performance problem? I think that to<br>
maintain a pool of connections is easy and cheap (again, I think).<br>
I'll try to experiment around this.<br>
<br>
Multiplexing is great, but it's more complex. You need to implement a<br>
protocol inside TCP for stream identification, stream flow control,<br>
etc.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Overall, I think multiplexing, connection pooling, etc., should all be<br>
> easy to implement well and prove very useful in many circumstances.<br>
><br>
> Thanks,<br>
> Juli.<br>
><br>
> On Tue, Jan 31, 2012 at 10:11, Diego Woitasen <<a href="mailto:diego@woitasen.com.ar">diego@woitasen.com.ar</a>> wrote:<br>
>> Hi,<br>
>>  In one of the customers where I'm going to implement Wanproxy we are<br>
>> discussing about developing on-disk storage and tcp optimization.<br>
>> On-disk storage was already discussed on this list, now I was to start<br>
>> a discussion about TCP optimization.<br>
>><br>
>>  Wanproxy optimizes the amount of data transferred right now, but one<br>
>> of the biggest problems of some WAN connections is the latency<br>
>> (Satellite specially). I was thinking about a method to improve TCP<br>
>> using pools of connections.  Right now the Wanproxy client connects to<br>
>> the Wanproxy server when it receives a TCP connection. I think that we<br>
>> could improve the performance having a pool of idle TCP connections.<br>
>> When a connection is established to the Wanproxy client, it finds a<br>
>> free connection and use it. Then the connection could be closed and a<br>
>> new one could be established to keep always the same numbers idle<br>
>> ones. Or may be we could not close it and to be reused.<br>
>><br>
>> In the past I worked in a consultancy job where I developed a proof of<br>
>> concept of the described above and there results were great.<br>
>><br>
>> What do you think?<br>
>><br>
>> Regards,<br>
>>  Diego<br>
>><br>
>> --<br>
>> Diego Woitasen<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>
<br>
<br>
<br>
--<br>
Diego Woitasen<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>