Mark Tinka wrote:
[...]
> But I doubt that
> will work, unless someone can think up a clever way to modify BitTorrent
> to suit today's network architectures.
Unless network topology is somehow exposed, this isn't possible. All anybody can do is use latency, IP and ASN information as a proxy.
Nothing is stopping a BitTorrent client from being selective about its peers. The current peer selection algorithm optimizes for throughput, not adjecency or topology.
Thank you to everyone who pointed out this has
already been tried in the past--I wasn't aware of
it, but it stands to reason. By the time I think of
something as a good idea, there's a high probability
it's already been done somewhere. ;)
In terms of exposing network topology, remember the
clients get their information on what chunks to fetch
from whom from the tracker. As each client connects
to the tracker to report what chunks it has, the tracker
can build a mapping of client IP to ASN, coupled with
latency. For added fanciness, a traceroute towards the
client's public IP can be performed, and then clusters
can be mapped of clients with the highest numbers
of common elements in the traceroute path back,
which would give you a measure of network topological
"closeness".
That is, if the traceroutes to client A and client B are the
same for 12 out of 15 hops, but the traceroutes to client A
and client C are only the same for 8 out of 15 hops, we have
a good hint that client A and client B are probably topologically
closer than client A and client C, and therefore when client A makes
a request for chunks of movie 1, if both client B and client C have
relevant chunks, we would provide client A with client B's information
preferentially over client C's information.
That way, the tracker can help cluster data transfers in roughly
topological "closeness". Over time, you can build up a more and
more accurate topological map as you collect path information
from each tracker back to each client. For added points, since
we're talking about subscription-based content delivery, associate
each client's IP address(es) with the subscriber login information
and now you have a mapping of where that subscriber watches
content from, over time. Knowing their viewing history would
allow you to get an idea of what they're likely to watch next, and
where in the network they're likely to watch it, and you can nudge
your pre-seeding of chunks of the next-most-likely-to-be-watched
content to other clients topologically near to where the subscriber
is most likely going to be connected when they want to watch that.
...but perhaps I'm getting a bit too far into the "creepy" factor at
this point. ^_^;
- Jared
Thanks!
Matt