Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: Current server and BitTorrent protocol

Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

Discussion topic

Back to topic list

Re: Current server and BitTorrent protocol


Author tomjennings
Full name Tom Jennings
Date 2003-04-22 16:15:22 PDT
Message On Mon, 2003-04-21 at 16:44, John Berninger wrote:

> First, attempting to integrate two transport methods for package
> distribution into a single server would be a nightmare. The Current
> server no longer does /any/ package or header transports - all of that
> is entirely handled by Apache.

Yes, and BitTorrent fits with this scheme; BitTorrent is inherently URL
based and driving it from http header data is just fine. Talking this
over with BitTorrent's developer (Bram Cohen) the most we believe we'd
need from Current is a hook such that we could see/intercept the headers
passed to apache.

> Second, we're having a hard enough time keeping Current updated
> with new versions of the client as it is - adding support for a modified
> client would increase the complexity to a level that I personally am not
> willing to work on.

Absolutely no additional requirement to support any other client is
requested or needed. I assume you (royal you) would test against the RH
client -- period.

I will modify the client to BitTorrent-enable it; "BitTorrent" would be
added to mentioned capabilities in sent headers, and the downloaded file
would be examined for mime type and if a BitTorrent file received,
download the actual file with BitTorrent code before returning to the
calling code. The modified client will work with RHN, Current, or
BT-enhanced Current, eg. all combinations of clients/servers remain 100%
compatible and functional.

> Third, and perhaps most important from my point of view, using
> up2date / Current for this apprach just seems wrong to me; the behavior
> of multiple repositories you're looking for doesn't offer any real
> advantages that I can see over what up2date / Current provides. In
> addition, if you really want multiple repositories, you should probably
> look at how Debian's apt-get works; what it seems to me you're trying to
> do is re-write apt-get to use the up2date command. It'd be easier to
> just "ln -s up2date apt-get".

The sorts of use we envision for Current is different from your intended
use, I believe, more for distributing a small number of packages in a
reliable, trustworthy, efficient and automatic way, instead of "I think
I'll go check for the latest package at Mary's site". In other words,
extending the up2date schema of secure, automated efficient downloads to
generalized software distribution.

A small test example of the use of multiple repositories is, I put the
latest up2us on my Current server, zero.wps.com. When I invoke it with
"up2us --update" it up2dates from redhat, then zero, downloading and
installing all packages from each repository. Clearly this could be

 A hard example of BitTorrent's usefulness is RedHat's recent release of
the RH9 ISOs. RH9 was pre-announced to entitled users, and Bram made it
available via BitTorrent. Bother were mentioned on slashdot. RH's
servers keeled over under the onslaught (I personally attest to that)
and the BitTorrent-enabled server stayed up 100%. You can see the direct
vs. P2P transfer statistics here: http://f.scarywater.​net/postmortem/
The first graph, showing direct (from server) downloads vs. leechers
(peer to peer) are clear.

I do realize you are working your butts off just keeping up with your
own work, and it's appreciated. Current is great software. I want to
generalize its usefulness, and at the same time avoid adding *any* load
to you or Hunter. I believe we can do that with a little planning.

Again, thanks for your time, and sorry for the long reply.


> On Mon, 21 Apr 2003, Tom Jennings wrote:
> > I wrote a while back about expanding the utility of Current and up2date,
> > to support more than (more or less) emulating the distribution of RedHat
> > RPMs, to include general RPM distribution.
> >
> > I realize you guys are busy, and any code changes are up to me, just to
> > state the obvious.
> >
> > My goal is to make Current/up2date (1) more general and (2) incorporate
> > BitTorrent for distributed download. I know you've got other things to
> > do, but if done cleanly etc, are you willing in principle to incorporate
> > BitTorrent support if I provide patches and documentation? Clearly you'd
> > wait'n'see if the result is worth your bother, but do you have any
> > up-front objections?
> >
> >
> > Up2us, my extention to up2date, currently can
> > * fetch the SSL certificate and GPG keyring from the server
> > * install both,
> > * register with Current,
> > given only the servername.
> >
> > This would seem useful for Current as it stands. Up2date remains 100%
> > untouched, and up2date config 100% untouched and fully backwards
> > compatible.
> >
> > up2us-1.1 does this now. This version does not support BitTorrent.
> >
> > It's a wrapper around up2date (both command line and GUI), essentially,
> > which technique you comment on unfavorably before; I disagree, I think
> > it's the safest and most stable. Existing up2date config -- if any -- is
> > paranoiacally preserved. It should work with client 2.7 - 3.x, and RH 7
> > or 8(9). It's exceedingly clean, install-wise, it creates and upgrades
> > it's own config, uses PAM and consolehelper, etc.
> >
> > Adding BitTorrent support requires changes to Current and up2date. I
> > fully understand and agree with your attitute towards the client. No
> > problemo here, it's the perfectly correct approach for Current.
> >
> > But if I produce patches that incorporate BitTorrent into Current,
> > cleanly, then:
> >
> > * Your goals for Current are unaffected by my stuff,
> > * Current can be deployed more broadly, for general software
> > distribution, with the stock client (RH-shipped) or the modified client
> > (BitTorrent-enabled).
> >
> > Since RedHat Inc has recently entrenched up2date in their income model,
> > it's likely they'll balk at incorporating my BitTorrent patches, which
> > goes around the central-server model for software distribution, so I
> > will own the patched version, most likely.
> >
> > Client changes would not affect Current in any way, since you would
> > continue to test against the RH-distributed client of course.
> >
> > Feedback? Thanks for your time.
> >
> > tomj
> >
> >
> >
> > Up2us, extention of up2date client:
> > http://sourceforge.n​et/projects/up2us
> >
> > BitTorrent protocol:
> > http://sourceforge.n​et/projects/bittorre​nt/
> >
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe@curr​ent.tigris.org
> > For additional commands, e-mail: dev-help at current dot tigris dot org
> --
> John Berninger
> GPG Key ID: A8C1D45C
> Fingerprint: B1BB 90CB 5314 3113 CF22 66AE 822D 42A8 A8C1 D45C
> Sit vis nobiscum.
> --
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@curr​ent.tigris.org
> For additional commands, e-mail: dev-help at current dot tigris dot org

To unsubscribe, e-mail: dev-unsubscribe@curr​ent.tigris.org
For additional commands, e-mail: dev-help at current dot tigris dot org

« Previous message in topic | 3 of 6 | Next message in topic »


Show all messages in topic

Current server and BitTorrent protocol tomjennings Tom Jennings 2003-04-21 12:39:23 PDT
     Re: Current server and BitTorrent protocol jwbernin John Berninger 2003-04-21 16:44:38 PDT
         Re: Current server and BitTorrent protocol tomjennings Tom Jennings 2003-04-22 16:15:22 PDT
             Re: Current server and BitTorrent protocol hunterm Hunter Matthews 2003-04-23 08:03:28 PDT
                 Re: Current server and BitTorrent protocol tomjennings Tom Jennings 2003-04-23 11:58:35 PDT
         Re: Current server and BitTorrent protocol tomjennings Tom Jennings 2003-04-22 16:17:55 PDT
Messages per page: