JP2011199644A - Streaming delivery method - Google Patents

Abstract

The present invention relates to a peer-to-peer streaming distribution method, a distribution server device, and a client device, which eliminate the bias of data blocks held by peers distributed in a network and avoid load concentration on the distribution server.
Real data of content is divided into a plurality of data blocks, each data block is held by a distribution server 10 and a plurality of peers 21 to 25, and each data block of content is stored in a client 11 by each peer 21 to 25 or Delivered from the delivery server 10. The client 11 sends a data block distribution request to each of the peers 21 to 25, and when a response indicating that distribution is not possible is returned from the peer, the client 11 transmits a distribution request for the non-distributable data block to the distribution server 10. When receiving a data block distribution request, the distribution server 10 distributes the data block to the client 11 and instructs the client 11 to hold the data block.
[Selection] Figure 1

Description

  The present invention relates to a streaming distribution method, a distribution server device, and a client device. The present invention can be suitably applied to streaming distribution by peer-to-peer (P2P).

  In the conventional server / client type streaming distribution, the distribution server distributes contents to all clients, so the load is concentrated on the distribution server. For this reason, the performance and bandwidth of the distribution server have been increased in accordance with the increase in the number of clients. In order to avoid the concentration of load on the distribution server, streaming distribution by peer-to-peer (P2P) not via the distribution server has been proposed.

  In streaming distribution by peer-to-peer (P2P), content is divided into a plurality of data blocks, and each peer holds a partial data block of the content according to capability (CPU, hard disk capacity, network bandwidth, etc.). The client avoids the load concentration of the distribution server by receiving the distribution of content from some peers instead of the distribution server.

  A distributed streaming delivery method under the control of the reception side of media streaming from a group of loosely coupled peers to a client is known from Patent Document 1 below.

JP 2006-0747444 A

  In the conventional streaming distribution described in Patent Document 1 and the like, since the client randomly determines each data block to be held, the data blocks held by each client (peer) distributed on the network are biased. Sometimes. In particular, when the number of peers holding data blocks is small, the bias of data blocks held by peers is significant.

  If there is a bias in the data blocks held by the peers on the network, a small number of data blocks cannot be distributed between the client and the peer and are distributed from the distribution server, so the load is concentrated on the distribution server. . As a result, problems such as delay may occur in streaming viewing. An object of the present invention is to eliminate the bias of data blocks held by peers distributed in a network regardless of the number of peers, and to avoid load concentration on a distribution server.

  A streaming distribution method as one form for solving the above problem is to divide actual data of content into a plurality of data blocks, hold each data block in a distribution server device and a plurality of peer devices, and view content from a client device. In response to the request, in the streaming delivery method of delivering each data block of the content from each peer device or delivery server device, the client device is notified of the delivery request for the data block from the delivery server device Transmitting to the distribution server device a distribution request for the non-deliverable data block when a response indicating non-distribution is returned to the data block distribution request for each peer device; and The distribution server device sends a data block distribution request from the client device. When received, the data block as well as delivered to the client, is intended to include a step of instructing to preferentially retained the data blocks to the peer device.

  In addition, the distribution server device as another embodiment holds each data block obtained by dividing the actual data of the content, and also holds a peer list indicating identification information of the peer device holding each data block. In the distribution server for notifying the identification information of the peer device holding the data block in response to the content viewing request, the data block to be held by the client device when notifying the identification information of the peer device to the client device And means for instructing, when receiving a data block delivery request from the client device, delivering the data block to the client device and preferentially holding the data block to the peer device; It is equipped with.

  Further, in response to the content viewing request, the client device as another embodiment receives the identification information of the peer device holding each data block obtained by dividing the actual data of the content from the distribution server, and receives the peer device. On the other hand, when a client device that transmits a distribution request for each data block receives a response indicating that distribution is not possible from the peer device, the identification information of the peer device that is not capable of data block distribution is recorded and notified to the distribution server device. And means for holding a data block instructed from the distribution server among the data blocks distributed from the distribution server or the peer device.

  For each data block of content, a data block with a small number of peers holding the data block can be preferentially held in the peer device, and the bias of data blocks held by peer devices distributed in the network Can be avoided, and load concentration on the distribution server can be avoided.

