Browse Prior Art Database

Method for more efficiently providing distributed downloads to resource-limited devices.

IP.com Disclosure Number: IPCOM000200640D
Publication Date: 2010-Oct-22
Document File: 2 page(s) / 46K

Publishing Venue

The IP.com Prior Art Database

Abstract

This document provides a method for connecting to peers in a distributed environment for downloading files. Certain devices, such as mobile devices, have very limited bandwidth capabilities and so should not waste this connecting to peers that do not contain parts of the files they are attempting to download.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 01 of 2

Method for more efficiently providing distributed downloads to resource -limited devices.

Current distributed download solutions rely on a central tracker, which provides information to each client, informing them of the IP addresses of the seeds (clients with all parts of the file) and peers (clients with some parts of the file).

    The local client will then connect to some or all of these seeds and peers, despite the fact that many of the peers will not have information that it needs.

    This generally works fine when running the distributed download software on a PC with a large amount of memory and a low-latency connection capable of supporting hundreds of concurrent connections, but on a mobile device with limited memory, a high-latency network, and limited support (both in the device and the network) for a large number of connections, this would be very inefficient.

    The solution herein improves the intelligence of the tracker, so that it knows which peers have which parts of the file.

In order for the distributed download system to be able to efficiently inform downloading clients who they need to connect to, changes must be made to the standard behaviour of both the tracker and the peers:

The peers must update the tracker as they complete downloading new parts of the file.

When a peer needs another part to download, it queries the tracker asking who has that part.

The tracker provides that information to the requesting peer.

    Thus, when a client starts to download a file, it will contact the tracker who will provide it with an initial list of seeds and peers. As the client needs all parts of the file at this point, it can use all of these seeds and peers immediately. As it finishes downloading a piece of the file, it updates the tracker to let it know that it now can seed that part of the file, and also asks for details of peers who have the next part that the client requires.

    If a client already has some of the file and h...