I like your analysis and I share your frustration. And this is a so bad press for inria.
Stef On Thu, Nov 23, 2017 at 2:49 PM, Norbert Hartl <[email protected]> wrote: > > > Am 23.11.2017 um 13:18 schrieb Christophe Demarey > <[email protected]>: > > > Le 23 nov. 2017 à 12:34, Norbert Hartl <[email protected]> a écrit : > > > > Am 23.11.2017 um 11:39 schrieb Christophe Demarey > <[email protected]>: > > Hi Norbert, > > I understand your point of view that others probably share. > I also agree the situation is very bad: Inria took too much time to > investigate the problem and now, renater also … > The question is: would it be really better outside Inria? Maybe ... maybe > not … > > > Maybe that is the point. It is not a question if it works better outside > because it will. The problem we have is so serious that it will be hard to > find elsewhere. I can only repeat: It is not the download that fails which > TCP wise means that exactly the thing is downloaded that inria offered. So > something below the web server is broken and most probably they have a > corrupt storage solution meaning only if you give it broken to the web > server the broken thing can be transported in a sane manner. > > > I’m not confident with the diagnostic. > I never encountered this problem and we got no such feedback from people in > the team. So it is really strange. Indeed, if CRC is worn it does not mean > slowness but corrupted data … I do not see any reason that we do have CRC > from outside Inria but not inside. > If no solution is found today or tomorrow, we will probably see to host a > solution outside Inria. > > > If you are not confident about the diagnosis that's fine. But then it would > be cool to come up with a better one and not giving that "works for me". > That is not an explanation. Because your assumption would be that externally > and internally you use the same system and transport ways. And that is most > likely not true. > Just try to find an explanation. Here we go: > > - If I download a zip file from files.pharo.org I open a TCP connection from > my laptop to files.pharo.org > - TCP has a checksum in the header that is used to check the integrity of > each transferred package > - So I can assume that this packet of the one connection was not tampered > - If it counts for a single packet it counts for the whole file > - With all my assumption I can state that I get exactly what the > files.pharo.org is sending me > > So what are the possibilities it fails? > > - Either the stack beneath hands out the data to the TCP stack delivers > corrupt data. That could be the filesystem hence my thought > - Or there is no single connection between my laptop and files.pharo.org. In > that case the data would flow over a proxy. But even if I have two > connections and for each the integrity check counts then what I said for one > connection counts for two and more as well > - If we really decline beliving the filesystem fails (that is less likely if > it works inside of inria) > - Is there anything left? Yes, if the proxy modifies the data you can have > data integrity on the first connection, then a program that deliberately > changes the content and transfers that integer again over the second > connection. So it can be broken on the other end. > > If we then look at the file we might recognize that it has the ending .zip > and this is the file type that transfers most viruses over the net. So we > even can imagine what kind of proxy that might be, let's call it a virus > checker. That is what I would do in order to narrow the problem. > > Norbert >