It is a figure which shows the network structural example to which streaming delivery is applied. It is a figure which shows the information hold | maintained at a delivery server. It is a figure which shows the information hold | maintained at the client which performed the viewing-and-listening request | requirement of a content. It is a figure which shows the functional block structural example of a delivery server. It is a figure which shows the functional block structural example of a client. It is a figure which shows a content viewing request sequence (in the case of the request | requirement OK to a peer). It is a figure which shows a content viewing request sequence (in the case of request | requirement NG to a peer). It is a figure which shows a content viewing request sequence (when storage data is in a priority list). It is a figure which shows the processing flow of a request | requirement peer candidate list (C2) production | generation. It is a figure which shows the processing flow of a holding | maintenance data block ID list (C3) production | generation. It is a figure which shows the processing flow of the streaming viewing request in a client. It is a figure which shows the processing flow of the update of a peer list in a delivery server. It is a figure which shows the processing flow of streaming viewing-and-listening request reception in a peer. It is a figure which shows the processing flow of streaming viewing-and-listening request reception in a delivery server.

  A network configuration example to which the disclosed streaming distribution is applied is shown in FIG. In FIG. 1, in response to a content distribution request from each client 11 to 13, each data block obtained by dividing the actual data of the content is distributed from the distribution server 10 or each of the peers 21 to 25. In the following description, a distribution server device, a client device, and a peer device are simply referred to as a distribution server, a client, and a peer.

  In the example of FIG. 1, the data block whose data block ID is “1” is held in the distribution server 10 and the peers 21 and 22, and the data block whose data block ID is “2” is stored in the distribution server 10 and the peers 22 and 23. The data block with the data block ID “3” is held in the distribution server 10 and the peers 21 and 25, and the data block with the data block ID “4” is held in the distribution server 1 and the peers 23 and 24. An example is shown.

  Information held in the distribution server is shown in FIG. The distribution server holds content information (S1), content entity data (S2), peer list (S3), normal holding instruction list (S4), priority holding instruction list (S5), and unrequestable peer list (S6). To do.

  The content information (S1) is information indicating a configuration of entity data of each content such as a moving image distributed by the distribution server. The substance data of each content is subdivided into data of a delivery unit called a plurality of data blocks, and the content information (S1) indicates configuration information of the data block. The content information (S1) includes a content ID and each data block ID corresponding to each content.

  The content entity data (S2) is an entity data group of streaming content such as a moving image to be viewed, and is an aggregate of data blocks. The peer list (S3) is information indicating which peer holds which data block corresponding to each content. In the peer list (S3), peer identification information (IP address and port number) and data block identification information (held data block ID) held in the peer are stored in association with each other.

  The normal holding instruction list (S4) stores the data block ID of the data block instructing the client to hold. It is used to instruct a client that has made a content distribution request to retain a part of the distributed data block so that the client functions as a peer. Hereinafter, the normal holding instruction list is also simply referred to as a normal list for the sake of brevity.

  Similar to the normal holding instruction list (S4), the priority holding instruction list (S5) stores the data block ID of the data block instructing the client to hold. However, the data block ID instructing to preferentially hold the data block ID stored in the normal holding instruction list (S4) is stored. Hereinafter, the priority holding instruction list is also simply referred to as a priority list for the sake of simplicity.

  In response to a data block distribution request from the client to the peer, the request-impossible peer list (S6) stores the data block ID and the IP address of the peer that cannot be distributed from the peer. The request impossible peer list (S6) is notified from the client to the distribution server. Hereinafter, the unrequired peer list is also referred to as a request NG peer list for the sake of simplicity.

  FIG. 3 shows information held by the client that has requested the content viewing. In the client that has requested the content viewing, the content information (C1), the requested peer candidate list (C2), the retained data block ID list (C3), the actual data (C4) of the retained data block, and the unrequired peer list (C5) ).

  The content information (C1) is acquired from the distribution server as a response to the content viewing request. As the content information (C1), content information of only the content requested to be viewed by the client is acquired from the content information (S1) of a plurality of contents held in the distribution server.

  The request destination peer candidate list (C2) stores information indicating peers that hold data blocks constituting entity data of content requested to be viewed. For each data block, the data block ID and the IP address and port number of one or more peers holding the data block are stored. These pieces of information are generated by the distribution server and notified to the client who requested viewing.

  The retained data block ID list (C3) stores the content ID and data block ID of the data block retained by the client. The entity data (C4) of the retained data block is the entity data of the data block that is instructed to be retained from the distribution server and retained by the client. In response to a data block distribution request from the client to the peer, the request-disabled peer list (C5) stores the data block ID and the IP address of the peer that cannot be distributed from the peer.

  A functional block configuration example of the distribution server is shown in FIG. In FIG. 4, a distribution content registration receiving unit 4-1 receives a registration request for content to be distributed from a distribution server. Based on the content registration request, the distribution content registration processing unit 4-2 generates content information together with the content entity data, and stores and manages the content information.

  The client request analysis control unit 4-3 analyzes a request such as a content viewing request from the client, and each function of the peer list management unit 4-5, the distribution content state management unit 4-6, and the transmission signal control unit 4-7 Request processing to the department. The reception signal analysis unit 4-4 receives and analyzes a signal from the client and makes a processing request to the client request analysis control unit 4-3.

  The peer list management unit 4-5 updates the peer list (S3) based on the content viewing completion notification from the client. Further, when there is a content viewing request from the client, the request destination peer candidate list (C2) to be returned to the request source client is edited and generated.

  The distribution content state management unit 4-6 manages the update of the contents of the normal holding instruction list (S4) or the priority holding instruction list (S5) when receiving a content viewing request or a transmission request for a certain data block from the client. Do. The transmission signal control unit 4-7 controls a signal to be transmitted to the client. The data block transmission control unit 4-8 performs transmission control of the actual data of the data block based on the data block transmission request from the client.

  An example of the functional block configuration of the client is shown in FIG. In FIG. 5, a user interface unit 5-1 receives and processes a request from a content viewing user who uses a client function. The request destination peer candidate list management unit 5-2 manages the request destination peer candidate list (C2) distributed from the distribution server.

  The distribution content acquisition control unit 5-3 instructs the viewing request to the distribution server in order to acquire the content requested by the content viewing user, and receives various information (content information (C1), request destination) returned from the distribution server. The acquisition of the peer candidate list (C2), the retained data block ID list (C3), etc.) is controlled.

  The data block acquisition control unit 5-4 refers to the request destination peer candidate list (C2) and performs acquisition control of data blocks (streaming data) from each peer stored in the request destination peer candidate list (C2). . The data block management unit 5-5 manages the distributed data block (streaming data).

  The data block transmission control unit 5-6 performs data block distribution control in response to a data block distribution request from another client. The signal reception analysis unit 5-7 receives and analyzes a response from the distribution server to the viewing request, a data block transfer request from another client, and the like, and the distribution content acquisition control unit 5-3 and the data block acquisition control unit 5 -4 or a processing request to the functional unit of the data block transmission control unit 5-6.

  The transmission signal control unit 5-8 controls transmission of signals to the distribution server and other clients. The content reproduction unit 5-9 reproduces the content based on the acquired data block (streaming data).

