Freezed download via Wanproxy

[Juli Mallett]

Hi Ivan,

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.

Thanks,
Juli.

On Tue, Mar 6, 2018 at 6:15 PM, Ivan Pizhenko <ivan.pizhenko at gmail.com>
wrote:

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