Roland Giesler | 13 Mar 20:31 2011
Picon

Corrupt cache or what else could cause this?

Hi all,

I recently downloaded teamviewer for debian/ubuntu from
http://www.teamviewer.com/download/teamviewer_linux.deb, but could not
install it since the file has a corrupted internal structure.  After much
deliberation with their technical support, re-downloads via Afrihost,
OpenWeb and FNBConnect and getting the same corrupted file, I received a
secure link from Teamviewer's technical support.  Lo and behold, the file is
fine, the checksum matches and can be installed.

Here are the two files' detials

-rw-r--r--    1 roland roland  19093632 2011-03-11 18:52
teamviewer_linux(2).deb
md5sum: 968f9c674ec2a6dca63682f7433bc59b
-rw-r--r--    1 roland roland  19093632 2011-03-08 11:03
teamviewer_linux.deb
ms5sum: 75be172866aa2d770a91db37e712beb0

Through all 3 ISP's the same faulty checksummed file is received, but
through WebAfrica with https (I didn't try the others), all it well.

This points to a corrupt cached copy somewhere, doesn't it?
Is there a common cache that serves there 3?
Doesn't the checksumming in a cache server prevent this kind of thing from
happening?
Surely a cache server is clever enough to see that it's copy is not the same
as the one requested?

Some comments, investigations if you are the cache admin of this common
(Continue reading)

jc | 13 Mar 20:42 2011
Picon

Re: Corrupt cache or what else could cause this?

On Sun, 13 Mar 2011, Roland Giesler wrote:

> I recently downloaded teamviewer for debian/ubuntu from
> http://www.teamviewer.com/download/teamviewer_linux.deb, but could not
> install it since the file has a corrupted internal structure.  After much

*snip*

> Some comments, investigations if you are the cache admin of this common
> cache, and insight and corrections if I'm misguided in my synopsis would be

sounds like it might be us (IS). we will have a look and come back to
you (mostly likely off-list while sorting it out).

j.

_______________________________________________
IOZ mailing list
IOZ@...
http://lists.internet.org.za/mailman/listinfo/ioz

Tiaan van Aardt | 13 Mar 20:47 2011

Re: Corrupt cache or what else could cause this?

Hi,

On 13-Mar-11 9:31 PM, Roland Giesler wrote:

>     I recently downloaded teamviewer for debian/ubuntu from
>     http://www.teamviewer.com/download/teamviewer_linux.deb, but could

If you do a plain:

   wget -S http://www.teamviewer.com/download/teamviewer_linux.deb

The "-S" option will show you the headers of the HTP response. In my 
case, I can see the response header lists:

   Age: 288158
   Warning: 113 wblv-ip-pcache-4 "Heuristic expiration"
   Via: 1.1 wblv-ip-pcache-4 (NetCache NetApp/6.1.1D8), 1.1 
tvwt-ip-ccache-1 (NetCache NetApp/6.1.1D8)

Which tells me the file is coming via one of the Telkom NetApp cache 
servers. What does your reveal?

regards,
   -Tiaan.

--

-- 
_____________________________________________________
TruTeq Wireless (Pty) Ltd.    Tel     +27 12 667 1530
http://www.truteq.com         Fax     +27 12 667 1531
Copyright & Legal: http://truteq.com/legal_notice.pdf
(Continue reading)

Roland Giesler | 13 Mar 21:15 2011
Picon

Re: Corrupt cache or what else could cause this?

On 13 March 2011 21:47, Tiaan van Aardt <tva@...> wrote:

> If you do a plain:
>
>  wget -S http://www.teamviewer.com/download/teamviewer_linux.deb
>
> The "-S" option will show you the headers of the HTP response. In my case,
> I can see the response header lists:
>
>  Age: 288158
>  Warning: 113 wblv-ip-pcache-4 "Heuristic expiration"
>  Via: 1.1 wblv-ip-pcache-4 (NetCache NetApp/6.1.1D8), 1.1 tvwt-ip-ccache-1
> (NetCache NetApp/6.1.1D8)
>
> Which tells me the file is coming via one of the Telkom NetApp cache
> servers. What does your reveal?
>
>
Looks like mine is not cached, but it comes from an IIS server...  :-(
Hopefully that is not the reason!

roland <at> gts-server:~/Downloads$  wget -S
http://www.teamviewer.com/download/teamviewer_linux.deb
--2011-03-13 22:09:06--
http://www.teamviewer.com/download/teamviewer_linux.deb
Resolving www.teamviewer.com... 87.230.73.24
Connecting to www.teamviewer.com|87.230.73.24|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Content-Length: 19093632
(Continue reading)

Hendrik Visage | 13 Mar 21:57 2011
Picon

Re: Corrupt cache or what else could cause this?

On Sun, Mar 13, 2011 at 9:31 PM, Roland Giesler <roland@...>wrote:

>
>   This points to a corrupt cached copy somewhere, doesn't it?Â
>

>   Doesn't the checksumming in a cache server prevent this kind of thing
>   from happening?Â
>

What checksumming in the cache servers?
The hashing typically done inside cache servers, is on the URL to "compress"
it and make it more manageable in computer storage terms.

>   Surely a cache server is clever enough to see that it's copy is not the
>   same as the one requested?
>

How? By re-downloading the same file, thus not caching? The upstream could
touch/change the date on the file, that way the upstream could "force" a
refetch if the cache time have expired.

Yes, cache "corruption" can happen, especially when they've received a bad
copy from upstream (read: solar flares ;) but more so when a download
manager asks for several pieces at once, and the upstream gives an error
half way through a transfer. I've seen a case many summers ago that cached a
page with the error at the bottom of the partial HTML.

What would be nice/interesting is to redo the wget, but with the needed
pragma=no-cache etc. to attempt a single threaded cache-bypass request.
(Continue reading)

Roland Giesler | 13 Mar 22:13 2011
Picon

Re: Corrupt cache or what else could cause this?

On 13 March 2011 22:57, Hendrik Visage <hvjunk <at> gmail.com> wrote:
>   On Sun, Mar 13, 2011 at 9:31 PM, Roland Giesler
>   <[1]roland <at> giesler.za.net> wrote:
>
>>      This points to a corrupt cached copy somewhere, doesn't it?
>
>
>>       Doesn't the checksumming in a cache server prevent this kind of
>>       thing from happening?
>
>   What checksumming in the cache servers?
>   The hashing typically done inside cache servers, is on the URL to
>   "compress" it and make it more manageable in computer storage terms.

Of course, thinking just a little harder about it, what I asked
doesn't make much sense!

>
>>       Surely a cache server is clever enough to see that it's copy is
>>       not the same as the one requested?
>
>   How? By re-downloading the same file, thus not caching? The upstream
>   could touch/change the date on the file, that way the upstream could
>   "force" a refetch if the cache time have expired.

Ja-nee.

>
>   Yes, cache "corruption" can happen, especially when they've received a
>   bad copy from upstream (read: solar flares ;) but more so when a
(Continue reading)

Roland Giesler | 17 Mar 10:33 2011
Picon

Telkom marketing at it again?

Just received a pamphlet in the mail from Telkom touting their new
"Simple" bundle.  (Note: not totally a bad offering!)

On it is a FAQ and the first question reads:

* What does kbps mean?
Kilobytes per second. This is the speed at which your line is
downloading the information from and uploading the information to the
internet. For instance, at 384kbps, a 3MB file, which is more or less
the size of your average music file, would probably take a little over
30 second to download

The problem, of course, is that the Hoi Polloi out there, have no idea
that it will actually take 7 minutes to download a 3MB file at
386kbps, not "just over 30 seconds".

This may not be a deal breaker, but Telkom (and Vodacom, MTN in the
past) have worked so hard to mislead South Africans that what they
offer is broadband instead of naming it thinband, that this just rubs
me up the wrong way completely.  And millions of people have received
this and so the darkness continues.

Would this be something that can be taken up by some industry body
like ISPA or does this fall in the ASA's jurisdiction.

regards

Roland Giesler

_______________________________________________
(Continue reading)

Rory | 17 Mar 10:50 2011
Picon

Re: Telkom marketing at it again?

On 17 March 2011 11:33, Roland Giesler <roland@...> wrote:
> * What does kbps mean?
> Kilobytes per second. This is the speed at which your line is
> downloading the information from and uploading the information to the
> internet. For instance, at 384kbps, a 3MB file, which is more or less
> the size of your average music file, would probably take a little over
> 30 second to download
>
> The problem, of course, is that the Hoi Polloi out there, have no idea
> that it will actually take 7 minutes to download a 3MB file at
> 386kbps, not "just over 30 seconds".

384Kbps = 48KB/s theoretical max download speed, ever, on that line. :)

3072KB == 3MB => 64 seconds to transfer, in an ideal world, assuming
you got the full 384Kbps, which you won't.

So how on _earth_ do they arrive at "a little over 30 second(s)"?

Unless my maths is wrong.

R.

_______________________________________________
IOZ mailing list
IOZ@...
http://lists.internet.org.za/mailman/listinfo/ioz

Aubrey Kilian | 17 Mar 10:57 2011
Picon

Re: Telkom marketing at it again?

>> The problem, of course, is that the Hoi Polloi out there, have no idea
>> that it will actually take 7 minutes to download a 3MB file at
>> 386kbps, not "just over 30 seconds".
>
> 384Kbps = 48KB/s theoretical max download speed, ever, on that line. :)
>
> 3072KB == 3MB => 64 seconds to transfer, in an ideal world, assuming
> you got the full 384Kbps, which you won't.
>
> So how on _earth_ do they arrive at "a little over 30 second(s)"?