An example of the streaming distribution operation will be described below.
[Peer environment surrounding client and distribution server]
In a streaming distribution service using peer-to-peer (P2P) communication, the status of peers surrounding a client and a distribution server changes from time to time from the start of distribution service provision. The situation of this change is classified into two patterns, a peer environment expansion period and a peer environment maturity period.

[Peer environment expansion period]
In the peer environment expansion period, there is not yet a sufficient number of peers that can deliver data blocks of content in response to content viewing requests sent by each client. This situation occurs immediately after the distribution server starts the content distribution service.

[Peer environment maturity]
A sufficient number of peers capable of delivering content data blocks are available for content viewing requests sent by each client. A client requesting content viewing can receive distribution of each data block of content from any peer, and the streaming distribution service is maintained even if the distribution server does not directly distribute the content.

[Migration of peer environment]
The client joins the peer after using the streaming distribution service. As such peers increase in time series, the transition from the peer environment expansion period to the peer environment maturity period will begin. On the other hand, once a client becomes a peer, it is possible to delete the retained data block at any time. When the data block of the old content is deleted, the total number of peers that can be distributed decreases. Transition from peer maturity period to peer environment expansion period.

  Throughout the period in which the streaming distribution service is provided, the peer environment goes back and forth between two situation patterns: a peer environment expansion period and a peer environment maturity period. Hereinafter, a peer that holds a data block and can deliver the data block is also referred to as an active peer, and a peer that does not hold a data block is also referred to as a non-active peer.

