Re: git peer-to-peer project: info needed
- From
- Luke Kenneth Casson Leighton <luke.leighton@gmail.com>
- Date
- Aug 30, 2010, 11:31 UTC
- Message-ID
- <AANLkTi=Fr02G6u0tEhJvaZNhG=WGdQeJacH7XuJXkgaP@mail.gmail.com>
- In-Reply-To
- <vpq39twpp0e.fsf@bauges.imag.fr>
On Mon, Aug 30, 2010 at 7:56 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
Show 12 quoted lines
> Luke Kenneth Casson Leighton <luke.leighton@gmail.com> writes: > >> hi folks, >> >> [please could you kindly cc on responses because i am subscribed with >> "no mail" set] >> >> i need some guidance on what i should be doing, to add peer-to-peer >> networking to "git fetch". > > There have already been some attempts at a "gittorrent" mechanism. > Google will tell you more about that.
i know.
it's best to assume that i've been following those, given that i wrote the advogato and slashdot articles which brought sam and jonas' efforts to peoples' attention, but for the sake of brevity in contacting the git list i didn't want to mention that, so i apologise for not mentioning that i'm aware of gittorrent.
sam has already ruled out the bittorrent protocol as a means to create "mirrorsync". mirrorsync is, as it stands, a lower-level protocol requiring the addition of DHT and other peer-to-peer infrastucture (NAT-busting), and sam is designing mirrorsync to be part of git-daemon (i.e. it requires an HTTP port).
i believe that the use of HTTP is a mistake, and i believe that a proper peer to peer git distribution protocol _requires_ bittorrent-like features, in order to have a chance of success (i.e. be "simple" enough to use i.e. _not_ require knowledge of firewall configuration etc.)
so whilst this is all way outside of the scope of the git mailing list, i'm describing the rough plan here in case anyone's interested: the rough plan is to create a VFS layer into which i can then work "pack objects" into quotes torrents quotes, named by filename after the SHA1 hash. the bittorrent protocol is perfectly capable of supporting multiple files; thus it should not be too hard a job to rip out the hard-coded filesystem access in the bittornado source code - os.listdir, open(fname, "r"/"w"), osstat etc - and then redirect the file/directory operations onto underlying git operations.
l.