<div dir="ltr">Hi Ivan,<div><br></div><div>I don't know the Linux TCP/IP stack, unfortunately, so I can't be any help there.  In your case, I think you might want to consider adding, or having someone add, a simple heartbeat mechanism to the xcodec protocol in WANProxy.</div><div><br></div><div>Thanks,</div><div>Juli.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 6, 2018 at 6:15 PM, Ivan Pizhenko <span dir="ltr"><<a href="mailto:ivan.pizhenko@gmail.com" target="_blank">ivan.pizhenko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Juli,<br>
<br>
Thanks for replying to my email.<br>
<br>
I am using Linux. I have set up VirtualBox VM with Xubuntu 16.04 LTS<br>
with latest HWE kernel 4.13 and all latest updates. I have not tuned<br>
any OS options related to networking and TCP/IP protocol. I am not<br>
using libuinet. I am not targeting FreeBSD, I need to have it working<br>
on Linux, primarily on Ubuntu Server.<br>
<br>
So I also was expecting that connection should be reset after some<br>
reasonable timeout, but that didn't happen (or I have waited for too<br>
short time??? I remember it was like at least 10 minutes). So present<br>
mechanism seems to don't work. Thanks, heartbeat is interesting idea,<br>
but probably there is something we can do via TCP connection settings<br>
that we did not do yet? I am not big specialist in TCP protocol<br>
settings, but I suppose you must be more aware in this area, so I am<br>
asking about this, probably you can recommend something else. If<br>
nothing more can be done, then sure, I will need to implement<br>
heartbeat.<br>
<span class="HOEnZb"><font color="#888888"><br>
Ivan.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
2018-03-06 3:48 GMT+02:00 Juli Mallett <<a href="mailto:juli@clockworksquid.com">juli@clockworksquid.com</a>>:<br>
> Hi Ivan,<br>
><br>
> WANProxy should pass along state when a stream is closed from end to end,<br>
> not perfectly, but your connection should be properly reset at some point<br>
> from the server going away.  There isn't anything that can be done in a<br>
> protocol-neutral way that exceeds that, but that should be good enough for<br>
> most uses.  Of course there are things that can disrupt the TCP state<br>
> machine, or settings on a system can mean that connections aren't timed out<br>
> when they should be.<br>
><br>
> Are you using libuinet, FreeBSD, Linux, or something else for the TCP/IP<br>
> stack?<br>
><br>
> An easy change would be to add a heartbeat on all active sessions with<br>
> WANProxy to actively probe for disconnected peers, but I'm not sure I'd<br>
> encourage that.  If you think that would be helpful to you, let me know.<br>
><br>
> Thanks,<br>
> Juli.<br>
><br>
> On Sat, Feb 24, 2018 at 1:09 AM, Ivan Pizhenko <<a href="mailto:ivan.pizhenko@gmail.com">ivan.pizhenko@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I am making some tests with Wanproxy to understand how much it is<br>
>> stable and reliable. I am using latest Wanproxy code from Github and<br>
>> work on Ubuntu 16.04 LTS with kernel 4.13 and all latest updates.<br>
>><br>
>> I have conducted following simple test:<br>
>><br>
>> I have installed locally Apache 2 HTTP Server and put some large file<br>
>> into the document root. Then I have configured, also locally, "client"<br>
>> and "server" Wanproxy similar to how it is described in examples<br>
>> section on <a href="http://wanproxy.org" rel="noreferrer" target="_blank">wanproxy.org</a>, but without ssh tunnel between them, to proxy<br>
>> Apaches's HTTP port. Then I have used wget to download that large file<br>
>> through "client" Wanproxy. It worked fine but slower than direct<br>
>> download from Apache. Then I have tried to do the same thing but  I<br>
>> have shut down "server" Wanproxy somewhere in the middle of download.<br>
>> The download has freezed, the were no further progress. When I have<br>
>> restarted "server" Wanproxy, the download did not resume. When I shut<br>
>> down client Wanproxy, wget showed error like "connection refused" and<br>
>> exited.<br>
>><br>
>> I would expect that when "server" Wanproxy went down, "client" one<br>
>> would disconnect clients connected to it to indicate that upstream<br>
>> link is broken, if not immediately, then after some reasonable<br>
>> timeout. Is there a way to achieve something like this with Wanproxy?<br>
>> If not, what changes to Wanproxy are needed to enable such<br>
>> functionality?<br>
>><br>
>> Ivan.<br>
>> ______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://lists.wanproxy.org/<wbr>listinfo.cgi/wanproxy-<wbr>wanproxy.org</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>