Re: git peer-to-peer project: info needed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 30, 2010 at 7:56 AM, Matthieu Moy
<Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
> Luke Kenneth Casson Leighton <luke.leighton@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]