Re: Re: Request for protocol extension: get_info/info messages

>From: iain_wade <[email protected]>
> The intention of our caching peer is to have it passively listening
> for connections solely from our own customer base, not to participate
> in the general torrent distribution.
> 
> To be able to do this, we need two things. The first is to get the
> clients to connect to us. We need that to happen by default as relying
> on user configuration would limit this feature to a small fraction of
> the user base. (I have a http proxy (for tracker communications)
> written which will add itself to the list of peers before returning,
> but getting a few hundred thousand people to change their settings is
> going to be a problem for us).

Why not replace the returned list with *just* your cache?

The simplest approach might be to return one IP:port pair for each peer
the tracker returns. By then imitating the client actions, you can
reasonably effectively imitate how the client is acting and correctly
tit for tat each peer. Add in one extra record that is purely the cache
to provide cached blocks (prevents a peer from getting over-credited).

> I would like the following patch to be integrated into the official
> BitTorrent client (as well as any other clients) for this reason. It
> does a single dns lookup each time the program starts for
> "btcache.p2p" and adds the ip addresses returned to the peer list:
> 
> https://habitue.net/projects/bt/btcache.patch

Problem is this pollutes things for folks without a cache in from of
them. Why is this needed? If you can proxy the tracker connection, why is
better than modifying the response?

> The second feature would be the get_info/info extension so we can
> obtain the "pieces" and "piece length" fields needed for sensible
> torrent participation.
> 
> https://habitue.net/projects/bt/btgetinfo.patch

Why do you need to ask the client this information for sensible
participation? You can proxy with the piece# plus offset being the keys
and everything will fine. Work on 16/32K blocks and it works fine (either
you have to join 16K blocks together for clients that use 32K blocks, or
split 32K blocks for clients with 16K blocks). If you see the client ask
for the piece again, you can guess that you've got bogus data in your
cache.

I've suggested the "by_hash" mode to solve a similar situation. The nice
part about by_hash is you also add deniability for the cache. You're
caching and cannot be forced to reveal or police what your clients are
downloading (because you cannot know).


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         [email protected] PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/