I don't think it's a server side issue; I'm sure it is indeed on the client side. Eventually, you guys will figure out what the common element across all these client machines is that causes the MD5 to not match after download. My point is, I bet you $100 when you get the root cause determined, you will find that if Impulse had simply not done any MD5 check at all, everything would have worked fine.
Agreed, problems resulting from an actual corrupted file download would be very difficult to track down. But you have to ask yourself how many of those problems are you really preventing, vs. how many customers you are losing or at a minimum inconveniencing with these checks. I guarantee you the latter is a much bigger number. The lower level layers used to transmit data already have lots of protections built into them for this kind of thing. Nobody is having
[quote who="Rosco_P" reply="12" id="2555382"] Quoting DancingM4chine, reply 10 The chances of false-negatives are clearly much, much higher than the chances of an actual honest-to-goodness corrupted download. This verification "feature" is hurting your customers much more than helping them, you really aught to just scrap it. The problem is not with false-negatives. The way MD5 works [/quote] I understand how an MD5 works.
The chances of false-negatives are clearly much, much higher than the chances of an actual honest-to-goodness corrupted download. This verification "feature" is hurting your customers much more than helping them, you really aught to just scrap it.