Google Gruppi non supporta più i nuovi post o le nuove iscrizioni Usenet. I contenuti storici continuano a essere visibili.

Re: LZH, ISP, FTP/HTTP

4 visualizzazioni
Passa al primo messaggio da leggere

Jonathan de Boyne Pollard

da leggere,
7 set 2011, 05:23:0707/09/11
a
> My ISP claims the poblem only happens with those files, the files may
> be "corrupt" or it may have to do with the "algorithm".
>
> Can the ISP be right?

For certain values of "right". Only you and your ISP have the whole
picture between you. However, the internal structure of a file should
not make a difference in an ideal world. It would make a difference for
non-binary file transfer, but presumably you know enough to be
transferring your LZH archive files in binary over FTP.

Several things factor into this. The content HTTP server might not
support byte ranges. Your WWW browser might be asking for gzip transfer
encoding of an LZH archive. You might have asymmetric Internet
connections, where the upstream bandwidth and downstream bandwidths are
not the same. The traffic could be backing up at some point. (Dave Yeo
and I hit that one a while back. My server on an asymmetric cable
connection ended up repeatedly filling the pipe on his dial-up
connection with a TCP window size's worth of data, which would be lost
after a time out. Shrinking the TCP window size stopped the backing up
from happening so often, and supporting byte ranges allowed his end to
resume transfers from where they stopped.)

As I said, though, only you and your ISP have the whole picture between
you. Without seeing the IP traffic that occurs when the download speed
drops to zero, and knowing what softwares are in use at each end, no-one
is going to be able to tell you what's actually going on. For all that
we know, this is some wacky compression algorithm bug in the HTTP
transfer codecs at one or the other ends that only occurs when the
current file pointer is past the 1GiB mark.

A.D. Fundum

da leggere,
7 set 2011, 08:25:1307/09/11
a
>> My ISP claims the poblem only happens with those files, the files
>> may be "corrupt" or it may have to do with the "algorithm".

>> Can the ISP be right?

> For certain values of "right".

So it's not guaranteed to be bogus.

I've transfered files with the same names quite often, my homepage is
in use for diff-backups.

> The content HTTP server might not support byte ranges. Your
> WWW browser might be asking for gzip transfer encoding of an
> LZH archive.

If (!) it happens again, does anybody want me to reproduce the same
file? I cannot download it, but a file called ZIP2.002 was just
PMSplit's part 2 of ZIP2.LZH, which contained new files from Hobbes
and had the same size as ZIP2.001 (there were 3 parts).

> You might have asymmetric Internet connections, where the
> upstream bandwidth and downstream bandwidths are
> not the same.

Yes, ADSL2.

> no-one is going to be able to tell you what's actually going on.

Well, at least it isn't a certainty the ISP is making up problems at
my side (I'm happy with them, it's just an easy claim and it seems (!)
to be a normal situation).

> For all that we know, this is some wacky compression algorithm
> bug in the HTTP transfer codecs at one or the other ends that
> only occurs when the current file pointer is past the 1GiB mark.

Understood, thanks.


--

0 nuovi messaggi