[Processing of distribution server for content viewing request]
Processing of the distribution server in response to a content viewing request from the client will be described with reference to FIG. Here, a case where a distribution request to a peer is possible will be described. The content distribution service is started when the client 11 who desires the content distribution service transmits to the distribution server 10 the content viewing request (6-1) specifying the content desired to be viewed. The distribution server 10 creates a requested peer candidate list (C2) and a retained data block ID list (C3) used by the client 11 (6-2, 6-3).

[Generation of Requested Peer Candidate List (C2)]
The distribution server 10 holds content information (S1) of the content ID included in the content viewing request (6-1) and a peer list (S3) of the content ID. The content information (S1) indicates the configuration information of the entity data (S2) of the content specified by the content ID, and the client 11 collects the data block of the entity data (S2) from each peer later, and re-enters the content. Used to configure.

  In the peer list (S3), for each content ID, the data block ID of the data block held by each peer is associated with the IP address of the peer. These are generated and held by the distribution server 10 based on the information of the client (peer) who has used the content distribution service in the past.

  The distribution server 10 refers to the content information (S1) and the peer list (S3) based on the content ID included in the content viewing request (6-1), and requests destination peer candidate list used by the client 11 (C2) is generated. The requested peer candidate list (C2) is a list of peer candidates that deliver data blocks of content requested by the client 11. The requested peer candidate list (C2) is generated by the flow process of FIG. Based on the requested peer candidate list (C2), the client 11 inquires and collects the distribution of each data block from each peer.

[Generation of retained data block ID list (C3)]
The client 11 itself becomes one of the peers after the use of the distribution service is completed. At this time, a partial data block of the content is held, but the distribution server 10 designates which data block is held.

  The distribution server 10 uses the content information (S1) and the normal holding instruction list (S4) or the priority holding instruction list (S5) based on the content ID included in the content viewing request (6-1), and holds the stored data. A block ID list (C3) is generated. The retained data block ID list (C3) is generated by the flow process of FIG.

[Returning content information and generation information to the client]
The distribution server 10 returns a response (6-4) of the content viewing request (6-1) to the client 11. This response (6-4) includes a requested peer candidate list (C2), content information (C1), and a retained data block ID list (C3).

  In the operation example shown in FIG. 6, the data block ID “1” is extracted from the data block IDs “1” to “4” registered in the normal holding instruction list (S4), and the holding data block ID list (C3). In the example shown in FIG. As a result, the data block ID “1” is erased from the normal holding instruction list (S4).

[Data block collection processing at the client]
The client 11 holds the information received from the distribution server 10 (requested peer candidate list (C2), content information (C1) and holding data block ID list (C3)) (6-5), and based on the information. In addition, by the flow process shown in FIG. 11, a process of acquiring a data block and reconfiguring the streaming so that it can be viewed is performed.

  The operation in the client 11 will be described below with reference to FIG. The client 11 obtains a data block ID constituting the content from the content information (C1). From the requested peer candidate list (C2), information on candidate peers requesting distribution of the data block with the data block ID is obtained (6-6).

  First, a streaming viewing request (6-7) is transmitted to the peer 21 which is one of the peers holding the data block ID “1”. Here, it is assumed that the peer environment is mature, and it is assumed that the peer 21 is an active peer holding a data block with the data block ID “1”. The peer 21 extracts the data block having the data block ID “1” held by itself (6-8), and distributes it to the client 11 instead of the distribution server 10 (6-9).

  The client 11 determines whether the data block ID of the distributed data block matches the data block ID set in the retained data block ID list (C3). If the data block ID matches, the client 11 selects the data block of the data block ID. Hold (6-10).

Similarly, a streaming viewing request (6-11) is transmitted to the peer 22 holding the data block ID “2”. The peer 22 extracts the data block with the data block ID “2” held by the peer 22 (6-12) and distributes it to the client 11 instead of the distribution server 10 (6-13).
The above process is repeated for the number of data blocks. In the period for executing this process, the client 11 holds the data block designated by the held data block ID list (C3). After the content viewing is completed, the client 11 transmits a completion notification (6-14) to the distribution server 10.

[Processing of distribution server for completion notification from client]
The completion notification (6-14) includes the content ID, the IP address of the client 11, the port number, and the retained data block ID list (C3). Based on the completion notification (6-14), the distribution server 10 adds information on the client (peer) 11 to the end of the peer list (S3), and updates the peer list (S3) (6-15). That is, the more the time is registered behind the peer list (S3), the newer the addition time becomes. This operation is performed by the flow process shown in FIG.

