<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 05/12/2016 à 13:57, Gustavo Niemeyer
a écrit :<br>
</div>
<blockquote
cite="mid:CANySw1nuAPpP5Wt6823Fz6myRsGL2reCypBqg8oq+3oNzfeR1w@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Dec 5, 2016 at 5:23 AM,
Didier Roche <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:didrocks@ubuntu.com" target="_blank">didrocks@ubuntu.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div class="m_8792450729980366169moz-cite-prefix">Le
03/12/2016 à 16:01, Gustavo Niemeyer a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Xavier,
<div><br>
</div>
<div>There's definitely a problem interrupting the
connection with the server. The fact it works
sometimes means it's inconsistent.</div>
<div><br>
</div>
<div>Can you please try to download such files
several times out of snap and snapd, to see what
the error is?</div>
<div><br>
</div>
<div>Per my note above, we had a bug in snapd
which prevents the real error from being shown.
We're always showing the digest mismatch
instead, which will of course happen if the
download is interrupted before its end.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
</div>
</blockquote>
</span> As written on the bug report + some part
feedback emails you received some weeks earlier, it
seems you ignored one part of the issue. Yes, it seems
the network is failing. However, snapd consistenly fails
in my case for downloading, while other tools, like wget
and curl can download bigger files, many times, without
ever getting one failure. They are more robust in
difficult network situations it seems.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Neither this thread nor the bug report mentioned that
wget/curl worked consistently across several tries.</div>
</div>
</div>
</div>
</blockquote>
<br>
I did though write on the bug: "contrary to curl or wget which both
supports large downloads."<br>
The feedback thread mentioned as well "while same assets can be
successfully downloaded via curl or wget".<br>
<br>
I thought that was really obvious that they worked consistently and
that I did rerun then multiple times or I wouldn't have opened the
bug report + write this feedback. Sorry if that wasn't clear enough,
let's move on :)<br>
<blockquote
cite="mid:CANySw1nuAPpP5Wt6823Fz6myRsGL2reCypBqg8oq+3oNzfeR1w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Is it the case? Did you ever get a failure with them?
Are they retrying while they work? Do you have a verbose
dumb of the process?</div>
</div>
</div>
</div>
</blockquote>
Yes, as mentioned. I never got any failure with any of them and I
did retry multiple times in loop when I saw the snapd failures.<br>
wget is in verbose mode by default and I never got any hint that it
was retrying (just getting the normal download output).<br>
<br>
I did just try a verbose download in curl (here, an ubuntu 300M
image). Here is the output: <a class="moz-txt-link-freetext" href="http://paste.ubuntu.com/23583568/">http://paste.ubuntu.com/23583568/</a>. It
seems that curl doesn't complain of any reconnect.<br>
<br>
<blockquote
cite="mid:CANySw1nuAPpP5Wt6823Fz6myRsGL2reCypBqg8oq+3oNzfeR1w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> So either the store
connection side is fragile or snapd isn't robust enough
while other tools cope with those conditions just fine
(without any warning/debug message telling that they are
retrying).<br>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, something is wrong. :)</div>
</div>
</div>
</div>
</blockquote>
<br>
Right, I have the feeling this is related to some timeout when the
connexion hangs without any data for a very short period of time (as
the failure happens in ~1s or 2s each time after downloading 1 or
2Mb).<br>
<br>
Cheers,<br>
Didier<br>
</body>
</html>