I get to the same answer, so I was wondering how Roland was getting to
his "7 minutes".
"30 seconds" could count as "a little", depending on how you look at it.
But ja, I'm guessing it's a matter of a non-technical marketing person
dreaming up the marketing material.

-Aubrey

_______________________________________________
IOZ mailing list
IOZ@...
http://lists.internet.org.za/mailman/listinfo/ioz

William Francis Stucke | 17 Mar 13:38 2011
Picon

Re: Telkom marketing at it again?

No one seems to have addressed the first error: -

> * What does kbps mean?
> Kilobytes per second.

No, it doesn't. It means kilobits per second. Bits, not bytes.

As to a realistic time: - 

Assuming that you get the maximum possible theoretical performance out of an ADSL line, which is typically
around 87% [1]  of its capacity, we have:

Effective maximum line speed = 384 * 0.87 = 334 kbps = 334,000 bps (~= 42 kBps)

3 MB file = 3 * 1024 * 1024 * 8 = 25,165,824 bits

25,165,824 bits / 326,000 bps = 75 seconds.

That's "a little over one minute", if you're feeling generous. Realistically, since one seldom achieves
maximum theoretical performance, you may well find that it takes several minutes to download the file.
While it's impossible in practice to predict the actual speed on a contended consumer ADSL service, what
you can say is that it will never take _less_ than 75 seconds on a 384 kbps ADSL line.

More interesting, perhaps, is Telkom's assumption that one is downloading MP3 music files. From where?
Limewire for the typical kiddie?

Note that both "1000" and "1024" are used in the sums above, in the appropriate places, for speeds and sizes respectively.

[1] That arbitrary figure of 100 - 87 = 13% is what I remember from way back when I actually did the sums - and the
online tests to confirm - the overhead taken up by the ATM framing, etc. Note that there is also the IP
(Continue reading)


Gmane