Yum .hdr files massive

Stephen Pollei stephen_pollei at comcast.net
Mon Oct 11 02:12:41 UTC 2004


On Sun, 2004-10-10 at 09:26, seth vidal wrote:
> On Sun, 2004-10-10 at 13:45 +0200, Nils Philippsen wrote:
> > Though it would be even sweeter if byte-ranges fail you would start to
> > download the whole thing (or at least tell the server that) and break
> > the connection when you've read the entire header. Still better than
> > downloading the whole thing.
Well if you wanted to be super careful not to waste bandwidth you might
choose to use setsockopt( ..., SO_RCVBUF, ...) at least. A value from
2800 to 4200 might be about right. The reason is that between the time
you do the final read(2) and the time you do the close(2) or shutdown(2)
you will probably still have other packets in flight. Of course to
really cut down on all wastage you'd have to micromanage the advertised
tcp window to a greater extent.

My initial guess at the 2800 to 4200 is based on 1500 sized packets,
guess of how much data you will need to read from a tcp stream, and the
slow start doubling .
I estimate that a tcp connection needs to download between 4-8k to
extract the rpm header information via http.
http headers(300 bytes) + lead(100 bytes) + signature(200 bytes) +
header(2,500 to 6,500 bytes) = 3,000 to 7,000 bytes.

  2800 | 4200  window size advertised
==============
  1460 | 1460 first trip total
  4260 | 4380 second trip total
  7060 | 8580 last trip total

Note that the first packet should have given you the total amount you
needed to download so in theory if you could micromanage the advertised
window you could set it to exactly how much more you needed. You'd need
extra kernel hooks if you wanted to always have it stop at exactly the
right place every time AFAIK.

-- 
http://dmoz.org/profiles/pollei.html
http://sourceforge.net/users/stephen_pollei/
http://www.orkut.com/Profile.aspx?uid=2455954990164098214
http://stephen_pollei.home.comcast.net/
GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1  3C01 910F 6BB5 4A7D 9677
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20041010/675f9c54/attachment-0002.bin 


More information about the devel mailing list