Abstract:
A technique for efficiently transferring files in a peer-to-peer network promotes substantially real-time file sharing over the network. Nodes of the network may serve as both clients and servers, such that the file transfer burden in the network is equitably distributed across the nodes of the network, generally ensuring that the file dissemination process is executed as quickly as possible. In an embodiment, each node that has or receives a file advertises possession of the file so that other nodes may obtain the file therefrom. In an embodiment, a node may simultaneously receive a file via download from a particular node and serve that same file via upload to another node. Within this embodiment, a generation identifier is preferably associated with each copy of the file to prevent two nodes, each having only part of a file, from attempting to retrieve the remainder of the file from each other.

Description:
TECHNICAL FIELD  
         [0001]    This invention relates generally to group connectivity over a network and, more particularly, relates to file transfer in a peer-to-peer network.  
         BACKGROUND OF THE INVENTION  
         [0002]    As peer-to-peer networks increase in number and popularity and experience new applications, the drawbacks in current peer-to-peer technologies become more noticeable. The increase in PC computing power also emphasizes these shortcomings when contrasted with the lack of a concomitant substantial increase in the bandwidth available for use in peer-to-peer connectivity.  
           [0003]    For example, existing techniques and methodologies for the transfer of files in peer-to-peer networks are often awkward and noticeably slow, inhibiting rapid sharing of information over the network. When the peer-to-peer system is being employed for real-time group interactivity, any substantial delay in file transfer can result in a disconnected feeling, where a supposedly real-time interaction begins to feel to the user like a more stilted less dynamic interaction. Therefore, it is important to speed file transfer whenever possible.  
           [0004]    One primary reason for the slowness of current peer-to-peer file transfer protocols lies in the method with which file transfer load is apportioned among the peer-to-peer nodes. For example, in one typical transfer technique, a node having a file to share with the group simply fans the file out to all group members by uploading the file to each in parallel or serial. This imposes a significant bandwidth and computational penalty on the dispersing node since it has to serve each requester or each node receiving the material, and has to do so in a generally simultaneous or contemporaneous manner. As a result, the file transfer speed relative to the entire group is bounded by the computational capabilities and connection speed of the dispersing node.  
           [0005]    There is a need for a peer-to-peer file transfer mechanism that provides sufficient speed of transfer so that substantially real-time group interactions using a peer-to-peer network may be had without undue interruption due to file transfer delay.  
         SUMMARY OF THE INVENTION  
         [0006]    The present invention is directed to a system, method, and architecture for efficiently transferring files in a peer-to-peer network. The system is adapted to promote substantially real-time file sharing, which is especially beneficial in an online group interaction environment. In an embodiment of the invention, many nodes of the peer-to-peer network serve as both clients and servers, both receiving file information and transmitting the received information to other nodes. The file transfer burden is apportioned in an embodiment of the invention more evenly across the nodes of the network so that typically no one node bears a disproportionate file transfer load. This is useful in ensuring that the file is transferred to every node in the network as quickly as possible.  
           [0007]    In an embodiment of the invention, file dissemination is initiated by the publication of file metadata. Having received the metadata, each node determines whether it wishes to receive the associated file. If it desires to receive the file, the relevant node or nodes utilize a pull model to request the file contents from respective neighbors. In an embodiment of the invention, each node that has or receives the file advertises its possession of the file so that other nodes may then obtain the file from these secondary sources. In an embodiment of the invention, a node may substantially simultaneously receive a file via streaming download from a particular node and serve that same file via upload to another node. In this embodiment, a generation identifier is preferably used to prevent two nodes, each having the same part of a file, from attempting to retrieve the remainder of the file from each other.  
           [0008]    Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments that proceeds with reference to the accompanying figures. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0009]    While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:  
         [0010]    [0010]FIG. 1 is a schematic diagram generally illustrating an exemplary computer system usable to implement an embodiment of the invention;  
         [0011]    [0011]FIG. 2 is a schematic diagram illustrating an exemplary peer-to-peer network for facilitating file transfer according to an embodiment of the invention;  
         [0012]    [0012]FIG. 3 is a flowchart illustrating a process of file dissemination and retrieval for use in a peer-to-peer network according to an embodiment of the present invention;  
         [0013]    [0013]FIG. 4 is a flowchart illustrating a file transfer prioritization technique for use in a peer-to-peer network according to an embodiment of the present invention; and  
         [0014]    [0014]FIG. 5 is a schematic diagram showing a node client/server architecture according to an embodiment of the invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0015]    Turning to the drawings, wherein like reference numerals refer to like elements, the invention is described hereinafter in the context of a computing environment. Although it is not required for practicing the invention, the invention is described as it is implemented by computer-executable instructions, such as program modules, that are executed by a Personal Computer (PC). Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types.  
         [0016]    The invention may be implemented in computer system configurations other than a PC. For example, the invention may be realized in hand-held devices, mobile phones, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers and the like. The invention may also be practiced in distributed computing environments, where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.  
         [0017]    Thus, although the following detailed description of the invention is set forth in the context of an exemplary general-purpose computing device such as conventional PC  20 , it will be understood that the invention may be incorporated into many types of computing environments as suggested above.  
         [0018]    Before describing the invention in detail, a computing environment in which embodiments of the invention may be implemented is described in connection with FIG. 1A. The PC  20  includes a processing unit  21 , a system memory  22 , and a system bus  23  that couples various system components including the system memory to the processing unit  21 . The system bus  23  may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM)  24  and random access memory (RAM)  25 . A basic input/output system (BIOS)  26 , containing the basic routines that help to transfer information between elements within the PC  20 , such as during start-up, is stored in ROM  24 . The PC  20  further includes a hard disk drive  27  for reading from and writing to a hard disk  60 , a magnetic disk drive  28  for reading from or writing to a removable magnetic disk  29 , and an optical disk drive  30  for reading from or writing to a removable optical disk  31  such as a CD ROM or other optical media.  
         [0019]    The hard disk drive  27 , magnetic disk drive  28 , and optical disk drive  30  are connected to the system bus  23  by a hard disk drive interface  32 , a magnetic disk drive interface  33 , and an optical disk drive interface  34 , respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the PC  20 . Although the exemplary environment described herein employs one or more of a hard disk  60 , a removable magnetic disk  29 , and a removable optical disk  31 , it will be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computing device, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories, read only memories, and the like may also be used in the exemplary operating environment.  
         [0020]    A number of program modules may be stored on the hard disk  60 , magnetic disk  29 , optical disk  31 , ROM  24  or RAM  25 , including an operating system  35 , one or more applications programs  36 , other program modules  37 , and program data  38 . A user may enter commands and information into the PC  20  through input devices such as a keyboard  40  and a pointing device  42 . Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit  21  through a serial port interface  46  that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). A monitor  47  or other type of display device is also connected to the system bus  23  via an interface, such as a video adapter  48 . In addition to the monitor, PCs typically include other peripheral output devices, not shown, such as speakers and printers.  
         [0021]    The PC  20  operates in a networked environment using fixed or transient logical connections to one or more remote computers, such as a remote computer  49 . The remote computer  49  may be in general another PC, a server, a router, a network PC, a peer device or other common network node, or any other device type such as any of those mentioned elsewhere herein. The remote computer  49  typically includes many or all of the elements described above relative to the PC  20 , although there is no such requirement, and only a memory storage device  50  has been illustrated in FIG. 1A. The logical connections depicted in FIG. 1A include a local area network (LAN)  51  and a wide area network (WAN)  52 . Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.  
         [0022]    When used in a LAN networking environment, the PC  20  is connected to the local network  51  through a network interface or adapter  53 . When used in a WAN networking environment, the PC  20  typically includes a modem  54  or other means for establishing communications over the WAN  52 . The modem  54 , which may be internal or external, is connected to the system bus  23  via the serial port interface  46 . Although a standard modem may be used in an implementation of an embodiment of the invention, a broadband connection, such as one having a capacity of between about 120 kbps and 1.5 Mbps or more, will generally yield better performance. Program modules depicted relative to the PC  20 , or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. Additionally, the invention is not intended to be limited to a particular network type. Any network type, wired or wireless, fixed or transient, circuit-switched, packet-switched or other network architectures, may be used to implement the present invention.  
         [0023]    In the description that follows, the invention will be described with reference to acts and symbolic representations of operations that are performed by one or more computing devices, such as PC  20 , unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer of electrical signals representing data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operations described hereinafter may also be implemented in hardware.  
         [0024]    An exemplary peer-to-peer network  201  usable in accordance with an embodiment of the invention is shown schematically in FIG. 2. Typically, a peer-to-peer network using the invention will contain between about 2-10 nodes, although larger networks may be used to implement the invention as well. The double-ended lines between nodes A-G of the peer-to-peer network represent peer-to-peer network connections. Thus for example, in the illustrated arrangement, node A is connected directly to node B but only indirectly (i.e. not via a single link) to node C. Each peer-to-peer connection may actually comprise a number of physical and/or logical underlying connections, such as may be associated with an underlying network over which the peer-to-peer network is laid. Note that although the peer-to-peer network nodes will generally be computers, such is not required. Rather, any type of device having appropriate networking facilities may be used depending upon the user&#39;s choice of equipment.  
         [0025]    To increase the performance of the peer-to-peer network, each computer in the group may also store “common files” in a database that is kept current with the other members&#39; databases in the group. This database can be kept current in many different ways. In one implementation, whenever a particular computer changes the database, it can propagate these changes to the other computers in the peer-to-peer network via the connections described above. Alternatively, the computers in the group can automatically update their databases after a certain time period passes, polling the computers in logical connection with them for newer versions of the database. While peer-to-peer technologies generally have a number of advantages including independence from a central server and often better resource utilization, the present invention may also utilize a central server or facility (not shown) connected to one or more nodes for data storage or for maintaining state of a particular peer-to-peer group of nodes or particular offline members.  
         [0026]    The peer-to-peer network  201  can be constructed using existing peer-to-peer technologies. For example, in general, a node connects to the network  201  by establishing a connection to one of the existing nodes. At this point, the new node may “piggy back” on the connections (to other nodes) of the existing node by evaluating the other connections and nodes, if any, of the existing node, and choosing to connect to some, all, or none of those other nodes. The connecting node generally takes into account the cost of a new connection versus the beneficial attributes of the new connection in deciding whether to create additional connections based on the existing node&#39;s connections. Each node of the peer-to-peer network also maintains a record of the instantaneous state of the portions of the network of which it has knowledge, so as to track the relevant network membership portion and status at any given time as will be appreciated by those of skill in the art. It is the collection of these various records on the various nodes that actually forms the peer-to-peer network since the connections between nodes are typically not actually hard wired and in most cases are also transient in the sense of being packet switched rather than circuit switched.  
         [0027]    In accordance with one aspect of the invention, a file distribution is initiated by a node of the peer-to-peer network, such as node A. As will be described hereinafter in greater detail, the file data flows through the network to the appropriate recipient nodes while the transfer technique distributes the transfer costs relatively evenly across the network. In particular, with reference to the flow chart  301  of FIG. 3, it can be seen that the distributing node first publishes metadata associated with the file of interest in step  303 . The metadata is not file data, but rather represents information about the file itself as well as the context of the file, such as priority relative to other files. The metadata is preferably small enough to be easily flooded to all nodes via existing connections with minimal bandwidth usage via the regular peer-to-peer record flooding technique. According to this technique, all recipient nodes sequentially forward the metadata until the data has reached all nodes of the network. Note that when a node receives duplicate metadata, such as over different connections to different nodes, it simply discards any duplicate information without forwarding, and forwards only the first received copy of the metadata.  
         [0028]    In an embodiment of the invention, the metadata comprises a file name, a file size, a set of distribution characteristics, expiration information, and any module-specific information that the publishing application or module wishes to provide. In addition, the metadata may also include any other appropriate information such as creation and/or modification date, owner, creator, priority, etc. The file name within the metadata is simply an identifier linked to the file. The filename need not be absolutely unique, although it is preferably an identifier that is specific enough so that it is unlikely to be identically associated with any file other than the appropriate file on any node of the network  201 . In the case of music files, the file name may include the appropriate MP3 ID3 tags. The file size information provides an indication of how much data is contained in the file, and is preferably given with respect to the size of the file when compressed if compression is to be used in transfer. The set of distribution characteristics optionally provides a hint or suggestion as to how the file should be distributed. Finally, the expiration information specifies the time at which the file, once transferred, should be deleted from the memory of each recipient node. Note that the original metadata publication may include a declaration that the originating node has the proffered file, but that every other node does not make this declaration until it actually has at least a portion of the file as discussed in greater detail below.  
         [0029]    Once the publishing node has transmitted the metadata as in step  303 , and all nodes of the peer-to-peer network have received the metadata, each metadata recipient node decides in step  305  whether or not to request the file. A node may have any of a number of reasons to request the file. For example, if an online real-time group interaction module, such as a group audio experience module, instigated the file metadata publication, and the recipient node has active the same type of module, then the recipient node will likely want to request the proffered file.  
         [0030]    In addition, in an embodiment of the invention, a node searches its local files to determine whether it already has a copy of the relevant file, and uses any such copy rather than requesting a download from another node. The determination of whether a local copy is the “same” as the advertised copy may be based upon many factors. For example, in the case of audio files, sameness may be inferred from a correspondence in such characteristics as file name, producing artist or other party, and play length. However, in a further embodiment of the invention, this locally sourced file is not used to serve other nodes&#39; requests for the advertised file. This is because there may be differences between the locally sourced copy and the advertised copy, which may or may not be apparent at the locally sourcing node, but which may prevent continuity in downloading when there is a source switch during download by another node. Such differences may lie in the precise compression technique used to reduce the file (for example when the same file is compressed in different manners to produce different final versions), or in the underlying data used to create the file (for example when the files are associated with different cuts of the same song). The decision to use or not to use the local file in this context may be associated with the measure of file sameness that is employed.  
         [0031]    If the recipient node decides to request the file, then it checks in step  307  to determine whether any of its direct neighbor nodes have declared that they have the file. If one or more neighbors have declared that they have the file, which means that they have at least a portion of the file, then the node in question decides from which neighbor node to request the file in step  309 . This decision may be based on any number of factors including, for example, the computational and connectional characteristics (previously measured file transfer performance, speed, reliability, etc.) of the nodes.  
         [0032]    Since multiple nodes may receive portions of a file and then advertise their possession, there is a possibility in the abstract that if the relevant suppliers for these nodes experience problems, the nodes may attempt to obtain the file from each other. This would result in a deadlock since neither node has possession of the entire file. To alleviate this problem, each node that advertises its possession of a file also preferably advertises a generation number for the file. Any node that has or obtains the entire file can advertise its version as a generation 0 file. A node that advertises a partial copy that it is obtaining from a generation 0 source advertises its version as generation 1. In general, each node advertises its version as having a generation one greater than the version that it is simultaneously downloading. When one source node completes its download of a whole copy of the file, it decrements its generation advertised to 0, and the decrement flows through the chain of nodes to which it is directly or indirectly supplying uploads. Thus, the generation number associated with the advertised file versions is another factor usable in an embodiment of the invention to determine which node to obtain the file from, a lower generation being generally required, and a generation equal to the requester&#39;s generation typically not being acceptable.  
         [0033]    If only one neighbor node has declared possession of the file and has a suitable version, then step  309  is omitted for the requesting node in question. In step  311 , the requesting node requests the file from the selected neighboring node in possession of the file and begins receiving the file.  
         [0034]    In an embodiment of the invention, once the requesting node has begun receiving the file, it is able to advertise its possession to other nodes. This is because the requesting node may serve the portions of the file that it has already received while simultaneously continuing to receive the file from its supplier at approximately the same rate or greater. This acts in most cases to slightly decrease the latency of file distribution since a node need not wait for completion of file receipt before advertising its possession and serving the file to other nodes. Thus, in step  313 , the requesting node transmits a notice to its neighbor nodes that it has possession of the file in question. In step  315 , the node in question serves any received requests for the file. Finally, the process terminates at node  319 .  
         [0035]    If it was determined at step  305  that the node in question does not wish to possess the file then the process flows to step  317 , where it is determined if any neighbor node of the node in question has sent an unsolicited file request to the node in question. Because the file distribution is generally on a request only basis as described above, it is possible that a node that wants the file will not have any neighbors that obtain and advertise the file of their own initiative. Thus, after waiting an appropriate amount of time, such as approximately one file download time increment, such a node may send an unsolicited file request to one of its neighbors, prompting that neighbor to retrieve and serve the file in question. In an embodiment of the invention, each peer-to-peer application or module is associated with a particular peer-to-peer network comprised exclusively or primarily of nodes running the same application or module. Thus, in this embodiment, the likelihood of needing to use an unsolicited request is small, since each node will likely want to have the file.  
         [0036]    If it is determined at step  317  that no neighbor node of the node in question has sent an unsolicited file request to the node in question, then the process terminates at step  319 . If instead it is determined at step  317  that one or more neighbor nodes of the node in question have sent an unsolicited file request to the node in question, then the process flows to step  307  and the steps that logically follow. Note that the node in question may itself need to make an unsolicited file request to obtain the file in an embodiment of the invention.  
         [0037]    Although not discussed in extensive detail above, there are situations in which a node chooses among multiple files for upload and/or download, and/or when a choice is made between the task of uploading and the task of downloading for the particular node. These situations will be discussed in greater detail with respect to the generalized flow chart  401  of FIG. 4. Although the situation presented in FIG. 4 involves the simultaneous availability of multiple upload and download opportunities, it will be appreciated that in many cases such multiple opportunities will not exist, and in such situations, some of the steps of the flow chart  401  may be omitted as appropriate.  
         [0038]    At step  403 , a particular node has received requests to upload two or more particular files and has also received advertisements that two or more other files are available for upload to the node. In the case where the node of interest has unlimited upload and download capacity, and the simultaneous execution (i.e. at substantially the same time, or at least during overlapping time intervals) of all such activities can be accomplished without slowing or delaying any one activity, then all such uploads and downloads are preferably addressed simultaneously. If however, as is more typical, the resources of the node and/or the network are limited so that the fastest download or upload is only achieved when no other download or upload is being serviced, then the fastest possible download or upload will generally only occur by making a choice as to which activity (uploading or downloading) and file to service. In will appreciated that when the upload and download channels are entirely separate as in certain broadband technologies, that the prioritization for each channel can be accomplished separately rather than in a cooperative fashion as shown in FIG. 4.  
         [0039]    At step  405 , the potential file upload and download activities are prioritized. In particular, each file is preferably associated, such as via the metadata, with a numerical priority representing its current importance. The priorities may represent, for example, the relative order of the files in an audio play list, and may change as the play list changes. To the extent that one or more relevant file priorities change during upload or download and affect which file is currently the preferred file to upload or download, the target file may be switched midstream, with the transferred incomplete portion of the previously preferred file being stored for potential future resumption of the transfer. If file upload and download channels are entirely distinct so as to not impact each other, then the prioritization preferably occurs on a per-channel basis. That is, all potential file downloads are prioritized with respect to each other and all potential file uploads are prioritized with respect to each other. One of skill in the art will additionally appreciate that the described techniques may be easily modified to accommodate multiple independent upload channels and or multiple independent download channels.  
         [0040]    At step  407 , the highest priority file transfer is serviced. In the case of independent upload and download channels, the highest priority file upload is serviced and the highest priority download is also serviced. It should be again noted that file priorities may change during file transfer, which may result in another file having a higher priority for upload or download then the currently serviced file as discussed above. Finally, at step  409  the process terminates.  
         [0041]    [0041]FIG. 5 illustrates in schematic fashion a client/server architecture usable according to an embodiment of the invention. In particular, in the peer-to-peer network according to various embodiments of the invention, many nodes operate as both clients and servers, although it will appreciated that one or more nodes may operate only as clients or only as servers. An exemplary node client/server architecture  501  has both client facilities  503  and server facilities  505 . The client facilities  503  are responsible for requesting desired files if any and receiving such. In greater detail, the client facilities  503  preferably include a client interface  507  for receiving a request, such as from a module or application, for obtaining a particular file, such as one that has been advertised, from another node. Such requests may be prioritized and queued in priority queue  511 . At this point, the node connection interface  513  is used to execute the request and obtain the desired file at the appropriate time based on the assigned request priority.  
         [0042]    The server facilities  505  of a node preferably contain a file interface  515  for receiving file data, such as from another module or application on the node. The file information may be compressed, such as to 64 k Windows Media® Audio (WMA) format, or may be in unitary format for bulk upload or may be in streaming format for streaming upload. For clarity, two interfaces, a “Publish File” interface and a “Publish Stream” interface, are illustrated within interface  515 . The latter is used to facilitate stream publication of a file by the server portion  505  while the former is used to facilitate unitary publication of the whole file as discussed above. The file data received at the interface  515  is transmitted to the server cache  517  for temporary storage, and may be reordered relative to other pending uploads in the server priority queue  519 . Preferably, the highest priority files are received first at the file interface  515 , although priorities can change during receipt of file data at the interface  515 . Finally, the file data is made available in appropriate priority order to the node connection interface  513 . It will be appreciated that file data for upload may come alternatively from the node connection interface  513 , such as when the client facilities  503  have caused receipt of file data from another node, and the server facilities are to upload that same data to yet another node. In this case, the incoming file data may be stored in both the client priority queue and the server priority queue.  
         [0043]    It will be appreciated that a novel means of content broadcast transfer for use in a peer-to-peer network has been described. In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of invention. For example, those of skill in the art will recognize that the elements of the illustrated embodiments shown in software may be implemented in hardware and vice versa or that the illustrated embodiments can be modified in arrangement and detail without departing from the spirit of the invention. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.