[Operation of peer streaming data block]
The streaming viewing request (6-7, 6-11) transmitted from the client 11 includes a content ID and a data block ID. Each of the peers 21 and 22 inputs the requested content ID and data block ID, and checks whether there is a data block held by the peer.

  Here, it is assumed that the peer environment is mature, and the peers 21 and 22 hold the data block IDs “1” and “2” requested by the client 11. The peers 21 and 22 distribute the data block held by the peers 21 and 22 to the client 11 instead of the distribution server 10. This operation is performed by the flow process shown in FIG.

  Next, a sequence in a case where a response of “NG” is returned in response to the distribution request to the peer will be described with reference to FIG.

[Processing of distribution server in response to content viewing request from client]
The client 12 who desires to use the content distribution service transmits a content viewing request (7-1) to the distribution server 10. The distribution server 10 creates a requested peer candidate list (C2) and a retained data block ID list (C3) used by the client 12 (7-2, 7-3).

[Generation of retained data block ID list (C3)]
[Generation of Requested Peer Candidate List (C2)]
The creation (7-2, 7-3) of the requested peer candidate list (C2) and the retained data block ID list (C3) is the same as the requested peer candidate list (C2) and the retained data block described with reference to FIG. This is the same as the creation (6-2, 6-3) of the ID list (C3).

[Returning content information and generation information to the client]
The distribution server 10 returns a response (7-4) to the content viewing request (7-1) to the client 12. This response (7-4) includes a requested peer candidate list (C2), content information (C1), and a retained data block ID list (C3).

  In the operation example shown in FIG. 7, the data block ID “2” is extracted from the data block IDs “2” to “4” registered in the normal holding instruction list (S4), and the holding data block ID list (C3). It shows an example of being set to and returned to the client 12. As a result, the data block ID “2” is erased from the normal holding instruction list (S4).

[Data block collection processing at the client]
Based on the information received from the distribution server 10 (requested peer candidate list (C2), content information (C1), and retained data block ID list (C3)), the client 12 performs the data block by the flow process shown in FIG. Is acquired, and processing for reconfiguring the streaming so that it can be viewed is performed.

  The operation in the client 12 will be described below with reference to FIG. The client 12 obtains a data block ID constituting the content from the content information (C1). From the request destination peer candidate list (C2), information on candidate peers that request distribution of the data block with the data block ID is obtained.

  Here, a streaming viewing request (7-5) is transmitted to the peer 23 which is one of the peers holding the data block “4”. Here, it is assumed that it is a peer environment expansion period, and it is assumed that the peer 23 is a non-active peer that does not hold the data block with the data block ID “4” requested by the client 12.

  The peer 23 returns a response indicating that the distribution is impossible (request NG) to the client 12 (7-6). Upon receiving a response indicating that the delivery is not possible (request NG) from the peer 23, the client 12 recognizes that the data block cannot be obtained from the peer 23, and information on the next candidate peer 24 from the requested peer candidate list (C2). Get. At this time, since the peer 23 is a peer that cannot be requested, the client 12 registers and updates the peer 23 in the request impossible peer list (C5) (7-7).

  The client 12 transmits a streaming viewing request (7-8) to the next candidate peer 24. Again, since the peer environment expansion period is assumed, it is assumed that the peer 24 is a non-active peer that does not hold the data block with the data block ID “4”. The peer 24 also returns a non-delivery (request NG) response (7-9) to the client 12. At this time, since the peer 24 is a request impossible peer, the client 12 registers the peer 24 in the request impossible peer list (C5) and updates it (7-10).

  When the above process is repeated as many times as the number of requested peer candidates, and when it is finally recognized that the data block ID “4” cannot be obtained from the peer, the client 12 sends a distribution request for the data block to the distribution server 10. A streaming viewing request (7-11) is transmitted.

  The distribution server 10 can always distribute the requested data block to the client 12. Here, the streaming viewing request (7-11) from the client 12 includes a request-disabled peer list (C5) in which information on the unrequestable peers 23 and 24 is set.

  The distribution server 10 updates its request-disabled peer list (S6) with the request-disabled peer list (C5) received from the client 12. The distribution server 10 recognizes that the data block ID “4” is not held by the peer or that there are not enough active peers on the network, and thereafter holds the data block of the data block ID “4”. Initiate operation to instruct to increase peers.

  Specifically, the operation performed at this timing is to delete the non-requestable peers 23 and 24 from the peer list (S3) (7-12) and register the data block ID “4” in the priority holding instruction list (S5) ( 7-13). Then, the data block with the data block ID “4” is distributed to the client 12 (7-14).

  The client 12 transmits a content viewing request to the peers 21 to 24 or the distribution server 10 until all the data blocks for reconstructing the content entity data (S2) are prepared, and the data block is received as a response. Obtain. In the execution period of the above process, the client 12 holds the actual data of the data block designated by the held data block ID list (C3) from the distribution server. After the content viewing is completed, the client 12 transmits a completion notification to the distribution server 10.

