Srijak Rijal wrote:
quoted text
> Hi all,
> I hope this is the right forum for this :).
>  I hope to be able to implement the gittorrent client/ tracker during
> GoogleSoc (if chosen :) ). I have been reading up on various git docs
> and listserv messages to figure out what features I want in it in
> addition to the basics. I have been concentrating especially on how to
> minimise tracker load.
>   

Note that a minimal tracker can always return the same static file,
listing known stable peers; the P2P protocol is capable of discovering
new peers.

Also, unlike BitTorrent, the protocol is capable of negotiating the
tracker update frequency.  A tracker under load would just start
advertising addresses for longer, and returning server busy responses
for peers that contact them too frequently.  See the "valid" key in the
Request, and the "expires" key in the Response.

I think in BitTorrent there is an *over*-emphasis on making the tracker
load light, because people want to be able to run them on the most
dirt-cheap hosting account they can find, because they might get shut
down and don't want a huge outlay.  But with GitTorrent, a large number
of the tracker providers are going to be software houses, and people
already running mirroring services - and so the increased load will be
more than justified by the reduced overall load.

quoted text
> I was thinking about enabling avahi in the clients so that they can
> find peers without putting that much extra load on the tracker.
> A small caveat is that avahi timeout is around 50ms, so this sort of
> dynamic peer discovery would probably turn out to work effectively
> only among clients in the same LAN. However, best case scenario is
> clients in the same LAN would have only a couple of clients talking to
> the tracker and spreading the data(as well as peer list etc) in their
> LAN.
>
> To me, this feature seems be worth implementing if enough git users
> are in the same LAN trying to get at a certain git repository.
> What do you guys think ?
>   

Looks like avahi is only intended for the local network anyway, going by
the home page and Wikipedia article.

I guess the use cases for this include programming houses and hackathons.

At a hackathon, you might scan the network for a list of projects, and
jump into one of the swarms.  Then you hack on the code.  Then to
"commit", you set up and advertise another tracker that has your list of
heads, but refers to the other repo as an "alternative" (see
Metainfo/repo/alternatives).  The other people's avahi-enhanced
gittorrent client could see that a new related project has been
advertised, and fetch new commits to "remotes/" references automatically.

SVN fans would probably then configure it to automatically merge in new
remote references to their current working tree, but that's not
important right now :-).

One current TO-DO item in the specification to make this use case
scalable is to allow connections to deal with multiple (possibly
related) repositories at the same time.  Otherwise, with 6 "committers",
you've got 6 P2P swarms.  But this can happen with the next incremental
version of the specification.

At a programming house, setting up a tracker to commit wouldn't be as
frequent, as you expect people to have the appropriate access to
commit.  It would still be useful as a live directory of projects - but
is it significantly more useful than a simple gitweb?

Anyway, the old warning about scope creep applies to this idea - working
from the bottom up is a lot better for getting things done than thinking
big.  Just look at me, I think big all the time and never get anything
done ;-)  There will be a lot of interesting technologies enabled by
gittorrent.

Sam.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html