Mark Tinka wrote:
Someone can correct me if I'm wrong, but the way I know BitTorrent to
work is the file is downloaded to disk, unarchived and then listed as
ready to watch.
That's not how it works. Several streaming BitTorrent clients specifically request blocks in order so that you can start watching immediately.
Not that you need a special client, it works pretty well with the standard client as well on a well seeded torrent, as blocks are generally requested more or less in order.
It also assumes the device has all the necessary apps
and codecs needed to render the file.
Well, yes. Or you could just stream content that is guaranteed to be compatible with the device used.
On the other hand, BitTorrent could just make an Apple
TV/PS4/PS5/Xbox/whatever-device-you-use app as well.
They could, and they might even have, I forget, but there is little demand for such a thing as a centralized CDN strategy works better.
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.
- Jared
That's not how it works. Several streaming BitTorrent clients specifically request blocks in order so that you can start watching immediately.
Not that you need a special client, it works pretty well with the standard client as well on a well seeded torrent, as blocks are generally requested more or less in order.
Thanks. I wasn't aware there were torrent clients that streamed straight to video. The last time I used torrents, it was to download files for later consumption.
I found Usenet feeds more reliable.
Well, yes. Or you could just stream content that is guaranteed to be compatible with the device used.
People on this list would bother to check compatibility.
Jane + Thatho just point & click.
They could, and they might even have, I forget, but there is little demand for such a thing as a centralized CDN strategy works better.
Which is why I'm not sure it would work, in today's Internet.
Mark.
Mark Tinka wrote:
Someone can correct me if I'm wrong, but the way I know BitTorrent to
work is the file is downloaded to disk, unarchived and then listed as
ready to watch.
That's not how it works. Several streaming BitTorrent clients specifically request blocks in order so that you can start watching immediately.
Not that you need a special client, it works pretty well with the standard client as well on a well seeded torrent, as blocks are generally requested more or less in order.
It also assumes the device has all the necessary apps
and codecs needed to render the file.
Well, yes. Or you could just stream content that is guaranteed to be compatible with the device used.
On the other hand, BitTorrent could just make an Apple
TV/PS4/PS5/Xbox/whatever-device-you-use app as well.
They could, and they might even have, I forget, but there is little demand for such a thing as a centralized CDN strategy works better.
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.
Well, latency + measurements of e2e bandwidth and possibly IP+ASN information.
However, in reality, if you are trying to optimize your ability to receive data, latency + e2e bandwidth are pretty good assuming they don’t
vary greatly (which is, admittedly a problem, they do, and worse, any client-level continuous measurement at scale will affect the experiment
in a very negative way).
Nothing is stopping a BitTorrent client from being selective about its peers. The current peer selection algorithm optimizes for throughput, not adjecency or topology.
Is that bad?
It might be suboptimal for the eyeball ISP, but it seems to me that it’s probably optimal for everyone else involved.
Owen
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. ^_^;
Thanks!
Matt