[Operation in which peer returns content viewing request NG to client]
The streaming viewing request (7-5, 7-8) transmitted from the client 12 includes a content ID and a data block ID. Each of the peers 23 and 24 inputs the requested content ID and data block ID, and checks whether or not there is a data block held by the peer.

  Here, it is assumed that the peer environment expansion period is assumed, and the peers 23 and 24 are inactive peers that do not hold the data block ID “4” requested by the client 12. Alternatively, it is assumed that the data block is held, but the data block distribution request cannot be satisfied due to a reason that the data block is being distributed in response to a request from another client. The peers 23 and 24 return a response indicating that delivery is not possible (request NG) to the client 12. This operation is performed by the flow process shown in FIG.

[Operation of distribution server streaming data block to client]
The streaming viewing request (7-11) transmitted from the client 12 to the distribution server 10 includes a content ID and a data block ID, and a request impossible peer list (C5) in which the distribution request impossible peer information is set. ) Is included. The own request impossible peer list (S6) is updated by this request impossible peer list (C5).

  The distribution server 10 distributes the requested data block to the client 12. In addition, the distribution server 10 deletes information about inactive peers from the peer list (S3) based on the unrequestable peer list (S6). Further, regarding the data block ID “4” requested by the client 12, it is assumed that there are not enough active peers, and an instruction is given to increase the number of active peers holding the data block with the data block ID “4”. Specifically, the data block ID “4” is registered in the priority holding instruction list (S5). This operation is performed by the flow process shown in FIG.

  Here, by registering in the priority holding instruction list (S5), the following operation is performed, and the holding data block ID included in the response returned by the distribution server 10 in the processing for the content distribution request from the client next time or later. The data block ID “4” is set in the list (C3). This operation is performed by the flow process shown in FIG.

[Processing of distribution server in response to content viewing request from client]
Processing of the distribution server in response to a content viewing request from the client will be described with reference to FIG. The client 13 who desires to use the content distribution service transmits a content viewing request (8-1) specifying the content desired to be viewed to the distribution server 10. The distribution server 10 creates a requested peer candidate list (C2) and a retained data block ID list (C3) used by the client 13 (8-2, 8-3).

[Generation of retained data block ID list (C3)]
[Generation of Requested Peer Candidate List (C2)]
The request destination peer candidate list (C2) and the retained data block ID list (C3) are created (8-2, 8-3) according to the request destination peer candidate list (C2) and the retained data block described with reference to FIG. This is the same as the creation (6-2, 6-3) of the ID list (C3).

  Here, since the data block ID “4” is registered in the priority holding instruction list (S5), the holding data block ID list (C3) included in the response (8-4) returned by the distribution server 10 Data block ID “4” is set. This setting is prioritized over the data block ID in the normal holding instruction list (S4). When the data block ID “4” is set in the holding data block ID list (C3), the data block ID “4” is deleted from the priority holding instruction list (S5). This generation is performed by the flow process shown in FIG.

[Return content information and generation information to the client]
The distribution server 10 returns a response (8-4) of the content viewing request (8-1) to the client 13. This response (8-4) includes a request destination peer candidate list (C2), content information (C1), and a retained data block ID list (C3) as information.

  At this time, the data block ID “4” specified by the retained data block ID list (C3) is regarded as a shortage of peers that the distribution server 10 retains on the network. With this configuration, data block IDs held by active peers on the network are made uniform, enabling early transition from the peer environment expansion period to the peer environment maturity period, and streaming that does not place a burden on the distribution server Distribution service becomes possible.

