> 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 <http://files.pharo.org/> I open a TCP connection from my laptop to files.pharo.org <http://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 <http://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 <http://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