[Requested Peer Candidate List (C2) Generation Flow]
The flow process for generating the request destination peer candidate list (C2) will be described with reference to FIG. The distribution server refers to the content distribution information (9-1), and repeatedly performs the following processing on the data block ID from the beginning to the end (9-2). The peer list (S3) is referred to (9-3), and the following process is repeated for the number of requested peer candidates (9-4).

  The peer IP address and port number corresponding to the data block ID are obtained in order from the last peer stored in the peer list (S3) (9-5). It should be noted that in this process, peer candidates are searched in order from the last peer stored in the peer list (S3).

  As information on peers holding data blocks is successively stored in the peer list (S3), more newly registered peers are set as peer candidates for data block distribution. As a result, the possibility that the peer selected as the peer candidate becomes an active peer that can actually deliver the data block increases, and the stream delivery service is smoothly provided.

[Retention Data Block ID Determination Flow]
The flow process for generating the retained data block ID list (C3) will be described with reference to FIG. The distribution server first refers to the priority holding instruction list (S5) (10-1) and determines whether the priority holding instruction list (S5) is empty (10-2). When the priority holding instruction list (S5) is not empty, at least one of the data block IDs stored in the priority holding instruction list (S5) is extracted (10-3), and the data block ID is stored in the client. Set to list (C3) (10-4). At this time, the data block ID extracted from the priority holding instruction list (S5) is deleted from the priority holding instruction list (S5).

  When the priority holding instruction list (S5) is empty, the normal holding instruction list (S4) is referred to (10-5), and it is determined whether the normal holding instruction list (S4) is empty (10-6). . When the normal holding instruction list (S4) is empty, the data block ID of the content is registered in the normal holding instruction list (S4) (10-7).

  Next, at least one data block ID is extracted from the normal holding instruction list (S4) (10-8), and the extracted data block ID is set in the holding data block ID list (C3) to the client (10-9). ). At this time, the data block ID extracted from the normal holding instruction list (S4) is deleted from the normal holding instruction list (S4).

[Streaming view request flow at the client]
A processing flow of a streaming viewing request in the client will be described with reference to FIG. The client refers to the content information (C1) (11-1), and repeats the following processing from the beginning to the end of the data block ID (11-2). First, the request destination peer candidate list (C2) is referred to (11-3), and a connection destination peer candidate corresponding to the data block ID is extracted (11-4).

  A streaming viewing request is transmitted to the retrieved request destination peer candidate (11-5). As a response to the streaming viewing request, it is determined whether the viewing request is permitted (OK) (11-6). If it is not possible (NG), the peer candidate is registered in the request impossible peer list (C5) and updated (11-7). Then, it is determined whether it is the last request destination peer candidate in the request destination peer candidate list (C2) (11-8), and if it is not the last, the next request destination peer candidate is extracted (11-9), and the flow 11-5. Go back to and repeat the same process.

  On the other hand, if it is the last request destination peer candidate, a streaming viewing request is transmitted to the distribution server (11-10). If the viewing request is acceptable (OK) in the processing flow 11-6, or after making a streaming viewing request to the distribution server, whether the retained data block ID matches the data block ID that made the streaming viewing request. Determine (11-11).

  If they match, the client holds the data block together with the streaming viewing process (11-12). On the other hand, if they do not match, only streaming viewing processing is performed (11-13). The above processing is repeated for the data block ID from the beginning to the end (11-14). After completion of these processes, a completion notice is transmitted to the distribution server (11-15).

[Peer list update flow on distribution server]
A processing flow for updating the peer list in the distribution server will be described with reference to FIG. When the distribution server receives the completion notification from the client (12-1), it adds the peer information of the received completion notification to the end of the peer list (S3) (12-2).

[Streaming request reception flow at peer]
A processing flow for receiving a streaming viewing request at the peer will be described with reference to FIG. Upon receiving the streaming viewing request (13-1), the peer acquires the requested content ID and data block ID (13-2).

  Then, the stored data block ID list (C3) is referred to (13-3), and it is determined whether the data block corresponding to the requested content ID and data block ID is stored (13-4). If not held, a request impossible (NG) response is transmitted (13-5). If it is held, the streaming data corresponding to the requested data block ID is extracted (13-6). Then, the streaming data is distributed (13-7).

[Streaming request reception flow in distribution server]
A processing flow for receiving a streaming viewing request in the distribution server will be described with reference to FIG. The distribution server receives the streaming viewing request (14-1), and obtains information of the request impossible (NG) peer list (S6) (14-2).

  The following processing is repeated for the number of peers set in the request impossible (NG) peer list (S6) (14-3). First, referring to the peer list (S3) (14-4), the peers set in the request-impossible (NG) peer list (S6) and the peers whose content ID, data block ID, and IP address match are peer lists ( It is determined whether it exists in S3) (14-5).

  If it exists, the corresponding peer information is deleted from the peer list (S3) (14-6). The above processing is repeated for the number of peers set in the request impossible (NG) peer list (S6) (14-7). Next, it is determined whether a certain number or more of peers are registered in the peer list (S3) (14-8).

  When a predetermined number or more of peers are registered in the peer list (S3), that is, when the peer environment is mature, the data block ID set in the non-requestable (NG) peer list (S6) Register in the list (S5) (14-9).

  When a certain number or more of the peers are not registered in the peer list (S3), that is, when the peer environment expansion period is the initial stage of content distribution, the priority holding instruction list (S5) is not used and the normal holding instruction list (S4) is used. ) Is used, nothing is registered in the priority holding instruction list (S5).

  Next, streaming data corresponding to the requested data block ID is extracted (14-10). Then, the streaming data is distributed to the client that transmitted the streaming viewing request (14-11).

DESCRIPTION OF SYMBOLS 10 Distribution server 11-13 Client 21-25 Peer S1 Content information S2 Content entity data S3 Peer list S4 Normal holding instruction list S5 Priority holding instruction list S6 Request impossible peer list C1 Content information C2 Request destination peer candidate list C3 Holding data block ID list C4 Substantive data of retained data block C5 Peer-unavailable peer list

Claims (7)

The actual data of the content is divided into a plurality of data blocks, each data block is held by the distribution server device and the plurality of peer devices, and each data block of the content is received in response to a content viewing request from the client device. In the streaming distribution method of distributing from each peer device or distribution server device,
The client device makes a delivery request for the data block to each peer device notified from the delivery server device, and when a response indicating that delivery is impossible is returned to the delivery request for the data block, Transmitting a distribution request for the non-distributable data block to the distribution server device;
When the distribution server device receives a data block distribution request from the client device, the distribution server device distributes the data block to the client and instructs the peer device to preferentially hold the data block;
A streaming distribution method comprising:   The distribution server device determines whether or not the number of peer devices holding the data blocks is equal to or greater than a certain number, and if the number is greater than a certain number, instructs the peer device to preferentially retain the undeliverable data blocks. The streaming distribution method according to claim 1, further comprising: The distribution server device instructs the client device to hold a partial data block of the content;
Receiving a notification of the data block holding result from the client device, and registering the client device as a peer device in a peer list indicating a data block holding status of the peer device based on the data block holding result When,
The streaming delivery method according to claim 1 or 2, characterized by comprising: In response to a data block delivery request from the client device to the peer device, when receiving a response indicating that delivery is not possible from the peer device, the identification information of the peer device that is unable to deliver the data block is recorded by the client device. Notifying the server device;
Deleting from the peer list the peer device that is unable to deliver the data block at the distribution server;
The streaming delivery method according to claim 3, further comprising:   4. The method according to claim 3, further comprising: notifying the client device of a newer registered peer device among the peer devices registered in the peer list as a distribution request destination peer candidate having a higher priority. Streaming delivery method described in 1. Holds each data block obtained by dividing the actual content data, and also holds a peer list indicating the identification information of the peer device that holds each data block, and holds the data block in response to a content viewing request from the client device. In the distribution server that notifies the identification information of the peer device
Means for instructing data blocks to be held by the client device when notifying the identification information of the peer device to the client device;
Means for instructing the peer device to preferentially hold the data block while delivering the data block to the client device upon receiving a data block delivery request from the client device;
A distribution server device comprising: In response to a content viewing request, a client that receives identification information of a peer device that holds each data block obtained by dividing the actual data of the content from a distribution server, and transmits a distribution request for each data block to the peer device In the device
Means for recording identification information of the peer device that cannot deliver the data block and notifying the delivery server device when receiving a non-delivery response from the peer device;
Means for holding a data block instructed from the distribution server among data blocks distributed from the distribution server or the peer device;
A client device comprising:

Images