JP2003032300A - Multicast data communication method, multicast data communication system, relay apparatus, relay method, relay program, medium stored with relay program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a multicast data communication system, which is secured to a high degree that the problem of many unproductive tables due to attack by a malicious user being generated on nodes in a network is prevented. SOLUTION: Reception hosts 22-1 trough 22-4 periodically send reception request packets to a transmission host. A relay node 21, upon receiving the reception request packets and then receiving distribution table generating packets or data packets from the transmission host, generates a distribution table for the transmission host, if the table does not exist, and registers the addresses of the respective hosts 22-1 through 22-4, and the arrival time of the reception request packets and sends the reception request packets to the transmission host periodically. Upon receiving the data packet from the transmission host, the node 21 duplicates data packets, to send them only to the reception hosts whose reception request packets registered in the distribution table arrive within a prescribed time, when the data packets arrive.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a multicast data communication method for broadcasting data to a plurality of receiving hosts (receiving devices) on the existing Internet which supports only one-to-one communication (unicast). The present invention relates to a multicast data communication system, a relay device, a relay method, a relay program, and a medium recording the relay program.

[0002]

2. Description of the Related Art Conventionally, a predetermined multicast IP has been used as a method for realizing multicast communication for broadcasting data to a plurality of receiving hosts on the Internet.
There is a method of using an address (IP multicast). In this method, when a sending host (sending device) sends data to a multicast IP address as a destination, a multicast router (relay device) provided on the Internet copies the data as appropriate during delivery, thereby receiving all data. The same data is delivered to the host.

Usually, a data delivery path from a transmission host to a plurality of reception hosts is a tree having the transmission host as a root and the reception host as a leaf. This is called a multicast tree. In IP multicast, a protocol for constructing a multicast tree is DVMRP (Distance-Vec) of RFC1075.
tor Multicast Routing Protocol) and RFC1584
MOSPF (Multicast Open Shortest Path First)
And RFC2362 PIM-SM (Protocol Indepen
dent Multicast-Sparse Mode), etc., as a protocol for managing the operation of each receiving host joining and leaving the tree, RFC1112 IGMP
(Internet Group Management Protocol).

In order to realize the above-mentioned IP multicast, it is necessary that all routers support IP multicast. However, in the present situation where most routers do not support IP multicast, it is difficult to make all routers compatible with IP multicast. In addition, the IP multicast has a problem that the multicast packet cannot be passed to a network that does not support multicast. Furthermore, in order to realize IP multicast, the receiving host must be expanded at the operating system level, and it is not easy to make each host compatible with IP multicast.

The above protocol also has the drawback of not being scalable. That is, in DVMRP, even if there is no receiving host, a multicast tree is constructed up to the router closest to the receiving host and data is distributed. In MOSPF, each relay node needs to hold the topology information of the entire huge multicast tree. In PIM-SM, hosts participating in the multicast tree need to access a specific node called rendezvous point.

Further, since the above protocol needs to guarantee that the multicast IP address is global and unique, the management cost of the address for specifying the multicast tree is high. In addition, the above protocol allows a host that is not a member of the multicast tree to become a sending host, so that a malicious person may send unnecessary traffic to the participants of the multicast tree. Allow the attack.

On the other hand, Japanese Unexamined Patent Publication No. 10-63598 discloses a multicast data communication method using only unicast without using IP multicast. This method is a multicast server (relay node: which receives a reception start request transmitted from a reception host).
The relay device) stores the reception host, and thereafter delivers the multicast data to the reception host until a reception end request is received from the reception host.

However, this method has a problem that the delivery of the multicast data to the receiving host does not stop when the receiving end request from the receiving host is lost during the transmission or when the receiving host hangs up. It was Also, once the delivery route is confirmed by the reception start request,
Even if the relay node closest to the receiving host changes due to the change in the route information of the router, there is a problem that the route for delivering to the receiving host does not change.

FIG. 71 shows an example of a network configuration in which multicast communication is performed. Here, one relay node 1 has four receiving hosts 2-1, 2-2, 2-.
3 and 2-4 are connected via a network.

It is now assumed that a certain sending host (not shown) is connected to the relay node 1 via the network. 10.10.9.8, 10.11.10.9, 10.12.11.10, 10.13.12.1
Four receiving hosts 2-1, 2-2, with address 1
It is assumed that 2-3 and 2-4 are on the side opposite to the transmitting host with respect to the relay node 1.

These four receiving hosts 2-1 to 2-4
Of these, it is assumed that three reception hosts 2-1 to 2-3 having addresses 10.10.9.8, 10.11.10.9, and 10.12.11.10 have transmitted reception request packets. When these arrive at the relay node 1, a table for the transmitting host is created in the relay node 1, and these three receiving hosts 2-1 to 2-3 are registered in this table.

This table indicates that the relay node 1 should duplicate the data packet from the sending host and deliver it to these three receiving hosts. The host registered in the table is called a child of the relay node 1.

An example of this table is shown in FIG. The address of each child is recorded in this table.

When a new table is created, the relay node 1 itself transmits a reception request packet. Here, in order to propagate the reception request packet to the proximity node of the transmission host, a routing tree is determined for each multicast identifier by some means. In this way, the reception request packet eventually arrives at the transmission host.

FIG. 73 shows another example of the network configuration in which the multicast communication is performed.
Seven receiving hosts (hereinafter referred to as clients) 12-1, 1 in one relay node 11-1, 11-2, 11-3
2-2, 12-3, 12-4, 12-5, 12-6, 1
2-7 and one transmission host 13 (hereinafter referred to as a server) are connected via a network.

The process of constructing the multicast tree will be described below.

Now, as shown in FIG. 74, the client 1
It is assumed that 2-1 sends a reception request packet. This time,
A table showing that the client 12-1 is a child is created in the relay node 11-1, and further, as shown in FIG. 75, the reception request packet is sent from the relay node 11-1.

When the reception request packet arrives at the relay node 11-2, a table is similarly generated in the relay node 11-2 and the relay node 11-1 is registered. After that, the reception request packet is transmitted from the relay node 11-2. When this reception request packet arrives at the server 13, the server 13 transmits the data to the relay node 11
-2, it knows that it should be sent and starts sending the data packet.

Thereafter, as shown in FIG. 76, it is assumed that a reception request packet is sent from the client 12-2.
When this reception request packet arrives at the relay node 11-1, since the table already exists, the client 12
-2 is registered. When the client 12-4 further sends a reception request packet, the client 12-4 is registered in the relay node 11-3 and the relay node 11-3 is registered in the relay node 11-2, as shown in FIGS. 77 and 78.
Is registered. Further clients 12-5 and 12-
FIG. 79 shows the situation when 6 has joined the multicast.

In this way, a tree-like delivery route can be created in which the server is the root and the client is the leaf. Such a tree-like delivery route is created for each server. If this tree is distinguished by a symbol called a tree ID (multicast identifier), a table is created for each tree ID in the relay node as shown in FIG.

In each relay node, the data packet sent from the server is duplicated if necessary and then sent to the child registered in the table. Therefore, even when the route from the client to the server and the route from the server to the client are different, the data packet always passes through the relay node in which the table is created.

When these clients stop receiving the data packet, the leaving packet may be sent, and when it arrives at the relay node, the host sending the leaving packet may be deleted from the table. Then, when there are no more children registered in the table, the relay node sends a leave packet. Here, like the reception request packet,
The leaving packet is also propagated to the neighboring node of the sending host by some method. Thus, it is described in Japanese Patent Laid-Open No. 10-63598 that each relay node may repeat similar processing.

[0023]

However, in the above-mentioned communication method, when a client hangs up or is forcibly terminated without issuing a leave packet, this client remains registered in the table of the relay node, There is a problem that data packets from the server continue to be sent to this client.

To prevent this, a timer is set on the relay node, an inquiry is periodically made to the child registered in the table, and if a reply packet is returned from the child, it is considered to be receiving. It is conceivable that the data packet is continuously considered and the transmission of the data packet is continued, and if not, the transmission is stopped.

When an inquiry is made from the parent node to the relay node, a reply packet is sent if the child is registered in the table, and a reply packet is not sent if no child is registered in the table. Alternatively, a leave packet is sent to the parent node. This maintains the tree needed to deliver the data packet only to the clients that return the reply packet.

For example, in the network configuration shown in FIG. 71, the relay node 1 has addresses 10.10.9.8, 10.11.10.
Inquires about the three children (reception hosts) 9 and 10.12.11.10. Since the children of the addresses 10.10.9.8 and 10.11.10.9 are operating normally, the response packet was returned.
It is assumed that the child of 10.12.11.10 did not return a reply packet because it was hung up. At this time, the address 10.12.
It is determined that the data packet does not need to be delivered to the child of 11.10 and is deleted from the table as shown in FIG.

Further, instead of sending the data packet and the inquiry packet separately, the data packet is regarded as an inquiry packet, and the client (or relay node) receives the data packet and returns a reply packet to the server. You may decide to do it.

However, even if these methods are adopted, in order for the client (or the relay node) to be registered in the table of the parent node at the start of reception, it is necessary to output the reception request packet from the client (or the relay node). is there. In a network where the reception request packet may be lost, the reception request packet needs to be repeatedly output until it is registered in the table of the parent node. Then, after registering in the table of the parent node, a reply packet is sent to the data packet. That is, there is a problem that a state transition from a state of actively sending out a packet to a state of passively sending out a packet is required.

As a technique similar to the above-mentioned Japanese Patent Laid-Open No. 10-63598, Hugh. W. Holbrook, David R.
Cheriton, “IP Multicast Channels: EXPRESS Support
forLarge-scale Single-source Applications ”, pp.
65-78, In Proc. Of SIGCOMM, 1999 and Ion Stoica, T.
S. Eugene Ng, Hui Zhang, “REUNITE: A RecursiveUni
cast Approach to Multicast ”, pp. 1644-1653, In Pro
c. of INFOCOM2000 (hereinafter referred to as REUNITE) is available.

The former is an extension of IP multicast
It is called Source-specific multicast (SSM), and the multicast tree is specified by the combination of the source address and the multicast address. In addition, the document REUNIT
E is a multicast technology in the application layer, which is a forwar to the receiving host that first requests.
The multicast tree is determined based on the d-path.
After that, when this receiving host leaves the multicast tree, the multicast tree based on the forward-path to another receiving host is determined, and the configuration of the multicast tree is changed.

However, Japanese Patent Application Laid-Open No. 10-63598, document SSM, and document REUNITE have the following security problems. That is, the sending host or the receiving host sends a packet having a table creation function (for example, the above-described reception request packet) to an appropriate terminal address, so that each node existing on the path from the host to the destination receives the table. Can be created. By utilizing this property, when a malicious user sends a table generation packet to a large number of addresses, a large number of meaningless tables are generated in the nodes in the network. As a result, there is a problem that the load of the node becomes unnecessarily heavy and the performance thereof deteriorates.

An object of the present invention is to provide a multicast data communication method capable of realizing a high level of security without causing a problem that a large number of meaningless tables are generated in a node in a network due to an attack by a malicious user and the load is heavy. It is to provide a multicast data communication system, a relay device, a relay method, a relay program, and a medium recording the relay program.

An object of the present invention is to provide a multicast data communication method, a multicast data communication system, a relay device, a relay method, which can stop the delivery of multicast data when a receiving host fails or a packet loss occurs on a transmission line. It is to provide a relay program and a medium in which the relay program is recorded.

Another object of the present invention is to provide a multicast data communication method and a multicast data communication method capable of changing the delivery route of multicast data when the nearest relay node to the receiving host changes or the load state of the relay node changes. It is to provide a system, a relay device, a relay method, a relay program, and a medium recording the relay program.

Still another object of the present invention is to provide a multicast data communication method, a multicast data communication system, a relay device, which does not require a state transition from a state of actively sending out a packet to a state of passively sending out a packet at a receiving host. It is to provide a relay method, a relay program, and a medium in which the relay program is recorded.

Other objects of the present invention will be apparent from the description, drawings, and particularly the description of each claim.

[0037]

According to the present invention, in order to achieve the above object, a receiving host periodically issues a receiving request, and a transmitting host or a relay node receives a receiving request within a predetermined time interval. The method of stopping the delivery of multicast data to the host (hereinafter called the keep alive method) is used.

Specifically, the invention according to claim 1 uses a network capable of unicast communication and transmits data via a relay device provided on a unicast delivery path from a transmitter to a plurality of receivers. In the multicast data communication system, wherein the plurality of receiving devices comprises means for sending a reception request message addressed to the transmitting device at time intervals smaller than a predetermined value, An apparatus determines whether or not the receiving-apparatus-side adjacent node continues to request the reception of data by determining whether the reception interval of the reception request message is less than a predetermined time interval; and the receiving-apparatus side. Means for sending the data to the receiving device when it is determined that the adjacent node continues to request the reception of the data. The relay device, when receiving the data or the distribution table generation packet from the transmission device-side adjacent node after receiving the reception request message from the reception device-side adjacent node, selects the reception device-side adjacent node to which the data should be delivered. Means for generating a distribution table for registration,
Depending on the means for registering the receiving device side adjacent node that has transmitted the reception request message after generating the distribution table in the distribution table, and whether the reception interval of the reception request message is less than a predetermined time interval. Means for determining whether the receiving device side adjacent node continues to request the reception of the data, and a predetermined value when it is determined that the receiving device side adjacent node continues to request the reception of the data A reception request message addressed to the transmission device is sent at smaller time intervals, and the reception device side adjacent node is registered in the distribution table by duplicating the data sent from the transmission device side adjacent node. And a means for delivering to a multicast data communication system.

The invention according to claim 2 is the multicast data communication system according to claim 1, wherein the reception request message reaches the relay device or the transmission device which has received the reception request message from the reception device. The receiving device includes route information indicating a route, the information indicating itself is included in the reception request message as the route information, and is transmitted, and the transmitting device is an adjacent node on the receiving device side that has transmitted the reception request message. Is not registered in the distribution table, the distribution table generation packet including the route information in the reception request message is generated, and the distribution table generation packet is transmitted to the receiving device according to the route information, The relay device includes means for determining whether or not the distribution table is generated, and when the distribution table is generated, If the receiving device side adjacent node that has sent the reception request message is not registered in the distribution table, a distribution table generation packet including the route information in the reception request message is generated, and the distribution table generation packet is generated according to the route information. To the receiving device, and when the distribution table is not generated, a new information indicating itself is added to the route information in the reception request message sent from the receiving device side adjacent node. When the distribution table generation packet is transmitted from an adjacent node on the transmission device side, a reception request message including the new path information is transmitted to the transmission device as a destination, and the distribution table generation packet is transmitted. The multicast data that transfers the distribution table generation packet to the adjacent node on the receiving device side and generates the distribution table according to the route information in the It is a communication system.

The invention according to claim 3 is the multicast data communication system according to claim 1, wherein the relay device further comprises means for judging whether or not the distribution table is generated, and the distribution table is generated. If not, the source of the reception request message sent from the adjacent node on the receiving device side is changed to its own relay device and transferred to the adjacent node on the transmitting device side, and the data is transmitted from the adjacent node on the transmitting device side. When the distribution table is generated, the distribution table is generated and the data is discarded. When the distribution table is generated, the distribution device is set to the adjacent node on the receiving device side that has transmitted the reception request message. Is a multicast data communication system to be registered in. In addition, claim 4
According to the described invention, in the multicast data communication system according to claim 2 or 3, the relay device determines whether or not the relay device is in a high load state exceeding a predetermined load, and determines that the relay device is in the high load state. For the receiving device side adjacent node that is not registered in the distribution table while being transmitted, the transmission is performed without registration in the distribution table when the reception request message is sent from the receiving device side adjacent node. A multicast data communication system further comprising means for transferring the reception request message to a device as a destination. Further, the invention according to claim 5 is the multicast data communication system according to claim 2 or 3, wherein the reception request message is between a preference of each user corresponding to each of the receiving devices and a conversion cost for the data. The relay device stores preference information indicating the correlation of the above, and the conversion information necessary for converting the data distributed to each of the receiving devices is stored in advance in a plurality of required categories. Based on the conversion information storage means and the preference information in the reception request message sent from the reception device side adjacent node, the conversion information category to be adopted for the reception device side adjacent node is set to the reception device side adjacent node. The conversion instruction table defined in advance for each node is defined, and the conversion instruction table is referred to in accordance with the data transmitted from the transmitter-side adjacent node. A category of the conversion information to be adopted for the receiving device side adjacent node is selected, the conversion information stored in the conversion information storage means corresponding to the selected category is read, and the read conversion information is read. Is a multicast data communication system further comprising conversion means for converting the data by using the above and transmission means for transmitting the data converted by the conversion means to the receiving device side adjacent nodes.

Further, in the invention described in claim 6, in the multicast data communication system according to claim 5, the conversion means, in addition to the preference information, information indicating the load state of each relay device itself or each of the above-mentioned preference information. It is a multicast data communication system that selects the category based on a load state of a communication link between relay devices. Further, the invention according to claim 7 is, in the multicast data communication system according to claim 5, preference information extraction means for extracting the preference information from the reception request message transmitted from the adjacent node on the receiving device side, and extracted. The preference information storage means for storing the preference information, and the preference information stored in the preference information storage means are collectively subjected to a predetermined calculation to generate new preference information, and the new preference information is used to generate the new preference information. The multicast data communication system further includes a preference information totaling unit that updates the conversion instruction table and a unit that sends the new preference information to the adjacent node on the transmitter side.

The invention according to claim 8 uses a network capable of unicast communication and broadcasts data via a relay device provided on a unicast delivery path from a transmitter to a plurality of receivers. In the multicast data communication method for transmitting, the plurality of receiving devices send out a reception request message addressed to the transmitting device at time intervals smaller than a predetermined value, and the relay device includes a receiving device side. When the data or distribution table generation packet is received from the transmission device side adjacent node after receiving the reception request message from the adjacent node, a distribution table for registering the reception device side adjacent node to which the data is to be distributed is generated. However, the transmission device determines whether the reception interval of the reception request message is less than a predetermined time interval. Judging whether or not the contact node continues to request the reception of data, and sending the data to the adjacent node on the receiving device side that continues to request the reception of the data, and continuously requesting the reception of the data. The distribution of the data is stopped to the receiving device side adjacent node that stopped the distribution, and the relay device distributes the receiving device side adjacent node that has transmitted the reception request message after the distribution table is generated. Registered in the table, the relay device determines whether the reception device side adjacent node continues to request the reception of the data by whether the reception interval of the reception request message is less than a predetermined time interval,
When the receiving device side adjacent node determines that it continues to request the reception of the data, it transmits a reception request message addressed to the transmitting device at every time interval smaller than a predetermined value, and transmits the reception request message. It is a multicast data communication method for duplicating the data sent from the device-side adjacent node and delivering it to the receiving device-side adjacent node registered in the distribution table.

Further, in the invention according to claim 9, in the multicast data communication method according to claim 8, the receiving device includes information indicating itself in the reception request message as route information and sends the information, and the transmitting device If the receiving device side adjacent node that has transmitted the reception request message is not registered in the distribution table, generates the distribution table generation packet including the path information in the reception request message, and according to the path information, A relay device that sends a distribution table generation packet to the receiving device and is on the path from the receiving device to the relay device for which the distribution table has been generated and for which the distribution table has not been generated is adjacent to the receiving device. New route information is generated by adding information indicating itself to the route information in the reception request message sent from the node, and the new route information is generated. When a reception request message including route information is sent to the transmission device as a destination and the reception request message reaches the transmission device or the relay device in which the distribution table is generated, the transmission device or the relay device If the receiving device side adjacent node that has transmitted the reception request message is not registered in the distribution table, a distribution table generation packet including the path information in the reception request message is generated, and the distribution table is generated according to the path information. The distribution table generation packet is transmitted to the reception device, and the distribution table generation packet is generated in the relay device existing on the path from the relay device in which the distribution table is generated to the reception device and in which the distribution table is not generated. When the distribution table generation packet is sent from the adjacent node on the transmission device side, the distribution table generation packet is transmitted to the reception device side adjacent node according to the route information in the distribution table generation packet. A multicast data communication method for generating the delivery table and transfers to the over-de.

Further, the invention according to claim 10 is the invention according to claim 8.
In the multicast data communication method described, the relay device existing on the path from the receiving device to the relay device in which the distribution table is generated, and the distribution table is not generated,
To the relay device in which the reception request message sent from the receiving device side adjacent node is changed to its own relay device and transferred to the transmitting device side adjacent node, and the reception request message is generated in the distribution table. When the relay device arrives, the relay device registers in the distribution table the receiving device side adjacent node that has transmitted the reception request message, and also sends the data to the receiving device side adjacent node to generate the distribution table. The relay device that exists on the path from the relay device to the receiving device and has not generated the distribution table generates the distribution table by receiving the data sent from the adjacent node on the transmission device side. This is a multicast data communication method for discarding the data. In addition, claim 11
The described invention is a relay device in a multicast data communication system that broadcasts data from a transmitting device to a plurality of receiving devices, using a network capable of unicast communication, wherein the transmitting device provides the plurality of receiving devices. Is provided on a unicast delivery route to the transmitting device after receiving a reception request message from the receiving device-side adjacent node, the receiving device sending out the transmitting device to the transmitting device at a time interval smaller than a predetermined value. Means for generating a distribution table for registering the receiving device side adjacent node to which the data is to be delivered, when the data or the distribution table generation packet is received from the adjacent node on the side, and the reception request after generating the distribution table. Means for registering an adjacent node on the receiving device side that has sent a message in the distribution table, and the reception request message Means for determining whether the receiving-apparatus-side adjacent node continues to request the reception of the data depending on whether the reception interval is less than a predetermined time interval, and the receiving-apparatus-side adjacent node receives the data. When it is determined that the request is being continued, the reception request message addressed to the transmission device is transmitted at each time interval smaller than a predetermined value, and the data transmitted from the transmission device side adjacent node is transmitted. And a means for copying and delivering to the receiving device side adjacent node registered in the distribution table.

The invention of claim 12 is the same as that of claim 1.
1. The relay device according to 1, wherein the reception request message includes route information indicating a route from the reception device to the relay device or the transmission device which has received the reception request message, and the relay device stores the distribution table. A means for determining whether or not it has been generated, and when the distribution table is generated, if the receiving device side adjacent node that has transmitted the reception request message is not registered in the distribution table,
Route information indicating a route from the receiving device to its own relay device is extracted from the reception request message to generate the distribution table generation packet including the route information, and the distribution table generation packet is generated according to the route information. When it is sent to the receiving device and the distribution table is not generated,
The transmission device transmits a reception request message including new route information by adding information indicating itself to the route information in the reception request message sent from the receiving device side adjacent node and including the new route information. To the destination,
A relay which, when the distribution table generation packet is sent from the adjacent node on the transmitting device side, transfers the distribution table generation packet to the adjacent node on the receiving device side in accordance with the route information in the distribution table generating packet, and also generates the distribution table. It is a device.
Further, the invention according to claim 13 is the relay device according to claim 11, further comprising means for determining whether or not the distribution table is generated, and when the distribution table is not generated, the receiving device side adjacent node Change the transmission source of the received reception request message to its own relay device and transfer it to the adjacent node on the transmitting device side, and generate the distribution table when the data is sent from the adjacent node on the transmitting device side. Then, the data is discarded, and when the distribution table is generated, it is a relay device that registers in the distribution table the receiving device side adjacent node that has transmitted the reception request message.

The invention of claim 14 is the same as claim 1
In the relay device according to 2 or 13, means for determining whether or not the relay device itself is in a high load state exceeding a predetermined load, and reception that is not registered in the distribution table while it is determined that the relay device is in the high load state. Regarding the device-side adjacent node, means for transferring the reception request message received with the transmission device as the destination without registration in the distribution table when the reception request message is sent from the reception-device-side adjacent node The relay device further comprises: According to the invention of claim 15, in the relay device according to claim 12 or 13, conversion information necessary for converting the data distributed to each of the receiving devices is classified into a plurality of required categories. Between the conversion information storage means to be stored in advance, and the preference of each user corresponding to each of the receiving devices included in the reception request message transmitted from the receiving device side adjacent node and the conversion cost for the data Based on the preference information representing the correlation between the conversion device, the conversion instruction table in which the categories of the conversion information to be adopted for the receiving device side adjacent node are defined in advance for each of the receiving device side adjacent nodes, and the transmitting device side adjacent node According to the transmitted data, the conversion instruction table is referred to, the category of the conversion information to be adopted for each adjacent node on the receiving device side is selected, and the selection is performed. The conversion information stored in the conversion information storage means corresponding to the selected category and converting the data by using the read conversion information; The relay device further comprises a transmitting unit that transmits the converted data to the receiving-device-side adjacent nodes.

The invention of claim 16 is the same as claim 1
In the relay device according to 5, the conversion unit selects the category based on the preference information, information indicating a load state of each relay device itself, or a load state of a communication link between the relay devices. It is a relay device to perform. Also,
According to a seventeenth aspect of the present invention, in the relay apparatus according to the fifteenth aspect, preference information extracting means for extracting the preference information from the reception request message transferred from the receiving device side adjacent node, and the extracted preference information. And a preference information storage unit for storing the preference information stored in the preference information storage unit to collectively perform a predetermined calculation to generate new preference information, and generate the conversion instruction table by the new preference information. The relay device further includes a preference information totaling unit for updating and a unit for transmitting the new preference information to the adjacent node on the transmitting device side. Further, the invention according to claim 18 uses a network capable of unicast communication, and when data is broadcast from a transmitter to a plurality of receivers, the unicast from the transmitter to the plurality of receivers is performed. A relay method for relaying the data by a relay device provided on a delivery path, wherein a reception request message is sent by the plurality of receiving devices destined to the transmitting device at a time interval smaller than a predetermined value. When receiving and receiving the data or the distribution table generation packet from the transmitting device side adjacent node after receiving the reception request message from the receiving device side adjacent node, the receiving device side adjacent node to which the data is to be delivered is registered. For generating the distribution table for sending the reception request message after the distribution table is generated. Is registered in the distribution table, and it is determined whether or not the receiving-apparatus-side adjacent node continues to request reception of the data depending on whether the reception interval of the reception request message is less than a predetermined time interval, and the reception When it is determined that the device-side adjacent node continues to request the reception of the data, the reception device sends a reception request message addressed to the transmission device at time intervals smaller than a predetermined value, and the transmission device side It is a relay method of copying the data sent from the adjacent node and delivering the data to the receiving device side adjacent node registered in the distribution table.

The invention described in claim 19 is the same as claim 1.
In the relay method described in 8, until the distribution table is generated, new route information is generated by adding information indicating itself to the route information in the reception request message sent from the receiving device side adjacent node. Then, the reception request message including the new route information is sent to the transmission device as a destination, and then the distribution table generation packet generated by the transmission device or the relay device that generated the distribution table is transmitted to the transmission device side adjacent node. When transmitted from the distribution table generation packet according to the route information in the distribution table generation packet to the receiving device side adjacent node while generating the distribution table,
After generating the distribution table, when the reception request message is sent from the receiving device side adjacent node, if the receiving device side adjacent node is not registered in the distribution table, the receiving device relays itself. A relay method for extracting route information indicating a route to a device from the reception request message, generating the distribution table generation packet including the route information, and transmitting the distribution table generation packet to the reception device according to the route information. Is.

The invention according to claim 20 is the same as claim 1.
In the relay method described in No. 8, until the distribution table is generated, the source of the reception request message sent from the receiving device side adjacent node is changed to its own relay device and transferred to the transmitting device side adjacent node. After that, when the data is sent from the transmitter-side adjacent node, the distribution table is generated, the data is discarded, and after the distribution table is generated, the sender that has transmitted the reception request message. Is a relay method of registering the receiving device side adjacent node in the distribution table and transmitting the data to the receiving device side adjacent node.

According to a twenty-first aspect of the present invention, a network capable of unicast communication is used, and when data is broadcast from a transmitting device to a plurality of receiving devices, the transmitting device transmits the data to the plurality of receiving devices. A computer-readable medium recording a relay program for relaying the data on a unicast delivery route to
The relay program receives a reception request message sent from the plurality of receiving devices to the transmission device at a time interval smaller than a predetermined value, and the reception request message from the receiving device side adjacent node. When receiving the data or the distribution table generation packet from the transmission device side adjacent node after receiving, generating a distribution table for registering the reception device side adjacent node to which the data is to be distributed, and the distribution table A step of registering the receiving device side adjacent node that has transmitted the reception request message after being generated in the distribution table, and a reception device depending on whether the reception interval of the reception request message is less than a predetermined time interval. Determining whether the adjacent node on the side continues to request the reception of the data; When the adjacent node on the side determines that it continues to request the reception of the data, it sends out a reception request message addressed to the transmitting device at each time interval smaller than a predetermined value, and the adjacent device on the transmitting device side. And a step of copying the data sent from the node and delivering the data to an adjacent node on the receiving device side registered in the distribution table.

According to a twenty-second aspect of the present invention, a network capable of unicast communication is used, and when data is broadcast from a transmitter to a plurality of receivers, the transmitter transmits the data to the plurality of receivers. A relay program for relaying the data on a unicast delivery path that reaches, wherein the plurality of receiving devices receives a reception request message transmitted to the transmitting device at a time interval smaller than a predetermined value. Registering the receiving device side adjacent node to which the data is to be delivered when the data or the distribution table generation packet is received from the transmitting device side adjacent node after receiving the reception request message from the receiving device side adjacent node. Generating a delivery table for transmitting the reception request message after the delivery table is generated. The receiving device side adjacent node requests reception of the data according to the step of registering the receiving device side adjacent node in the distribution table and whether the reception interval of the reception request message is less than a predetermined time interval. And a step of determining whether or not continuing, and when it is determined that the receiving device side adjacent node continues to request reception of the data, the transmitting device is set as a destination at time intervals smaller than a predetermined value. A relay for causing a computer to execute the step of transmitting a reception request message and copying the data transmitted from the adjacent node on the transmitting device side and delivering the data to the adjacent node on the receiving device side registered in the distribution table. It is a program.

[0052]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiments of the present invention will be described below with reference to the drawings.

First, an example of an area to which each embodiment of the present invention is applied will be described, but the present invention is not limited to application to such an area. Each embodiment of the present invention is preferably applied to, for example, personal broadcaster type stream distribution for the masses in a wide area network. The personal broadcast station type stream distribution referred to here means a form of stream distribution in which a terminal owned by an individual is a source of the stream. The terminal possessed by an individual may be either a fixed terminal or a mobile terminal, but when the terminal is a mobile terminal, the source of the stream changes from moment to moment. Also, in the case of personal broadcast station type stream distribution, it is considered that the stream transmission period is often relatively short. It can be said that it is difficult to systematically build a multicast tree in advance due to the characteristics of such personal broadcaster type stream distribution.

Then, in order to realize the multicast communication in consideration of the above application areas, it is necessary to satisfy the following requirements. First, since both the sender and the receiver are masses (general users), a protocol capable of ensuring a high degree of safety is required from the viewpoint of security. In addition, since it is impossible to predict where the stream will be delivered from, it is necessary to be able to build a multicast tree on demand. In addition, decentralized control is required to ensure scalability with respect to the number of recipients to which the stream is distributed. Also, considering the application to a wide area network, it is necessary to be able to flexibly deal with route changes.

[Embodiment 1] FIG. 1 shows an example of a network configuration in which multicast communication is performed, and here, an example similar to FIG. 71 taken up in a conventional example is shown. That is, here, one relay node 21 has four reception hosts 22-
1, 22-2, 22-3, 22-4 (address is shown in FIG.
(The same as the above) and a transmission host (not shown) is also connected to the relay node 21 via the network.

Each of the reception hosts 22-1 to 22-4 sends out a reception request packet at time intervals smaller than a predetermined value. When the reception request packet arrives at the relay node 21, the arrival time is recorded in the table of the relay node 21 (hereinafter referred to as the distribution table). The relay node 21 itself in which the child is registered also sends the reception request packet to the sending host at time intervals smaller than a predetermined value. When this reception request packet arrives at the relay node closer to the sending host, the arrival time is recorded. The timing at which the relay node itself sends the reception request packet to the sending host will be described later.

FIG. 2 shows an example of the distribution table of this embodiment, in which the address of each child and the time when the reception request packet from each child arrives at the relay node 21 are recorded for each child.

When the data packet from the transmitting host arrives at this relay node 21, the current time is compared with the reception request packet arrival time for each child recorded in the distribution table, and if the interval is more than a certain value. One child considers it to have timed out and does not send a data packet to that child. At this time, this child is deleted from the distribution table.

For example, FIG. 3 shows the state when the data packet from the transmission host arrives at the relay node 21 at time 10:23:11. Assuming that the timeout time interval is 00:00:10, from FIG.
Only child 3 has timed out. Therefore,
As shown in FIG. 4, this data packet is sent only to the child 1 and the child 2 (reception hosts 22-1 and 22-2). At this time, the child 3 is deleted from the distribution table. The distribution table after the child 3 is deleted is as shown in FIG.

When all the children have timed out, the distribution table itself is deleted. Other methods for deleting the child registered in the distribution table or the distribution table itself are also possible. For example, when a reception request packet arrives, if the deletion operation of the timed-out child is performed on the distribution table of the tree ID corresponding to the reception request packet, the processing amount at the time of transferring the data packet can be reduced. This is useful when transfer rates are important, such as real-time stream data. Also, to ensure that the timed-out child or distribution table is deleted, a method of periodically starting a program that deletes the timed-out child or distribution table may be created in the relay node itself. is there.

The keep alive method not only enhances the resistance against a hang-up or forced termination of a receiving host (hereinafter also referred to as a client), but also dynamically reconstructs a tree according to the load status of a relay node. To

FIG. 6 shows another example of the network configuration in which the multicast communication is carried out, here the same example as FIG. 73 taken up in the conventional example. That is, here, the three relay nodes 31-1, 31-2, and 31-3 have seven reception hosts 32-1, 32-2, 32-3, 32-4, and 32-.
5, 32-6, 32-7 and one transmission host 33 (hereinafter referred to as a server) are connected via a network.

FIG. 7 shows a state similar to that of FIG. 79 in the configuration of FIG. 6, that is, the clients 32-1, 32-2, 32-.
It shows a state in which the client 32-7 newly sends a reception request packet from the state in which 4, 32-5 and 32-6 participate in the multicast. Here, it is assumed that the relay node 31-3 is already in a high load state and cannot afford to increase the number of times the data packet is copied for the client 32-7.

At this time, the relay node 31-3 transfers the reception request packet from the client 32-7 to the server 33 as it is. When a reception request packet from the client 32-7 arrives at the relay node 31-2,
If the relay node 31-2 is not in a high load state, it is registered as a child in the distribution table of the relay node 31-2.
As a result, the data packet from the server 33 is duplicated for the client 32-7 by the relay node 31-2 and is directly transmitted to the client 32-7 by unicast.

Since the reception request packet from the client 32-7 is continuously transmitted at a time interval equal to or smaller than a predetermined value, it is transferred by the relay node 31-3 and distributed by the relay node 31-2 each time. The arrival time of the reception request packet in the table is updated.

Next, as shown in FIG.
2-5 is deleted from the distribution table of the relay node 31-3 due to a leaving packet or a timeout, and the load of the relay node 31-3 is reduced. As a result, the relay node 31-3
-3 is assumed to be able to newly increase the number of children. At this time, the client 32-
When the reception request packet of No. 7 arrives, the relay node 31-
3 does not transfer this reception request packet to the relay node 31-2, but registers the client 32-7 in the distribution table. This state is shown in FIG.

As a result, the data packet is sent from the relay node 31-3 to the client 32-7. After that, the client 32-
Since the reception request packet from 7 does not reach, the client 32-7 times out in the distribution table of the relay node 31-2, and the data packet cannot be sent from the relay node 31-2 to the client 32-7.

At this time, until the relay node 31-2 times out, the same data packet is sent from the relay nodes 31-2 and 31-3 to the client 32-7. Regarding this, the data packet is numbered in advance, and the relay node 31 is based on the number.
-3, the duplicate packet is discarded, and the client 32-
It suffices to prevent the same packet from being sent multiple times.
Also, in the client 32-7, when a plurality of the same packets arrive, they may be discarded.

Regarding data packet numbering, R
FC1889 Real-Time Transport Protocol (RT
As in P), it may be represented by a set of a time stamp and a sequence number.

As described above, it is possible to autonomously change the structure of the multicast tree according to the load state of the relay node, and it is possible to achieve load distribution.

The keep alive method is also useful when the client or server is a mobile terminal. For example, when the client is a mobile terminal, if the client moves out of the accommodation range of the relay node that has been accommodated so far, the client is accommodated in a different relay node. Even in such a case, the client keeps issuing the reception request packet,
It is registered in the newly accommodated relay node, and the relay node that has been accommodated so far times out. In this way, the client can continue to receive the data packet from the server 33 without being aware of the relay node accommodated therein.

On the contrary, when the server 33 is a mobile unit,
If there is a mechanism such as mobile IP that enables unicast to a mobile body, the reception request packet sent to the server 33 is always sent to the position where the server 33 actually exists. When the server 33 moves to be accommodated in a different relay node, a new distribution table is created only when the distribution table does not exist in the relay node on the route from each client to the server. Become.

For example, as shown in FIG. 10, it is assumed that the server 33, which has been housed in the relay node 31-2 until now, has moved and is now housed in the relay node 31-4.

At this time, the relay nodes 31-1 and 31- that exist in common on the path from any client to the server 33 before and after the server 33 moves.
The distribution table of No. 3 does not change, and the distribution table is newly generated in the relay node 31-4 newly added to the path, and the relay nodes 31-1 and 31-3 are registered. Then, the relay node 31-4 sends a reception request packet to the server 33.

Since the reception request packet is no longer sent to the relay node 31-2 that has deviated from the path from each client to the server 33, it times out. As a result, the final configuration is as shown in FIG.

Before the relay node 31-2 times out, data packets may reach the relay nodes 31-1 and 31-3 via the relay nodes 31-4 and 31-2. In this case, the same data packet will arrive in duplicate. On the other hand, similarly to the above, by adding a sequence number to the data packet, the relay node or the client may discard the same packet when a plurality of same packets arrive.

In the keep alive method, a relay node having a child that has not timed out must be prevented from timing out as a child of the relay node closer to the server. The simplest method is to use a timer interrupt. A timer is set on the relay node itself to check whether each child of the distribution table has timed out at a predetermined time interval. As a result, if any child has not timed out, a reception request packet is sent to the server.

However, with this method, a timer interrupt may occur during the processing of the data packet or the reception request packet, and in some cases the overhead may be serious.

A method that does not use the timer interrupt is a method that is realized as a part of the processing when the reception request packet arrives.

For example, it is assumed that the client sends a reception request packet at every time interval D. The relay node records the time T when the reception request packet was last sent to the server. When the reception request packet arrives, if the transmission source is not yet registered in the distribution table, register it and then compare the current time with the time T,
If (current time-T) ≧ D, a reception request packet is sent to the server, and the current time is set at time T.

When the maximum value of the number of links from a client to a relay node (or server) is called the height of the relay node (or server), the transmission delay between the relay nodes or between the client and the relay node is When there is no fluctuation, according to the above method, the time interval at which the reception request packet arrives at the relay node (or server) of height h is at most h × D. The reason for this can be shown inductively as follows.

It is assumed that the reception request packet received from a child by a certain relay node has an arrival interval (when measured for each child) of at most D '. At this time, according to the above method,
The maximum interval for sending a reception request packet from this relay node is that the reception request packet is sent before, and a reception request packet from a certain child arrives just before the time D elapses, and the same child sends the reception request packet. This is a case where a packet received from another child does not arrive (due to a departure or a hang-up) until the next reception request packet arrives.

In this case, after all, the time of D + D 'has elapsed from the time when the reception request packet was transmitted before and the time when the reception request packet was transmitted next. Also, D'is equal to D for relay nodes whose children are all clients.

When there is fluctuation in the transmission delay between the relay nodes or between the client and the relay node, if the absolute value (fluctuation) of the amount of increase / decrease in the transmission delay is α, all the children are clients. The arrival time interval of the reception request packet arriving at the relay node is at most D + 2α. Therefore, for the same reason as above, the time interval at which the reception request packet arrives at the relay node (or server) of height h is at most h × (D + 2α).

In a relay node (or server) having a height h, for each child, if the height of the child is h−1, then h × x since the reception request packet was received from that child last time.
If the time exceeding (D + 2α) has elapsed, it may be determined that a time-out has occurred. Further, if there is fluctuation in the processing delay of the relay node, the sum of the transmission delay and the fluctuation of the processing delay may be considered as α.

However, when a packet may be lost during transmission, even if the client continues to send the reception request packet, the relay node (or server) of height h has a time interval exceeding h × (D + 2α). The receive request packet may arrive at. In that case, it is necessary to appropriately extend the time interval for determining the timeout. In the following, it is assumed that the packet is not lost during transmission.

When the upper limit H of the value of h is known in advance from the network to be used, H × (D + 2α) may be used as the value for judging the timeout in all the relay nodes.

When the upper limit H of the value of h is not known in advance, h
For example, a method using a reception request packet can be considered. A variable h representing the height is prepared in the reception request packet. The client sends out a reception request packet with h = 0. In the relay node, the value obtained by adding 1 to the maximum value of the variable h included in the reception request packet received from each child is set as the value of h, and the reception request packet is transmitted. By doing this, the relay node
The value of h in the reception request packet received from a child is h *
, The child has height h *. In this way, the time interval to be timed out can be dynamically changed according to the shape of the tree.

FIG. 12 shows a processing flow in the relay node when the reception request packet arrives. However, the tree ID and the source (source) address included in the reception request packet are N and S, respectively. The processing when the load is high in FIG. 12 is shown in FIG.

FIG. 14 shows a processing flow in the relay node when the data packet arrives. The entry deletion operation in FIG. 14 is shown in FIG. However, the data packet contains the tree ID and the source (source) address,
Let us denote this by N and S. Further, X is a time interval for determining a time-out. That is, if the elapsed time from the arrival of the reception request packet to the present exceeds X, it is determined that the time-out has occurred. In FIGS. 12 and 14,
It is assumed that X is fixedly given.

The above method is not problematic when the user selects a server from a predetermined server group when designating the server, but like the case where the user inputs the server address using a keyboard or the like. When there is a possibility of server specification error, a distribution table for a server that does not actually exist is generated in each relay node. In such a case, send a server confirmation packet to the server before sending the reception request packet,
On the other hand, the reception request packet may be transmitted only when the packet indicating the existence of the server is returned from the server.

In this embodiment, the server and the relay node receive the reception request packet from the child and distribute the data packet to the child. Further, the client and the relay node request the server to deliver the data packet. Further, when the client and the relay node receive the data packet from the parent node, the client and the relay node appear to receive the data packet from the server. That is, the present embodiment is excellent in scalability because it is not necessary to be aware of how many nodes are connected to the parent node or the child destination when transmitting the reception request packet and the data packet.

Note that the functions of the above-mentioned respective units in the client (reception host), the relay node, and the server (transmission host) can be actually realized by a computer. To that end, a program for causing a computer to execute the operation of this embodiment (for example, a relay program in the case of a relay node)
May be recorded in a computer-readable recording medium, and the functions of the present embodiment may be realized by causing the computer to read and execute the program recorded in this recording medium. The computer system mentioned here includes hardware such as peripheral devices in addition to the OS (operating system). Also WW
If the W (World Wide Web) system is used, the computer includes a homepage providing environment (or its display environment). The program above
It may be one that realizes a part of the functions described above, or one that realizes such a function in combination with a program already recorded in the computer (so-called difference program). Computer-readable recording media include flexible disks, magneto-optical disks, ROM
(Read-only memory), portable media such as CD-ROM,
It includes a storage device such as a hard disk built in the computer system. Further, the computer-readable recording medium holds the program dynamically only for a short time like a communication line when transmitting the program through a network such as the Internet or a communication line such as a telephone line. , Such as a volatile memory inside a computer system, which holds a program for a certain period of time. And, the above is exactly the same also in each of the embodiments and application examples thereof which will be described later.

[Embodiment 2] In Embodiment 1, as a measure against the possibility that a server designation error occurs, a method has been described in which a client sends a packet of two types of a server confirmation packet and a reception request packet. However, the second embodiment shows an embodiment in which only the reception request packet transmitted from the client can be dealt with and the server can also cope with a case where a server designation error may occur.

When the relay node closest to the client has a distribution table, the reception request packet sent from the client is registered in the closest relay node as in the case of the first embodiment. The case where the nearest relay node is in a high load state and the client cannot be accommodated as a child is similar to the case of the first embodiment.

If the relay node closest to the client does not have a distribution table, the reception request packet is transferred to the server. However, the relay node passed in the middle of the transfer is recorded in the reception request packet.

When the reception request packet arrives at the relay node or server which already has the distribution table, the route information from the client to the relay node or server is described in the reception request packet. The relay node or server sends a distribution table generation packet including this route information to the client.

The distribution table generation packet is delivered to the client by tracing the above route information in reverse,
In the relay node passing on the way, if the distribution table corresponding to the server already exists, it is simply transferred, and if there is no distribution table, the distribution table corresponding to the server is generated. Regarding the route information in the distribution table generation packet, a method of registering the next node at the same time as the generation of the distribution table is possible, but a method of not registering anything when generating the distribution table will be described below.

As described above, by the time the delivery table generation packet arrives at the client (to be precise, the delivery table generation packet is discarded at the relay node closest to the client), the delivery table generation packet is sent on the route from the client to the server. A distribution table is newly generated for a relay node that does not have a. As in the case of the first embodiment, the client continues to send the reception request packet at time intervals equal to or less than the predetermined value. Therefore, after the distribution table exists in all the relay nodes on the route from the client to the server, the client is registered in the distribution table as in the case of the first embodiment.
If necessary, the relay node itself sends a reception request packet to the server.

FIG. 16 shows an example of a network configuration in which multicast communication is performed, here four relay nodes 41.
-1, 41-2, 41-3, 41-4 have five receiving hosts (hereinafter, referred to as clients) 42-1, 42-2,
42-3, 42-4, 42-5 and one sending host 4
3 (hereinafter referred to as a server) is connected via a network.

In the configuration of FIG. 16, for example, as shown in FIG. 17, the relay node 4 is provided on the path from the client 42-3 to which the reception request packet is sent and which reaches the server 43.
It is assumed that there are 1-3 and 41-2. Relay node 41-
Since there is no distribution table in 3 and 41-2, the reception request packet is transferred to the server 43. However, at this time, as the transfer route, the relay nodes 41-3 and 41-2 are used.
Is written as route information in the reception request packet.

As shown in FIG. 18, from the server 43,
When the distribution table generation packet including this route information is transmitted, the route is reversed to the relay node 41.
-2 and 41-3 generate distribution tables. what if,
Even if the normal route from the server 43 to the client 42-3 passes through the relay node 41-4, the distribution table generation packet is transmitted to the relay nodes 41-2 and 41-3.
Will pass through.

Thereafter, from the reception request packet sent from the client 42-3, as shown in FIG. 19, the client 42-3 and the relay node 41-3 are displayed in the distribution tables of the relay nodes 41-3 and 41-2. Each is registered, and a reception request packet is sent from the relay node 41-2 to the server 43.

Then, as shown in FIG. 20, when a reception request packet is sent from the client 42-2,
Since the relay node 41-1 does not have a distribution table, it is transferred to the server 43. When the reception request packet arrives at the relay node 41-2, since the relay node 41-2 has a distribution table, the distribution table generation packet is sent from the relay node 41-2 to the client 42-2. As shown in FIG. 21, the distribution table generation packet creates a distribution table in the relay node 41-1 and the subsequent reception request packet from the client 42-2 causes the client 42 to generate a distribution table as shown in FIG.
-2 is registered in the distribution table of the relay node 41-1,
The relay node 41-1 is registered in the relay node 41-2.

The route information is stored by the reception request packet, and the distribution table generation packet sent from the server or the relay node to the client traces the above route information in reverse, for the following reason. If the route from the client to the server and the route from the server to the client are different, if the distribution table generation packet is simply sent to the client, the distribution table will be different from the route from the client to the server. Will be made. In this case, since the reception request packet does not arrive at the relay node in which the distribution table is created, the reception node will time out immediately. Further, the reception request packet is always transferred to the relay node or server that has sent the distribution table generation packet. As a result, the data packet will never arrive.

Like the first embodiment, the second embodiment is also useful when the client or server is a mobile terminal. When the client is a mobile terminal, the client is registered in the newly accommodated relay node by continuously issuing the reception request packet, and the relay node that has been accommodated so far times out. Conversely, when the server is a mobile unit, if there is a mechanism that enables unicast to the mobile unit such as mobile IP, the reception request packet sent to the server is always sent to the position where the server actually exists. To be For this reason, a distribution table is created in the relay node that has newly received the reception request packet, and the distribution table of the relay node in which the reception request packet has stopped arriving times out.

A specific implementation example will be shown. The reception request packet has a tree ID N and a source (source) address S.
And source (source) side adjacent node address P and route information Q from the source to the current node. The client sends a reception request packet to the server with S and P as client addresses and Q = S. If the distribution table corresponding to the tree ID N already exists when the reception request packet arrives at the relay node, S
= P, S is registered, and if S ≠ P, a distribution table creation packet including Q is sent toward S.

When there is no distribution table corresponding to the tree ID N, P is changed to the address of the current relay node, the current relay node is added to Q, and the reception request packet is transferred. When the received packet arrives at the server, the same processing as that in the case where there is a distribution table is performed in the processing of the relay node.

FIG. 23 shows a processing flow when the reception request packet arrives at the relay node. However, the time interval D in FIG. 23 is defined as in the case of the first embodiment. Also,
The processing when the load is high in FIG. 23 is the same as that in FIG. FIG. 24 shows a processing flow when the delivery table generation packet arrives at the relay node.

In the present embodiment, the distribution table is generated only in the relay node existing on the path connecting the host that transmitted the reception request packet and the host that transmitted the data packet. Therefore, even if the distribution table generation packet is transmitted with an appropriate address as the destination address, the distribution table is not generated unless the node corresponding to this destination address actually exists. Therefore, if the addresses of the nodes in the network are hidden, it becomes difficult for the node to create a useless distribution table using only the distribution table generation packet.
Also, since packets other than the distribution table generation packet do not have a distribution table generation function, the distribution table is not naturally generated in the relay node. further,
Even if a host that sends a distribution table generation packet and a host that sends a reception request packet are prepared, and these hosts cooperate with each other to cause a node between them to generate a useless table, an effective attack Is difficult to do.

[Third Embodiment] The third embodiment shows another embodiment in which only the reception request packet is transmitted from the client, and the server can cope with a case where a server designation error may occur.

In this embodiment, when the client sends the reception request packet and arrives at the relay node, if there is no distribution table, the source is changed to the current relay node and the packet is transferred to the server. If there is, register the sender. The data packet sent from the server is
Upon arrival at the relay node, if there is no distribution table in the relay node, an empty distribution table is generated and disappears, and if there is a distribution table, for children that have not timed out as in the first embodiment. , Duplicate if necessary, and transfer the data packet.

The reception request packet that arrives after the empty distribution table is generated by the data packet causes the client side adjacent node on the path from the client to this relay node to be registered in the distribution table. This is because the source address of the received reception request packet is the client side adjacent node. The data packet arriving after this delivers the data packet to the client side adjacent node, and as a result, an empty distribution table is generated in the client side adjacent node.

In this way, the distribution table is created from the server to the client, and eventually the data packet is distributed to the client.

FIG. 25 is an example of a network configuration in which multicast communication is performed, in this case, four relay nodes 51.
-1, 51-2, 51-3, 51-4 have five receiving hosts (hereinafter, referred to as clients) 52-1, 52-2,
52-3, 52-4, 52-5 and one sending host 5
3 (hereinafter referred to as a server) is connected via a network.

In the configuration of FIG. 25, for example, when a reception request packet is sent from the client 52-3, this packet is transferred to the server 53 while changing its source address at each relay node. Server 53
Indicates that the source of the received reception request packet is the relay node 51.
-2, so as shown in FIG. 26, the relay node 51-2
Sends a data packet to the destination. When the data packet arrives, an empty distribution table is generated because the relay node 51-2 has no distribution table.

After that, the arriving reception request packet causes the relay node 51-3, which is the transmission source, to be registered in the distribution table of the relay node 51-2 as shown in FIG. Then, as shown in FIG. 28, the data packet is sent to the relay node 51-3 based on the distribution table of the relay node 51-2.

Similarly, after the empty distribution table is created in the relay node 51-3 as well, as shown in FIG. 29, the client 52-3 is registered by the reception request packet, and finally the data packet is transferred to the client 52-. 3 will be delivered.

If the route from the client to the server and the route from the server to the client are different, the distribution table is always created on the route from the client to the server, and the data packet also passes on that route. It does not happen that the relay node or server created is different from the relay node or server to which the receive request packet arrives. When a distribution table generation packet having no route information (equal to a data packet in this embodiment) is simply sent to the client, the destination address is not changed to the relay node. I can't make it in a node.

Like the first embodiment, the third embodiment is also useful when the client and server are mobile terminals. When the client is a mobile terminal, the client is registered in the newly accommodated relay node by continuously issuing the reception request packet, and the relay node that has been accommodated so far times out. Conversely, when the server is a mobile unit, if there is a mechanism that enables unicast to the mobile unit such as mobile IP, the reception request packet sent to the server is always sent to the position where the server actually exists. To be For this reason, a distribution table is created in the relay node that has newly received the reception request packet, and the distribution table of the relay node in which the reception request packet has stopped arriving times out.

FIG. 3 shows the processing flow when the reception request packet and the data packet arrive at the relay node.
0 and FIG. The processing when the load is high in FIG. 30 is the same as that in FIG. The entry deletion operation in FIG. 31 is the same as that in FIG. However, it is assumed that X in FIG. 31 is fixedly given.

Similar to the first embodiment, also in the present embodiment, when transferring the reception request packet and the data packet, it is not necessary to be aware of how many nodes are connected to the parent node or the child. Therefore, it is superior in terms of scalability.

Further, in the present embodiment, as in the second embodiment, the distribution table is generated only in the relay node existing on the path connecting the host that transmitted the reception request packet and the host that transmitted the data packet. It is like this. Therefore, as in the second embodiment, by hiding the addresses of the nodes in the network, unless the host that sends the distribution table generation packet and the host that sends the reception request packet cooperate with each other, the node is useless. No table is ever made. In addition, according to the present embodiment, even if the server side peeks at the reception request packet, it is only possible to know the node adjacent to the server, and the address of the node in the network other than the adjacent node. I don't know Therefore, safer security can be provided as compared with the second embodiment.

[Node Configuration] FIG. 32 shows the configuration of the first embodiment.
2 and 3 show a common client configuration, in which 61 is a clock, 62 is a packet generating means, 63 is a transmitting means, 64 is a receiving means, 65 is a video decoding means, and 66 is a video display means. .

At the client, the packet generation means 62
Periodically generates a reception request packet using the clock 61 and transmits it to the server by the transmission means 63.
When the receiving means 64 receives the data packet, the video decoding means 65 decodes the video data carried by the data packet, and the video display means 66 displays the video.

In the case of the client according to the first embodiment, in particular, the packet generation means 62 is used to generate a server confirmation packet, the transmission means 63 transmits it to the server, and the response packet is received by the reception means 64. Only in this case, the reception request packet described above is generated and transmitted.

FIG. 33 shows the structure of a relay node common to the first, second and third embodiments. In the figure, 71 is a clock and 7 is a clock.
2 is a node load measuring means, 73 is a distribution table, 74 is a distribution table managing means, 75 is a packet generating means, and 76 is a packet generating means.
Is a transmitting means, 77 is a receiving means, and 78 is a packet copying means.

When the relay node receives the reception request packet by the receiving means 77, the relay node refers to the clock 71 when the load is not high depending on the load state measured by the node load measuring means 72, and the distribution table managing means 74
12 (in the case of the first embodiment) and FIG. 23 (in the second embodiment)
30), the distribution table is updated as shown in FIG. 30 (in the case of the third embodiment), and the packet generation means 75 (if necessary) newly generates a reception request packet,
The transmitting means 76 transmits it to the server. When the data packet is received by the receiving means 77, the distribution corresponding to the tree to which the data packet belongs as shown in FIG. 14 (cases of the first and second embodiments) and FIG. 31 (case of the third embodiment). The packet duplication unit 78 duplicates the data packet by the number of children registered in the table, and the transmission unit 76 transmits the data packet to each child.

The distribution table 73 is generated by the distribution table management means 74 as shown in FIG. 12 (in the case of the first embodiment), FIG. 24 (in the case of the second embodiment), and FIG. 31 (in the case of the third embodiment). ), And deletion of the distribution table 73 and its entries is performed by the distribution table management means 74 in FIG. 14 (in the case of the first and second embodiments).
It is performed as shown in FIG. 31 (in the case of the third embodiment).

FIG. 34 shows the structure of a server common to the first, second and third embodiments. In the figure, 81 is a clock and 82 is a clock.
Is a distribution table, 83 is a distribution table management means, 84 is a packet generation means, 85 is a transmission means, 86 is a reception means,
87 is a packet duplicating means, and 88 is a distribution data accumulating means.

As with the relay node, the server stores the sender of the reception request packet and the arrival time of the reception request packet in the distribution table 82. The distribution table managing means 83 manages deletion, update, registration, etc. in the distribution table 82. The server uses the distribution data storage means 88.
The distribution data stored in the packet is packetized using the packet generation means 84, and the packet duplication means 87 is used to duplicate the number of unregistered children registered in the delivery table 82. To send to these children.

In the case of the server according to the second embodiment, the distribution table generation packet is the packet generation means 84.
And is transmitted by the transmitting means 85.

[Packet Format] Next, the packet format according to the above-described first to third embodiments will be described, and the flow identification will be described as a premise.

Since various packets are mixed and transferred in the network, the packets (reception request packet, data packet, distribution table generation packet, server confirmation packet) peculiar to each embodiment of the present invention are relayed by the client and relay. It is necessary to identify the flow so that the node and server can identify it. Although various methods can be considered to realize flow identification, here, as an example, a specific port (well-
The case of using a known port) is taken as an example. As a similar method, HTTP (Hyper T
ext Transfer Protocol) is well known.

Here, UDP (User Data) is used as the protocol.
tagram Protocol) is assumed. A specific port is determined in advance for flow identification, and a packet addressed to this specific port is identified by referring to the port number of the packet as a packet peculiar to each embodiment of the present invention. FIG. 35 is a diagram showing a state of flow identification using a specific port in a network including the server 101, the relay nodes 102 and 103, and the clients 104 and 105. The figure shows the case where the source port of the reception request packet and the reception port of the data packet are the same. The address of the server 101 is S, the addresses of the relay nodes 102 and 103 are A and B, and the addresses of the clients 104 and 105 are C1 and C2, respectively.

The reception request packet has the address S as the destination address and the specific port P as the destination port.
w, X as a source address (here, A, B, C1,
C2), Px as a source port (here, Pa, Pb, Pc1, Pc corresponding to the source address X)
2). The data packet has an address X as a destination address, Px as a destination port, S as a source address, and Ps as a source port.
The source address of the data packet is the server 101
Since the distribution table is generated for each server, the relay node determines which server each distribution table corresponds to by looking at the source address of the data packet. Also, each relay node 1
In the distribution tables 106 and 107 provided in 02 and 103, the fields of the reception port in which the same value as the source port of the reception request packet is stored are the transmission source (“child” in the figure) of the reception request packet and the arrival time. Are registered in pairs with each field.

Each client and each relay node use the destination port of the reception request packet as the specific port and transmit the reception request packet from the port desiring to receive the data packet to the server 101 by unicast. For example, the source address of the reception request packet sent by the client C1 is C1, the source port is Pc1, and
The destination address and the destination port are as described above.

The relay node to which the reception request packet arrives records the source address and the source port of the reception request packet in the distribution table. Further, the relay node refers to the distribution table and unicasts a data packet addressed to the reception port of each child that has not timed out and the destination of which is a set of the source address and the source port. For example, the relay node 103 registers the source address C1, the source port Pc1, and the arrival time 10:23:09 as a set in the distribution table 107 based on the reception request packet from the client 104. Also, the relay node 103
The destination address and the destination port are C1 and Pc1, respectively, and the server 10 is the source address and the source port.
The data packet having the values S and Ps as it is sent from the first side is sent to the client 104.

Further, the case where the relay node sends the reception request packet to the parent node is the same as the case of the client. For example, in the reception request packet sent by the relay node 103, the destination address and the destination port are always S and Pw, the source address is B, and the source port is an arbitrary port (for example, Pb). This is because only the reception request packet needs to be processed by the relay node having an address different from the destination (server) address. However, if the source port is set to Pw, a data packet whose destination port is Pw will flow in the network, but it is necessary to prevent the data packet from being processed by a relay node different from the destination. Also,
In the server 101 to which the reception request packet arrives, the source address and the source port are S and Ps, respectively, and the destination address and the destination port are the relay node 102, respectively.
The data packet equal to the source address A and the source port Pa of the reception request packet from is transmitted.

It is also possible to adopt a mode in which a plurality of servers are set up on a certain host and a plurality of types of streams are simultaneously and simultaneously distributed. Here, since the well-known port which is a specific port is used for flow identification as described above, it is not possible to distinguish each server on the same host based on the port. Therefore, information called a channel ID is newly provided to identify a plurality of servers on the same host. This channel ID needs to be set to a unique value on the same host, but does not necessarily have to be unique between different hosts. In this way, the server and the multicast tree can be uniquely specified by using the server address and the channel ID in combination. In other words, a distribution table is generated for each relay node for each set of server address and channel ID. The channel ID may be placed in the payload of the packet, for example.

Next, the packet format based on the flow identification just described will be described. FIG. 36 shows an example of the format of the reception request packet. The destination (server) address 111, the destination (server) port 112, the source address 113, and the source port 11 are shown.
4, channel ID 115, and height 116 fields. Destination address 111 to channel ID 11
5 is as described above. The height 116 is the same as in the first embodiment.
As described above, the relay node is used to know the height h on the multicast tree. Note that FIG.
As described with reference to FIG. 5, the destination address 111 and the destination port 112 are always addressed to the server.

Next, FIG. 37 shows an example of the format of the data packet.
1, destination port 122, source (server) address 12
3, source (server) port 124, channel ID 12
5, each field of data 126. The destination address 121 to the channel ID 125 are as described above. The data 126 is a stream (content) to be distributed. As described with reference to FIG. 35,
The source address 123 and the source port 124 always belong to the server. [Application example]

Next, an application example in which a data conversion function as an additional function is added to the multicast communication described in the above-described first to third embodiments will be described. The data conversion referred to here means that some or all of the content data is changed in the process of relaying a content such as a stream by a plurality of relay nodes. Specifically, a function of adding advertisement data to the content data, a function of replacing the advertisement data added to the content data with another advertisement data,
It has a function of converting the data format of the content data from one format to another.

Conventionally, when, for example, stream data with an advertisement is distributed from a server to a client via a multicast tree type network, required advertisement data is added to the stream data to be distributed in advance in the server. Generally, a method of preparing the prepared item and delivering it to each client is adopted.

In the case of adopting the above-mentioned method, the advertisement data which suits the taste of each client (user) is added to the stream data to present a more effective advertisement to each client. However, on the other hand, since it is necessary to prepare a large number of stream data with advertisements according to the type of taste of each existing client, the load on the server increases and its scalability decreases. Such problems were pointed out.

In order to deal with such a problem, various techniques have been proposed in recent years, for example, Japanese Patent Laid-Open No. 2000-29.
Japanese Laid-Open Patent Publication No. 712 discloses a method of selectively adding an advertisement at a terminal station installed in a game center or the like when downloading a game program from a server.

Further, Japanese Patent Laid-Open No. 11-13 filed by the applicant of the present application
In Japanese Patent No. 4353, an advertisement addition server installed in a network acquires stream data from the server in response to a data acquisition request from the client, and statistically displays the advertisement data matching the client's taste in the stream data. A method is disclosed in which the added one is returned to the client making the acquisition request.

However, in the above-mentioned method of selectively adding an advertisement in the terminal station, when attempting to distribute the load of the advertisement adding process, this must be performed for each existing terminal station, There was a problem that it could not be dealt with when the number dynamically increased or decreased.

Further, in the method of obtaining the required stream data with an advertisement using the advertisement addition server, the client needs to make a data acquisition request to the proxy server instead of the server, so the load concentrates on the advertisement addition server. There was a problem.

In addition, as a document disclosing a technique relating to advertisement distribution according to the taste of the client, Japanese Patent Laid-Open No.
There is a publication of 1-306611. In this document, an advertisement to be delivered to each user is determined based on the information accumulated in the preference management server, customer management server, and advertisement management server, and the advertisement is delivered according to the user's preference. However, in this document, there is no consideration of distributed advertisement addition, and there is a problem that it cannot be combined with the multicast technique adopted in the first to third embodiments described above.

Against this background, the present application example adds the following functions to the above-mentioned multicast communication.・ Effectively add or replace additional data such as advertisements that match the taste of each client to the content data. -In the distribution process of content data, the data format of the content data is converted into a format that can be received by each client. -The required content data is distributed in consideration of the load status of each relay node itself and the load status of the communication link of each relay node.

In this application example, description will be made assuming the following. First, assume that the application layer is used as the multicast protocol. Also, in IP multicast, anyone who participates in the multicast tree can be a sender of stream data, but here, only a node such as a server corresponding to the root of the multicast tree can be a sender. To do. In addition, each node on the multicast tree is capable of distinguishing its own child in order to perform different processing for each child, and the child also explicitly or implicitly knows its own parent node.

Here, in order to facilitate understanding, a description will first be made focusing on points peculiar to the data conversion function, and then a case where the data conversion function is added to the above-mentioned multicast communication will be described. Also, in the former description, as an overview, the description will be given assuming that advertisement data is added as predetermined additional data to the stream data in the relay process of the stream data by a plurality of relay nodes. Subsequently, first and second device examples, network system device examples and method examples, program examples and recording medium examples for implementing the method examples will be sequentially described based on the outline description, and further, as modifications thereof. A detailed description will be given with reference to a first modified example and a second modified example assuming the case where the data format of the stream data is converted.

Note that the first device example, the first network system device example, the first method example and the second device example, the second network system device example, and the second method example are assumed cost models. Although different, the basic technical idea is the same. Therefore, one of the first device example, the first network system device example, the first method example and the second device example, the second network system device example, and the second method example is selectively selected. It can be carried out. Similarly, it is possible to selectively implement either one of the first modification and the second modification. In addition, any one of the first device example, the first network system device example, the first method example or the second device example, the second network system device example, the second method example, and the first modification example. Alternatively, it can be carried out simultaneously with any of the second modified examples.

(Outline) In this application example, assuming the application to the above-mentioned multicast communication, it is assumed that stream data is distributed from a server to a plurality of clients by multicast. However, assuming a special case where there is one client, this application example can be applied to one-to-one communication (unicast).

The client (user) selects one or a plurality of categories from the n types of prepared advertisement categories. However, it is not necessary for the user to explicitly select the advertisement category at this time. For example, the information regarding the user's preference may be automatically extracted from the network access history of the client.

Further, each relay node has a function of adding or replacing advertisement data to stream data for each leaf side adjacent node (hereinafter, also referred to as “child node” or simply “child”) in the multicast tree type network. Shall be provided.

In the multicast network constituted by the relay nodes as described above, under the condition that the client likes the advertisement to be added in each relay node before the stream data transmitted from the server arrives at the client. The means, methods, procedures, and procedures for minimizing the cost of adding or replacing advertisement data over the entire network are shown below.

(First Device Example and Network System Device Example) A first device example, a network system device example, a first method example and a second device example, a network system device example, and a second system device example will be described below. The method example is the first example of the data conversion function which is an additional function to the multicast communication. First, FIG. 38 shows the first example in this application example.
FIG. 3 is a block diagram showing an internal configuration of a relay node according to the device example of FIG.

As shown in the figure, the relay node N1 according to the present apparatus example is a multicast tree for delivering stream data from a single server (not shown) to one or more clients (not shown). Form network (not shown), and basically adds advertisement data to the stream data in the relay process of the required stream data, basically the advertisement data storage means 101.
1, additional advertisement instruction table 1012, and receiving means 10
13, an advertisement addition / replacement unit 1014, a transmission unit 1015, a preference information extraction unit 1016, a preference information table 1017, and a preference information aggregation unit 1018.

Of these, the advertisement data storage means 1011
Stores the advertisement data to be distributed to each existing client in advance over a plurality of required categories, and the additional advertisement instruction table 1012 stores the preference of each client and the additional cost of the advertisement data. Advertisement data to be transferred to one or more existing leaf-side adjacent nodes (not shown) based on a preference vector (a form of "preference information" in the present invention, which will be described later in detail) indicating a correlation with The categories are defined in advance for each adjacent node on the leaf side.

The receiving means 1013 receives stream data transferred from the root side adjacent node (not shown) and also receives one or more preference vectors transferred from one or more leaf side adjacent nodes. To do. The receiving unit 1013 also functions to receive the advertisement data to be registered in advance in the advertisement data storage unit 1011 from the network.

Further, the advertisement addition / replacement means 1014
According to the data addition mode of the stream data received by the receiving means 1013, the category of the advertisement data to be transferred to each leaf side adjacent node is added to the additional advertisement instruction table 1
012 is selected, the advertisement data stored in the advertisement data storage means 1011 corresponding to the selected category is read, and the advertisement data related to the read is added to or replaced with the stream data. .

Then, the transmitting means 1015 adds an advertisement /
The stream data to which the advertisement data has been added and replaced by the replacement means 1014 is transmitted to each leaf-side adjacent node.

The additional advertisement instruction table 1012 is added.
Is the preference information extraction means 1016 and the preference information table 10
17, and the content can be updated by the preference information totaling means 1018.

In other words, the additional advertisement instruction table 1012 is
A preference information extracting unit 1016 that extracts (removes unnecessary packet headers and the like) from the one or more preference vectors received by the receiving unit 1013, and a preference that holds one or more preference vectors extracted by the preference information extracting unit 1016. The information table 1017 and one or more preference vectors held in the preference information table 1017 are collectively subjected to a predetermined calculation to obtain a new preference vector.
It is possible to update the content based on and.

In order to configure the multicast data communication system by the relay node N1 configured as described above, a multicast tree type network for delivering stream data from a single server to one or more clients. And configure the network to
The relay node N1 described above may be assigned to each of a plurality of relay nodes (the form of the network is not particularly shown, but will be apparent in the method example described later).

(First Method Example) Next, a first method example executed by the relay node N1 and the network system device configured as described above will be described.

First, in this method example, the following cost model is assumed. That is, the relay node N1 simply transfers a packet from the root-side adjacent node (hereinafter, also referred to as “parent node” or simply “parent”) to each leaf-side adjacent node, and the cost is “0”. Data addition
It is assumed that the cost of performing the replacement process is "1".

For example, when a relay node N1 on the network has c children, it simply forwards x children and the remaining c−x children of the advertisement data. If the addition / replacement process is executed and transmitted, the cost of the corresponding relay node N1 is c−x. Reducing the cost of the entire network under this cost model means reducing the number of times that advertisement data is added or replaced.

First, a method for minimizing the cost of the entire network under the above cost model will be described below. It should be noted that this method is realized by two phases, a "request phase" and a "delivery phase".

Here, in the request phase, the category of the advertisement that the client likes (hereinafter, also referred to as “advertisement category” or simply “category”) is transmitted to the network, and based on this, a plurality of relay nodes (N1 , N1,
...), the relay node N1 that actually adds / replaces the advertisement data is determined.

On the other hand, in the delivery phase, based on the determination made in the request phase, the appropriate relay node N1 actually adds / replaces the appropriate advertisement data. Hereinafter, detailed operations of the request phase and the delivery phase will be described.

First, in the request phase, each relay node and client periodically send the preference vector defined below to the parent node in the multicast tree. That is, when the number of advertisement categories is n, the preference vector is an n-dimensional vector (n-bit vector) whose elements are "1" or "0", and the i-th bit of the preference vector is "1". If there is, it indicates that the user likes the i-th advertisement category.

Here, when the client desires the i-th advertisement category, the client transmits a preference vector with the i-th bit of the n-bit vector set to "1" to the parent node. For example, the preference vector (0,1,0) indicates that the second category is desired from the three advertisement categories.

The client can also desire a plurality of advertisement categories at the same time. For example, the preference vector (1,1,0) desires the first or second category from the three advertisement categories. It means that. Therefore, if any advertisement category is acceptable, the preference vector is (1, 1, 1).

The processing of the request phase based on the above-mentioned preference vector will be described below with reference to the drawings.

39 (a) and 39 (b) are diagrams showing the outline of the request phase according to the first method example in the present application example.

First, as shown in FIG. 39 (a), the relay node N1 takes a majority decision of the preference vectors transmitted from the child, and extracts only the elements (bits) of the preference vector corresponding to the most requested advertisement category. The preference vector is set to "1" and the preference vector is transmitted to the parent node. At this time, if there are a plurality of most requested advertisement categories, all elements of the preference vector corresponding to those advertisement categories are set to "1" (other elements are "0"), and the preference vector is transmitted to the parent node. .

For example, there are two children, and the preference vector transmitted from each child is (1, 0, 0), as shown in the figure.
In the case of (1,0,1), the sum of these results in (2,0,1), so the preference vector (1,0,1) in which only the first bit is reset to "1" 0) to the parent node. That is, the sum of the preference vectors sent from all the children is calculated, only the bit having the maximum value is set to "1", and the other bits are set to "0", and this is transmitted to the parent node.

Further, as shown in FIG. 39 (b), the relay node N1 is a table showing categories of advertisement data to be added / replaced in the delivery phase, that is,
The additional advertisement instruction table 1012 described above is generated and stored according to the above-mentioned preference vector sent from each child.

In the additional advertisement instruction table 1012, the column "In" represents the category of the advertisement data added to the stream data from the parent node, and "Ou".
The columns of "t1", "Out2", ... Are the first, second, ...
Represents the category of advertisement data that should be added to the stream data output to the child. Further, “φ” represents a state in which advertisement data is not added, and “A”, “B”, “C”.
Represent the first, second, and third advertisement categories, respectively. The case where the stream data to which the advertisement data is not added is sent from the parent node may be the case where the server or the relay node which is the parent node does not have the function of adding the advertisement data to the stream data. To be

Here, the additional advertisement instruction table 1012
To the child who sent the preference vector (1,0,0),
The advertisement addition / replacement means described above is used to add / replace the category A advertisement, and to add / replace the category A or C advertisement to the child who has transmitted the preference vector (1, 0, 1). Instruct 1014. However, in the latter case, the additional advertisement instruction table 1012 is configured so that only the transfer is necessary, depending on the category of the advertisement data added to the stream data from the parent node.

For example, when the advertisement data of category C is added to the stream data from the parent node,
For a child who has transmitted the preference vector (1, 0, 1), by selecting category C, it is possible to simply transfer the stream data (category A).
If is selected, replace (Category C → Category A)
Will be added and the cost will increase, so we try to avoid this).

Originally, the advertisement data of the category requested by the parent node should be sent from the parent node. However, if the client dynamically changes the preference vector, the timing may change depending on the timing. May send advertisement data in a category different from the one requested to the parent node. Therefore, the entries of the additional advertisement instruction table 1012 are created for all the advertisement categories that may be sent from the parent node.

Next, the processing of the delivery phase based on the above-mentioned preference vector will be described with reference to the drawings.

FIG. 40 is a diagram showing a specific operation example of the request phase according to the first method example in the present application example.

In the figure, nodes indicated by "A" and "B" represent clients, nodes represented by "S" represent servers, and other nodes are relay nodes N1.
(Hereinafter, reference numerals “1001”, “1002”, “100
3) and “1004” represent alternative displays). Further, there are two types of advertisement categories, "A" and "B", and the reference numerals ("A" and "B") indicating the above-mentioned clients represent the advertisement category that the corresponding client likes (however,
“A” and “B” are the first and second advertising categories, respectively).

[0189] Of the symbols in each additional advertisement instruction table 1012, "*" means that it matches any advertisement category (including a state in which advertisement data is not added) ("In", "Out1", "Out2",
“Φ” is the same as those in FIG. 39 (b), but the child numbers are 1, 1 in order from the left child in the figure.
It is assumed that they are numbered as 2, 3, ...).

As shown in the figure, first, the advertisement category A
A client who prefers to send a preference vector (1,0) to the parent node, and a client who likes the advertisement category B sends a preference vector (0,1) to the parent node.

At this time, since the relay node 1003 receives the preference vector (1,0) from the child, the advertisement data added to the stream data sent from the parent node (relay node 1002) in the request phase is transmitted. The additional advertisement instruction table 1012 is generated so that the advertisement data belonging to the advertisement category A is added or replaced regardless of the category, and the preference vector (1, 0) received from the child node is transmitted to the parent node as it is. To do.

On the other hand, in the relay node 1004, since the preference vectors (0,1) and (1,0) are sent from the two children, the category of the advertisement data added to the stream data from the relay node 1002. Irrespective of the above, the additional advertisement instruction table 1012 is added so that the child on the left side of the drawing can add or replace the advertisement data belonging to the advertisement category B and the child on the right side can add or replace the advertisement data belonging to the advertisement category A. The relay node 1002 is configured and a new preference vector (1,
Send 1).

As a result, the relay node 1002 has 2
The preference vectors (1,0) and (1,1) are sent from the two children, and the relay node 1002 is connected to the left child (relay node 1003) from the parent node (relay node 1001). Irrespective of the category of the advertisement data added to the stream data, the addition or replacement of the advertisement data belonging to the advertisement category A is performed for the right child (relay node 1004). The additional advertisement instruction table 1012 is configured so that the advertisement data belonging to any one of them (the advertisement data belonging to the category that costs less) is added or replaced.

That is, in the illustrated example, the relay node 100
Whether the advertisement data of the advertisement category A or the advertisement data of the advertisement category B is added to the stream data from No. 1, the stream data is directly transferred to the relay node 1004. However, when no advertisement data is added to the stream data, the relay node 1002 determines that the advertisement category A or B.
Any one of the above is arbitrarily selected, the advertisement data of the selected category is added to the stream, and the relay node 10
04 (the operation of the relay node 1001 is similar to that in the relay node 1003 described above).

Then, the advertisement data is added / replaced in the delivery phase based on the additional advertisement instruction table thus generated and constructed.

It should be noted that each relay node 1001, 1002
Since 1003 and 1004 do not always receive the preference vector sent from the child at the same time, the preference vector sent from the child is actually stored in the above-mentioned preference information table 101.
It will be stored in step 7, and when the preference vectors from all the children are available, a majority decision will be taken to obtain a new preference vector. Further, in order to deal with the change of the preference vector and the participation and the withdrawal of the client from the multicast tree, the operation of taking a required majority decision is performed, for example, when the preference vector from the child is changed, or ,
It may be performed at predetermined time intervals set in advance.

Next, FIG. 41 is a diagram showing a concrete operation example of the delivery phase according to the first method example in this application example (corresponding to the request phase shown in FIG. 40).

As shown in the figure, each relay node 100
1, 1002, 1003 and 1004 determine the actual addition / replacement process of the advertisement data based on the advertisement data added to the stream data sent from the parent node. Therefore, even if the parent node sends the stream data to which the advertisement data belonging to the category inconsistent with the preference vector sent to the parent node is sent from the parent node due to the table update timing difference due to the request phase, The function of "adding advertisements according to taste" will not fail.

Therefore, the request phase and the delivery phase can operate independently, and if the time interval in which each additional advertisement instruction table 1012 is updated by the request phase is sufficiently long, the cost model described above is also used. With, the delivery with the minimum cost is realized.

[0200] Next, Fig. 42 is a diagram showing a cost example when the required addition / substitution processing of advertisement data is executed by a normal method. The numbers in the figure are the costs of each node.

As shown in the figure, first, it is assumed that each client forming a leaf of the multicast tree prefers any of "A", "B", and "C" as an advertisement category. In addition, thick solid lines, dotted lines, and broken lines in the figure respectively represent communication links through which stream data to which advertisement data of advertisement categories A, B, and C are added flow, and the numbers given in the vicinity of each relay node are: It represents the cost at each of these relay nodes.

Here, based on the fact that there are the most clients who prefer the advertisement category A, the advertisement data of the category A is added to the stream data in the relay node immediately below the server, and each client is adjacent to the stream data. In the relay node, the advertisement data is replaced according to the preference of each client.

When the advertisement data is replaced as described above, the cost of the entire multicast network is "1" if the sum of the costs at each relay node is taken.
1 ”is understood.

On the other hand, FIG. 43 is a diagram showing a second cost example when the advertisement data addition / replacement processing is executed by the first method example in the present application example. The numbers in the figure are the costs of each node.

As shown in the figure, when the advertisement data is replaced by this method example, the cost of the entire multicast network is "8", which is less than the above-mentioned normal case and the required advertisement data is required. It becomes possible to execute the addition / replacement processing of.

(Second Device Example and Network System Device Example) The present device example and the network system device example are as follows:
The meaning of the preference vector, a specific method for calculating the cost required for adding / replacement of advertisement data, and the format of the preference vector sent by the client are the above-mentioned first.
Device example and network system device. FIG. 44 is a block diagram showing an internal configuration of a relay node according to the second device example in the present application example.

As shown in the figure, the relay node N2 according to the present device example is directed from a single server (not shown) to one or more clients (not shown), as in the first device example. It is applied to a multicast tree type network (not shown) for delivering stream data, and in order to add advertisement data to the stream data in the relay process of the required stream data,
Basically, the advertisement data storage unit 1021, the additional advertisement instruction table 1022, the reception unit 1023, the advertisement addition / replacement unit 1024, the transmission unit 1025, the preference information extraction unit 1026, and the preference information table 1027.
And preference information totaling means 1028.

[0208] These advertisement data storage means 102
1, additional advertisement instruction table 1022, receiving means 102
3, advertisement addition / replacement means 1024, and transmission means 1
The configuration of 025 is the same as that of the first device example, and thus its description is omitted.

[0209] Also, the additional advertisement instruction table 1022
Can be updated by the illustrated preference information extraction means 1026, preference information table 1027, and preference information totalization means 1028.

In other words, the additional advertisement instruction table 1022 is
A preference information extracting unit 1026 for extracting one or more preference vectors (one form of “preference information” in the present invention, which will be described later in detail) received by the receiving unit 1023, and one extracted by this preference information extracting unit 1026. The content is updated based on the preference information table 1027 holding the above preference vector. Also, the preference information totaling unit 1028 collectively performs a predetermined calculation on one or more preference vectors held in the preference information table 1027 to obtain a new preference vector.

In order to configure the multicast data communication system with the relay node N2 configured as described above, a multicast tree type network for delivering stream data from a single server to one or more clients. And configure the network to
The above relay node N2 may be assigned to each of a plurality of relay nodes (the form of the network is not particularly shown, but will be apparent in the method example described later).

(Second Method Example) Next, a second method example executed by the relay node N2 and the network system device configured as described above will be described assuming a more general cost model. .

FIG. 45 is a diagram showing an outline of a cost model according to the second method example in this application example.

As shown in the figure, in this method example, a certain relay node N2 (hereinafter referred to as a substitute display by the symbol "k") is c.
If the i-th category advertisement data is added to the stream data transmitted from the parent node in the case of having a number of children, the advertisement data is a (j ) Suppose that the situation is changed to the advertisement data of the category.

At this time, the addition / replacement cost of the advertisement data at the relay node k is f _k (i,
a (1), a (2), ..., a (c)). However, it is assumed that the advertisement data is not added to the stream data sent from the parent node, which is also one advertisement category, and in the following description, only the replacement of the advertisement data will be considered. Further, the advertisement data belonging to the same advertisement category are equivalent from the viewpoint of replacement cost. If not, the above conditions may be satisfied by further subdividing the categories.

For example, the advertisement categories “A”, “B”, and “C” are respectively “A ₁ ” and “A ₂ ”,
Even when subdivided into “B ₁ ” and “B ₂ ”, “C ₁ ”, and “C ₂ ”, if the categorization meaningful to the client is “A”, “B”, and “C” , The user interface is divided into “A”, “B”, and “C” categories. For example, when the advertisement category A is favored, the advertisement category A ₁ or A ₂ is actually favored. Should be interpreted and processed.

With respect to the above cost model, a method of replacing advertisement data so that the cost of the entire network is minimized will be described below. Note that this method is also realized by two phases of a “request phase” and a “delivery phase”, as in the case of the first method example.

[0218] First, in the request phase, the client pays a cost of "0" when the advertisement data that it prefers is added to the stream data, and when the other advertisement data is added, Information that the cost is infinity “∞” is transmitted to the parent node. If this information is expressed as an n-dimensional vector (preference vector) for the number of advertisement categories n, for example, the preference vector from the child who likes the fourth category of advertisement data is
(∞, ∞, ∞, 0, ∞, ∞, ..., ∞).

As described above, due to the difference in the assumed cost model, the preference vector of this device example and the preference vector of the first device example have different definitions.
That is, in the preference vector in the first device example, each element of the preference vector is set to "1" or "0" depending on whether or not the client likes each advertisement category. On the other hand, in this apparatus example, each element of the preference vector is set to 0 or infinity depending on whether or not the data favored by the client is added to the stream data sent from the server side.

Here, each relay node k, k, ... Has a function f _k (i, a (1), a (2), a (2), a (2), … ， A (c))
Based on the above, when the advertisement data of the category i is added to the stream data received from the parent, the minimum cost value of the subtree rooted at the relay node k is obtained for each i, and this is represented by the preference vector. To the parent node.

That is, now, the relay node k is the parent node P.
If the advertisement data of category i is added to the stream data received from (k) and the subtree rooted at the relay node k is T (k), T (k) that can be achieved at this time is obtained. Let v ^k _i be the minimum cost of
The relay node k transmits the n-dimensional preference vector V _k = (v ^k ₁ , v ^k ₂ , ..., V ^k _n ) to the parent node P (k).

The above preference vectors are the preference vector sent from the child node and the above-mentioned function f _k (i, a (1), a (2), ..., A).
(c)) and (the detailed calculation method is described later), for example,
If V _k is (10, 23, 41), there are three advertisement categories, and the advertisements belonging to the first, second, or third category in the stream data from the parent node P (k). T that can be achieved when data is added
The minimum cost of (k) is "10", "23",
Indicates "41". Then, the above-described preference vector calculation / transmission processing is sequentially executed from the leaf toward the root.

At each relay node k, each i (i
= 1,2, ..., in order to achieve a v ^k _i to n), the category of the advertisement data to replace regard stream data to be transmitted to the child, since it is possible to obtain in the calculation process of the v ^k _i, This is the additional advertisement instruction table 10
It is recorded as No. 22, and this additional advertisement instruction table 1
Using 022, advertisement data is replaced in the delivery phase as in the first method example.

Next, the method of calculating the preference vector will be described as follows. That is, first, an arbitrary relay node k having c children sets the advertisement data added to the stream data to the j (j = 1, 2, ..., N) th child by a (j). Suppose that the advertisement data of the second category is replaced.

At this time, if the stream data to which the i-th advertisement data is added arrives from the parent node P (k), the cost for replacing the advertisement data at the relay node k is the function f _k (i ， A (1) ， a (2) ，… ，
It is represented by a (c)).

Now, for the relay node k, the n-dimensional preference vector sent from the j-th child is U _j = (u ^j ₁ ,
u ^j ₂ , ..., U ^j _n ), and the j-th child is a relay node C _k (j)
, The minimum cost of the subtree T (C _k (j)) when the stream data to which the a (j) th advertisement data is added is transmitted from the relay node k is u ^j _{a (j)} . is there.

Therefore, the minimum cost of the subtree T (k) in this case is f _k (i, a (1), a (2), ..., a (c)) + u ¹ _{a (1)}
It becomes + ... + u ^ca _(c) . Therefore, the preference vector V _k =
The elements v ^k _i of (v ^k ₁ , v ^k ₂ , ..., V ^k _n ) are a (1), a
F _k (i, in all combinations of (2), ..., a (c)
The minimum value of a (1), a (2), ..., a (c)) + u ¹ _{a (1)} + ... + u ^c _{a (c)} may be used.

The above calculation is performed for each i to obtain V _k = (v ^k ₁ , v ^k ₂ , ..., V ^k _n ) and to achieve each v ^k _i a (1), a The combination of (2), ..., A (c) represents the additional advertisement instruction table 10 in each relay node k.
It should be recorded in 22.

Next, FIG. 46 is a diagram showing a concrete operation example of the request phase according to the second method example in the present application example, and FIGS. 47 (a) to 47 (c) show the cost function. It is a figure which shows a specific example.

First, as shown in FIG. 46, in the state where three relay nodes are interposed between the server and the client, each relay node k (1001, 1002, 1
003), the cost function for f _k (i, a (1), a (2),
…, A (c)) = g _k (i, a (1)) + g _k (i, a (2)) +… + g
_The case where it can be decomposed into _k (i, a (c)) is taken as an example.

That is, when focusing on a certain relay node k,
The cost required to replace the advertising data for each child is
It is completely independent and equal in cost function.

Here, examples of the cost function g _k at each relay node are as shown in the left columns of FIGS. 47 (a) to 47 (c). In the figure, each row of the cost function g _k represents an advertisement category before replacement, each column thereof represents an advertisement category after replacement, and “φ”, “A”, and “B” are the first and second, respectively. Handled as the third and third advertising categories. However, the state in which no advertisement data is added is considered as one advertisement category.

For example, the relay node 1001 shown in FIG.
In, the cost g required to add the advertisement data A from the state where no advertisement data is added
₁₀₀₁ (φ, A) is “10” (the preference vector and additional advertisement instruction table 1022 shown in FIG.
(A) to the one generated and transmitted in the request phase based on the cost function shown in the left column of FIG. 47 (c)).

Next, FIGS. 48 (a) and 48 (b) show
FIG. 50 is a diagram showing a part of a specific operation example of a request phase according to a second method example in the present application example, and FIGS. 49 (a) to 49 (c) are diagrams showing a calculation example of a cost function, FIG.
FIG. 8 is a diagram showing another part of a specific operation example of the request phase.

First, as shown in FIG. 48A, when the relay node 1002 receives the preference vector U ₁ = (20,1,20) from the relay node 1003 which is its child, the relay node 1002 transmits it to the relay node 1001. Preference vector and additional advertisement instruction table 1 to be generated in the relay node 1002
The calculation method of 022 is as shown in FIGS. 49 (a) to 49 (c).

Here, when the table of g _i is regarded as a matrix,
The child matrix is represented by G _i (see right columns in FIGS. 47A to 47C). g ₁₀₀₂ is the relay node 10
Since it represents only the processing cost in 02,

[Equation 1] By calculating, a matrix having the cost value of the subtree T (2) as an element is obtained (see FIG. 49 (a)).

The minimum value in the i-th row of the above equation 1 represents the minimum cost of the subtree T (2) that can be achieved when the i-th category advertisement data is added to the stream data from the parent node. ing. In any case, it is understood that substituting and sending the advertisement data of category A to the child is the selection for achieving the minimum cost (see FIG. 49 (b)).

Then, as described above, as shown in FIG. 49C, the preference vector to be transmitted to the relay node 1003,
The additional advertisement instruction table 1022 to be generated in the relay node 1002 is obtained, and thereafter, as shown in FIG. 50, after the request phase processing in the relay node 1002 is completed, the same processing is performed in the relay nodes 1003, 1
002 and 1001 are sequentially performed to generate the additional advertisement instruction table 1022 in all the relay nodes, and based on this, the advertisement data addition / replacement processing is performed in the delivery phase described below.

FIG. 51 is a diagram showing a concrete operation example of the delivery phase according to the second method example in the present application example.

As shown in the figure, the stream data sent from the server is the relay nodes 1001 and 100.
2, 1003 according to each additional advertisement instruction table 1022. That is, the relay node 1001 transfers the stream data without adding the advertisement data,
In the relay node 1002, the advertisement data of category A is added to the stream data and transferred, and in the relay node 1003, the advertisement data of category A is already added to the stream data, so only the transfer is performed.

The above method minimizes the cost of the entire network. In the example of FIG. 46, the relay node 100
As shown in FIGS. 47 (a) to 47 (c), the addition processing of the advertisement data is performed only by G2.
_{This is because 1002} has an element having a smaller value than the elements of G ₁₀₀₁ and G ₁₀₀₃ . For example, it is understood that the load distribution can be performed by reflecting the load state of the relay node on this cost value.

Next, FIG. 52 is a diagram showing a concrete operation example of another request phase according to the second method example in this application example, and FIGS. 53 (a) to 53 (d) show other operation examples. It is a figure which shows the example of calculation of a cost function.

First, as shown in FIG. 52, when stream data is delivered to a plurality of clients by multicast, the relay node 1002 and the relay node 1
As in the case of the example shown in FIG. 46, f _k (i, a (1),
a (2), ..., a (c)) = g _k (i, a (1)) + g _k (i, a (2)) + ...
Assuming that it can be decomposed as + g _k (i, a (c)), j
Preference vector U _j from the (j = 1, 2, ..., C) -th child
= (U ^j ₁ , u ^j ₂ , ..., u ^j _n ) for f _k (i, a (1),
a (2), ..., a (c)) ＋ u ¹ _{a (1)} ＋ u ² _{a (2)} ＋ ・ ・ ・ ＋ u ^c _{a (c)} ＝ (g
_k (i, a (1)) + u ¹ _{a (1)} ) + (g _k (i, a (2)) + u ² _{a (2)} ) + ...
+ (G _k (i, a (c)) + u ^c _{a (c)} ).

Therefore, for each j, g _k (i, a (j)) + u ^j
_{By finding} the minimum value of _{a (j)} and taking the sum, f
_k (i, a (1), a (2), ..., a (c)) + u ¹ _{a (1)} + u ² _{a (2)} + ... + u
The minimum value of ^c _{a (c)} can be obtained (in the preference vector and additional advertisement instruction table 1022 shown in the figure, g _k is in the form shown in each left column of FIGS. 53A to 53D). It was sent and generated in the request phase when given). Since the relay node 1001 and the relay node 1003 have only one child, the calculation method of the preference vector and additional advertisement instruction table 1022 is the same as the example shown in FIG. 46.

Next, FIGS. 54 (a) and 54 (b) show
FIG. 55 is a diagram showing a part related to the relay node 1002 of FIG. 52, and FIGS. 55 (a) to 55 (d) are diagrams showing calculation examples of the relay node 1002 in FIGS. 54 (a) and 54 (b); FIG. 56 is a diagram showing how the relay node 1002 of FIG. 52 sends out a preference vector.

First, as shown in FIGS. 54 (a) and 54 (b), the relay node 10
03 to the preference vector U ₁ = (20,1,20), and from the relay node 1004 to the preference vector U ₂ = (4,
3 and 3) have arrived.

At this time, the preference vectors U ₁ and U ₂ and g
From the matrix G ₁₀₀₂ Metropolitan representing the _1002, FIG. 47 (a) through FIG. 47
By performing the same calculation as in the example shown in FIG.
The calculation results shown in (a) to (c) of FIG. 55 are obtained, and the sum of the minimum values of the children is taken to send the result to the relay node 1001 as shown in (d) of FIG. The preference vector V ₁₀₀₂ = (16, 6, 15) can be obtained. Then, as shown in FIG. 56, upon completion of the request phase process in the relay node 1002, the category of the advertisement data to be replaced at the same time to obtain the minimum value is set in the additional advertisement instruction table 1022 of the relay node for each child node. Based on this, required advertisement data addition / replacement processing is performed in the delivery phase described below.

Next, FIG. 57 is a diagram showing a specific operation example of another delivery phase according to the second method example in the present application example.

As shown in the figure, the stream data sent from the server is the relay nodes 1001 and 100.
2, 1003, 1004 additional advertisement instruction table 10
22 is processed. That is, the relay node 1001 adds the category A advertisement data to the stream data, and the relay node 1002 already adds the category A advertisement data to the stream data, so that only the transfer is performed, and the relay node 1003 For the same reason, only the transfer is performed, and in the relay node 1004, only the left child in the figure is replaced with the advertisement data of category B, and the right child is only transferred.

That is, in the relay node 1001 and the relay node 1004, the required advertisement data replacement processing is performed, and the relay node 1002 and the relay node 1003.
In, only transfer is performed. This is because the values of the elements of the matrices G ₁₀₀₁ and G ₁₀₀₄ are the same as those of the matrix G ₁₀₀₂ as shown in FIGS.
And G ₁₀₀₃ , which is relatively smaller than the value of the element. Therefore, similarly to the case of the example of FIG. 46, it is understood that the load distribution of the entire network can be realized by reflecting the load state of each relay node 1001, 1002, 1003, 1004 in g _k .

If it is expected that the traffic volume will increase remarkably by adding the advertisement data to the stream data, the communication link having a narrow usable band is used as the stream data among the communication links forming the multicast tree. When is passed, it is more effective not to add advertisement data to it.

To realize this, if the communication link on the tree connecting the relay node k and the j-th child is congested, the cost function f when a (j) ≠ φ is satisfied. _By setting a large value of _k (i, a (1), a (2), ..., a (c)), advertisement data is not added as much as possible when stream data passes through this communication link. It is possible to

On the other hand, in the stream data from the server,
By adding information such as the number of viewers, the type of stream data, or the scenes that change from moment to moment separately from the advertisement data, at each relay node, among the advertisement data belonging to the category that the client likes, It is also possible to select predetermined advertisement data according to information such as the number of viewers and add / replace it.

FIG. 58 is a diagram showing a viewer count / advertisement category search table applicable to the second method example in this application example.

As shown in the figure, in this viewer count-advertisement category search table 1029, that row indicates the viewer count.
The columns represent the advertising categories, which are "A1", "A2",
“A3” indicates that the advertisement data belonging to the advertisement category A is
“B1”, “B2”, and “B3” indicate that the advertisement data belonging to the advertisement category B is “C1”, “C2”, and “C3”.
Each of the advertisement data belonging to the advertisement category C is shown.

By placing the viewer number-advertisement category search table 1029 shown above in each relay node N2 in addition to the additional advertisement instruction table 1022, the advertisement data to be added / replaced according to the number of viewers is generated. Can be changed.

For example, when the additional advertisement instruction table 1022 created in the request phase instructs to add (replace) the advertisement data of category B, the viewer number information added to the stream data from the server If is "5000", the advertisement data "B2" may be added (replaced). By adopting such a method, it becomes possible to carry out advertisement attachment that reflects the intentions of both the advertiser, the stream data provider, and the user.

(Example Program and Example Recording Medium)
A program example and a recording medium example that can be applied to the implementation of the first and second method examples described above will be described.

As described at the end of the first embodiment, the relay nodes N1 and N2 are composed of computers for transmitting and receiving stream data composed of packets. Therefore, the first and second method examples described above can be programmed as an execution procedure.

In this case, as a required program, for example, (a) when the stream data is transferred from the adjacent node on the root side of the relay node, the correlation between the preference of each client and the additional cost of the advertisement data is obtained. Based on the preference vector indicating the above, the processing step of selecting a category of the advertisement data defined in advance as the additional advertisement instruction tables 1012 and 1022 for each of the existing one or more leaf side adjacent nodes, and (b) being transferred. When the advertisement data is not added to the stream data, the advertisement data storage means 1011 and 1 corresponding to the selected category.
A processing step of transferring the advertisement data registered in advance to the adjacent node on the leaf side in 021, and (c) the advertisement data is already added to the transferred stream data, and the advertisement data is selected. If the advertisement data is different from that of the classified category, the advertisement data is replaced with the advertisement data registered in advance in the advertisement data storage means 1011 and 1021 corresponding to the category and transferred to each leaf side adjacent node. And (d) when the ad data is already added to the transferred stream data and the additional data is the same as that of the selected category, the stream data is directly applied to each leaf side adjacent node. And a processing step of transferring.

Also, a series of procedures consisting of the processing steps constituting the above program are written in an arbitrary recording medium, and this is executed before the execution of the relay nodes N1, N.
If it is installed in 2 (all relay nodes that make up the network), the processing related to the required advertisement data addition function will be realized.

In the above, the first and second apparatus examples, network system apparatus examples and method examples, and programs and recording media have been described by taking advertisement data as an example of required additional data to be added to stream data. However, this is merely one application example of the present invention, and the present invention is similarly applicable to any other additional data.

(First Modification) Next, as a modification of the first and second device examples and network system device examples and method examples, and programs and recording media described above, the data format of stream data will be described. Two modified examples of the case of conversion will be described. These modified examples are the second example of the data conversion function which is an additional function to the multicast communication. Incidentally, in this first modification,
The data format of stream data may or may not be convertible (having reversibility) for all existing types.

FIG. 59 is a block diagram showing the internal structure of a relay node according to this modification. When converting the data format of stream data, the first node is selected as the relay node N3.
And a storage unit 1041 that replaces the advertisement data storage unit (1011, 1021) shown in the second device example, a conversion instruction table 1042 that replaces the additional advertisement instruction table (1012, 1022), and an advertisement addition / replacement unit (1014, 1024) alternative data format conversion means 1
044 is newly configured, and further, the receiving means 1043, the transmitting means 1045, the preference information extracting means 1046, the preference information table 1047, which are similar to those in the respective device examples.
And the preference information totalizing means 1048 is set.

Of the above, the storage means 1041 requires a plurality of data format conversion means 1044 for converting the data format of stream data to be distributed to the existing clients into a format receivable by each client. The conversion instruction table 1042 stores one or more existing ones based on the preference vector representing the correlation between the preference of each client and the data format conversion cost of stream data. Data format conversion means 10 to be adopted in the leaf side adjacent node
The 44 categories are defined in advance for each adjacent node on the leaf side.

Also, the data format conversion means 1044 determines the category of the data format conversion means 1044 to be adopted in each leaf side adjacent node according to the data format of the stream data received by the reception means 1043, and the conversion instruction table 1042. The data format conversion means 1044 stored in the storage means 1041 corresponding to the selected category is read out by reference, and the data format conversion means 1044 associated with the reading is used to convert the data format of the stream data. Is.

In order to configure a multicast data communication system with the relay nodes configured as described above, a multicast tree type network for delivering stream data from a single server to one or more clients is used. The relay node described above may be allocated to the plurality of relay nodes in the network.

In implementing the method, category A of the advertisement data described in the first and second method examples,
It is possible to interpret B and φ as mutually translatable languages and to explain that the relay node has a translation function. As a result, the server sends the stream data described in the language φ, and by translating it at the relay node on the route until reaching the client, the stream data described in the language requested by the client is delivered. Can be used for services.

For example, as an example of stream data,
Assuming a translation for video data or the like, the translation can be interpreted as an encoding conversion or a media conversion. However, since this kind of data conversion can often be performed in only one direction, the above characteristics of data conversion should be taken into consideration when applying the method in this modification.

FIG. 60 is a diagram showing the specific operation of the request phase according to the first modification of this application example, and FIG.
FIG. 1 is a diagram showing a specific operation of a delivery phase in the modified example.

First, as shown in FIG. 60, the server sends the required stream data in the encoding method C, and the
One client has a different encoding method A
Alternatively, B receives stream data. However, among the above encoding methods, conversion from method B to method A is possible, but the opposite conversion from method A to method B is not possible (this is expressed as “B⊃A”). ). Further, in the description of this figure, the same cost model as that described in FIG. 40 is used as the cost model for simplification, but it can be extended to the general cost model described in FIG. 46. is there.

Here, when "A", "B", and "C" are respectively set to the first, second, and third encoding systems, the relay node 1004 selects the preference vector (0, 1,0), (1,0,0), but B⊃A
Since the encoding method A cannot be requested to the relay node 1002, the preference vector (0, 1, 0) is transmitted.

On the other hand, the relay node 1002 selects the preference vectors (1,0,0) and (0,1,0) from the two children.
Is received, but since B⊃A, the relay node 1001
, The preference vector (0, 1, 0) is transmitted.

As a result of the above, in the request phase, the conversion instruction table as shown in the figure is set in each relay node 1001, 1002, 1003, 1004,
In the delivery phase, conversion of the encoding method as shown in FIG. 61 is realized. However, it is assumed that the data format sent by the server can be converted to the encoding method B (otherwise, such a service itself does not hold).

When the program is configured in the present modification, when the program receives, for example, stream data from the adjacent node on the root side of the relay node (a ′), the preference of each client and the stream data. In order to convert the data format of the stream data into a format that can be received by each client based on the preference vector that represents the correlation with the data format conversion cost of the And (b ') the data format conversion means for obtaining the data format of the transferred stream data are of the selected category. If it is different, the stream data is registered in advance in the storage means corresponding to the category. The processing step of converting the data by the existing data format conversion means and transferring it to each leaf side adjacent node, and (c ') the data format conversion means for obtaining the data format of the transferred stream data are selected in the selected category. If the same as the above, the processing step of directly transferring the stream data to each leaf side adjacent node may be provided.

Further, a series of procedures consisting of the processing steps constituting the above program are written in an arbitrary recording medium and introduced into a relay node (all relay nodes forming a network) prior to execution. Then, the processing related to the required data conversion function will be realized.

(Second Modification) Subsequently, as a second modification, the data formats of stream data are not always convertible for all existing types (some have irreversibility). Another example of the case is the above-mentioned first
And a second method example. In the following description, of all the existing data formats, the data format that can be converted to any data format requested by the client is
At least one is assumed to be present (ignoring this assumption, it will not be possible to fit all clients into one multicast tree).

First, FIG. 62 is a diagram showing a conversion constraint graph (directed graph) which defines the constraints on the conversion between the data formats in the stream data described in the first method example in the second modification of this application example. Is.

In the illustrated conversion constraint graph 1030,
The numbers shown at each node represent the types (all four types) of all existing data formats, and when conversion from data format i to data format j is possible, the direction from node i to node j is directed. There is a branch (i, j). However, the data format i
Even when it is necessary to go through one or more other data formats in the middle when the data is actually converted to the data format j, it is defined as “the conversion from the data format i to the data format j is possible”.

In the cost model described in the first method example, since any data format conversion is performed at the cost "1", it does not mean that the corresponding data format can be directly converted. This is because they do not have. Therefore,
If a directional path exists from the node i to the node j, the directional branch (i, j) always exists.

The above conversion constraint graph 1030 is
The preference information totaling unit 1018 of the relay node N1 shown in the first device example to which the first method example is applied is held in advance, or is transferred from one or more leaf-side adjacent nodes via the receiving unit 1013. It may be added as data to the preference vector.

Next, FIG. 63 shows the preference vector sent by each relay node or client when the conversion constraint graph 1030 shown in FIG. 62 is given, and the stream data delivered corresponding to this preference vector. It is a figure which shows the relationship of.

The preference vector is defined in the same manner as in the first method example. That is, assuming that the number of all data formats is n, the preference vector is an n-dimensional vector (n-bit vector) whose elements are "1" or "0", and the i-th bit of the n bits is "1". If so, it means that the i-th data format is requested.

Here, the method of collecting preference vectors will be described by taking the illustrated relay node 1001 as an example. According to the definition of the preference vector, the relay node 1002 requests the second or fourth data format. To be understood. In these data formats, the relay node 1001 to the relay node 100
In order to send the stream data to No. 2, according to the rule of the conversion constraint graph 1030, the stream data is
It must be the second, third, or fourth data format.

In this way, if a set of data formats of stream data from the parent node that can be converted into the data format required by the relay node (or client) j is represented by S _j , S ₁₀₀₂ = {2,3, 4}, S ₁₀₀₃ = {2, 3,
4}, _S1005 = {1,2,3} (j = 4 is a missing number).

At this time, in order to satisfy the requirements from all the child nodes, the data format of the stream data from the parent node must be S ₁₀₀₂ ∩S ₁₀₀₃ ∩S ₁₀₀₅ = {2,3}. Therefore, here, the second or third data format is requested to the parent node.

Since the sum of the preference vectors from all the child nodes is (1, 2, 1, 2), when the stream data from the parent node is in the second data format, the relay node is better. The conversion cost in 1001 is low.
Therefore, the relay node 1001 sends (0, 1, 0, 0) to the parent node (“server 1010” in the figure).

On the other hand, the preference vectors (0,1,0,1) and (0,0,1) generated by the relay nodes 1002 and 1003.
0, 1, 1) is S ₁₀₀₆ = {1, 2, 3, 4}, S ₁₀₀₇
= {2,3,4}, _S1008 = {1,2,3,4}, and _S1009 = {2,3,4}. Since the product set of S _j has at least one data format that can be converted into an arbitrary data format,
It is never the empty set.

The method of collecting preference vectors at each relay node can be summarized as follows. 1. Preference vector from each child j and conversion constraint graph 1030
Calculate S _j from 2. The sum of preference vectors from each child j (s ₁ , s ₂ , ...,
s _n ) is calculated. 3. Let i be the element of the product set of S _j and I be the set of i having the maximum value in the set of s _i . 4. The preference vector sent to the parent node is (b ₁ , b ₂ , ...,
b _n ). However, if i ′ is an element of I, then b _{i ′} = 1, and if not, b _{i ′} = 0.

A conversion instruction table is generated in each relay node so that the stream data is converted into a data format that satisfies the preference vector from each child, as in the first method example. However, if the stream data arrives from the parent node in a data format other than the requested data format temporarily due to the timing of updating the preference vector, etc., convert it to the data format requested by the child if possible. If the conversion is impossible, the data packet itself may be discarded.

This does not cause much problem in a stable network in which the order of packets does not change. Because each client and relay node keep sending the same preference vector periodically,
This is because stream data will not arrive from the parent node in a data format other than the requested data for the following reasons.

That is, since the parent node always calculates the preference vector so that the request of the child node is satisfied, even if the child of the parent node other than the client or the relay node changes the preference vector, the parent node is This is because the stream data requested by the newly generated preference vector can be converted into the data format requested by the client or the relay node.

By the way, as a special case of the conversion constraint,
If i ₁ <i ₂ , conversion from the i ₂ -th data format to the i ₁ -th data format is possible, but the reverse is impossible. In this case, the preference vector calculation can be simplified as follows.

That is, the relay node (or client) j
The preference vector from (b ^j ₁ , b ^j ₂ , ..., b ^j _n ), b ^j _i =
Let min (j) be the minimum value of the subscript i satisfying 1 and T be the maximum value of min (j) over all the children j, and the product set of S _j for all the children j is the set {i | i ≧ T}.

[0295] For example, in the case of the relay node 1001 shown in Fig. 64 (example of special conversion constraint), min (2) = 2, mi
Since n (3) = 3 and min (5) = 1 (j = 4 is a missing number), T
= 3, and _{S 1002 ∩S 1003 ∩S 1005 = {} 3,4}. At this time, the sum of the preference vectors from the three children is (1,
2, 1, 2), the relay node 1001 sends (0, 0, 0) to the parent node (“server 1010” in the figure).
0, 1) is transmitted.

The method of dealing with the conversion constraint based on the cost model described in the first method example has been described above. On the other hand, in the cost model described in the second method example, the function f _k (i, a By setting the values of (1), a (2), ..., A (c)) as follows, it is possible to meet the required conversion constraint.

That is, when a data format that cannot be converted from the data format i is included in a (1), a (2), ..., A (c), f _k (i, a By setting (1), a (2), ..., a (c)) = ∞ (infinity), such (i, a (1), a
The combination of (2),…, a (c)) can be excluded.
Further, the value of f _k (i, a (1), a (2), ..., A (c)) can reflect the difference in conversion cost between data formats.

FIG. 65 is a diagram showing a conversion constraint graph (directed graph) which defines constraints on conversion between data formats in stream data described in the second method example in the second modification example of the present invention. The label of each directed edge represents the corresponding data conversion cost.

Here, the conversion constraint graph 103 shown in FIG.
When 1 is given, as in the second method example,
f _k (i, a (1), a (2), ..., a (c)) = g _k (i, a (1)) + g
_{Considering a case in which k} (i, a (2)) + ... + g _k (i, a (c)) can be decomposed, g _k (i, a (j)) is further directed to (i, a (j) )) Label, f _k (2,1,1,3) = g _k (2,1)
It is calculated that + g _k (2,1) + g _k (2,3) = 3 + 3 + 2 = 8.

As described above, by reflecting the conversion cost between each data format in the value of (i, a (1), a (2), ..., A (c)), the overall multicast tree becomes more precise. It is possible to minimize various conversion costs.

According to the above modification, the values of f _k (i, a (1), a (2), ..., A (c)) as described in the second method example are It is also possible to reflect the load status of the node and the available bandwidth of the communication link.

That is, in order to reflect the load state of the node, the function f _k (i, a (1), a
By setting the values of (2), ..., a (c)) to be larger than the values of the functions of other relay nodes, the conversion processing in the relay node with a heavy load is performed as described in the second method example. , You can try to avoid it as much as possible.

Further, in order to reflect the usable bandwidth of the communication link, when the communication link with the parent node is congested, the conversion cost from a data format with a large required bandwidth to another data format is increased. By setting to, it is possible to reduce the possibility that stream data in a data format having a large required band will pass through the congested communication link.

(Application to Multicast Communication) Next, the overall configuration of the relay node in this application example will be described. FIG. 66 is a block diagram showing details of the overall configuration of the relay node N4, and the same components as those shown in FIGS. 33 and 38 are designated by the same reference numerals. The thick solid line in the figure shows the flow of data packets, the thin solid line shows the flow of reception request packets, and the dotted line shows the flow of control signals.

As shown in FIG. 66, the entire structure of the relay node is basically a combination of the components of FIGS. 33 and 38. However, the receiving means 77 and the transmitting means 76 in FIG. 33 are common to the receiving means 1013 and the transmitting means 1015 in FIG. 38, respectively, and some constituent elements are partially changed as described below.

First, the distribution table management means 1174 adds the distribution table 73 and the additional advertisement instruction table 1012.
The preference information table 1017 is also configured to be managed (generated, updated, deleted). Node load measuring means 117
2 also transmits the measured load state to the preference information collecting unit 1118 in order to reflect the load state of the relay node in the cost value. Based on the load status received from the node load measuring means 1172, the preference information totaling means 1118 judges whether or not its own relay node has a high load, and if the load is high, the reception request packet from the child node is directly sent to the parent node. To the packet generation means 1175. Also, the preference information totaling means 11
The reference numeral 18 refers to the distribution table 73 in order to exclude the child preference information that has timed out when performing the intensive calculation on the preference vector. Further, when the instruction from the preference information totaling means 1118 is sent, the packet generating means 1175 changes the source address to the address of the current node and transfers the reception request packet to the parent node.

Next, FIG. 67 is a diagram showing the format of a reception request packet in this application example, and the same fields as in FIG. 36 are assigned the same reference numerals. The difference from FIG. 36 is that a field of preference vector 117 is added. That is, in this application example, the preference vector is included in the reception request packet. As described above, in the first to third embodiments, the reception request packet is sent out periodically, and the data packet is distributed in the reverse order of the route through which the reception request packet has passed. On the other hand, in this application example, the data format conversion method for the data in the data packet is determined based on the packet carrying the preference vector, and the packet carrying the preference vector needs to follow the same route as the data packet passes. There is. Further, in order to follow the change of the preference vector corresponding to the change of the preference of the client, it is necessary to retransmit the packet carrying the preference vector at least when the preference vector changes. In consideration of the similarities between the multicast distribution and the data conversion function, the preference vector is placed in the reception request packet to efficiently realize the data conversion function.

FIG. 68 is a diagram showing the format of a data packet in this application example, and the same fields as in FIG. 37 are assigned the same reference numerals. The difference from FIG. 37 is that the fields of the data format control information 127 and the data format 128 are inserted between the channel ID 125 and the data 126. Data format control information 12
Reference numeral 7 is used when partially converting the data 126 (when adding or replacing the advertisement data), and indicates the position of the portion to be converted. For example, when the advertisement data is replaced, the data format control information 127 indicates the part to be replaced.

On the other hand, the data format 128 represents the name of the data format describing the data 126. In one multicast tree, it is possible to perform both the process of adding / replacement of advertisement data and the process of converting the data format. Therefore, the data format 128 is an encoding method for stream data (for example, MPEG1, MPE).
G2), a data name indicating advertisement data or the like added to the stream, or both of them at the same time. Each relay node has a conversion processing routine for all values that can be taken as the data format 128, and the data format control information 127 is referred to in these conversion processing routines. When the advertisement data is added or replaced, the data 126 includes the advertisement data in addition to the stream data.

The operation of the relay node shown in FIG. 66 is as follows. When the reception request packet arrives at the relay node N4, the reception request packet is passed to the distribution table management means 1174 via the reception means 1177, and as described in the first to third embodiments relating to the multicast communication. Is performed. However, at this time, in synchronization with the generation / deletion of the distribution table 73 or the generation / deletion of each entry constituting the distribution table 73,
Preference information table 1017 and additional advertisement instruction table 1
012 is generated / deleted, or each entry forming the preference information table 1017 and the additional advertisement instruction table 1012 is generated / deleted.

On the other hand, the reception request packet is received by the receiving means 117.
7 is also passed to the preference information extraction means 1016, and processed as described above in this application example. However, when the preference information totaling means 1118 performs an aggregate operation on the preference vector on the preference information table 1017,
The distribution table 73 is referred to and the preference information of the timed-out child is excluded from the aggregation target. On the other hand, the data packet is passed to the packet duplication unit 78 via the reception unit 1177, and the above-described first embodiment relating to the multicast communication is performed.
Or, after the operation as described in the third embodiment is performed, it is passed to the advertisement addition / replacement means 1114, processed as described above in this application example, and transmitted by the transmission means 1176.
Sent from.

Next, FIG. 69 is a block diagram showing the internal structure of the client according to this application example, and the same components as those shown in FIG. 32 are assigned the same reference numerals. In the present application example, a preference information acquisition unit 1201 that acquires information regarding a user's preference and generates a preference vector is added to the configuration of FIG. Then, the packet generation means 1162 uses the clock 61 to periodically generate the reception request packet, and the preference information acquisition means 120.
The preference vector from 1 is placed in the reception request packet. In the figure, the thick solid line shows the flow of data packets, the thin solid line shows the flow of reception request packets, and the dotted line shows the flow of control signals.

In FIG. 66, the distribution table 73, the additional advertisement instruction table 1012, and the preference information table 1017.
Was configured with separate tables, but it is efficient to combine these into a single table. FIG. 70 shows an example of such an integrated distribution table. As shown in the figure, the integrated distribution table is composed of fields of child number, address, port, reception request packet arrival time, preference vector, and advertisement.

The fields of "child number", "address", and "reception request packet arrival time" are the same as those shown in FIG. The "port" field corresponds to the "reception port" field on the distribution table described with reference to FIG. The "preference vector" field stores the preference vector sent from each child. The “advertisement” field is a category φ, A, B, C of the advertisement data that may be sent from the parent node (for example, “I” in FIG. 39B).
n ”) corresponding to the category of the advertisement data distributed to the child (for example,“ Out1 ”in FIG. 39B).
Alternatively, “(Out2)” is stored for each child.

According to the application example of the present invention, it becomes possible to efficiently add additional data such as an advertisement that suits the taste of each client to the content data, and at the same time, in the distribution process of the content data, It becomes possible to convert the data format to a format that can be received by each client. In addition to this, the distribution of the required content data is considered in consideration of the load status of each relay node itself and the load status of the communication link of each relay node. It becomes possible to do it.

The embodiment of the present invention has been described above.
The present invention is not necessarily limited to the above-described means, methods, procedures and procedures, and can be appropriately modified and implemented within the scope of achieving the object of the present invention and having the effects described below. Is.

For example, in the above description, stream data was given as an example of content data, but this is merely one application example of the present invention, and the present invention is applied to any other content data. Is similarly applicable.

[0318]

According to the present invention, the relay device does not generate the distribution table even if it receives only one of the reception request message periodically sent by the receiving device and the data from the transmitting device. . Therefore, even if a malicious user makes an attack such as sending a packet for generating a distribution table to a large number of addresses, a large number of meaningless distribution tables will not be generated in the relay device in the network. Absent. Therefore, it is possible to prevent the load of the relay device from becoming heavy and the performance thereof from being deteriorated due to the attack.

Further, according to the present invention, the receiving device periodically issues the reception request message, and the transmitting device or the relay device stops the delivery of the multicast data to the receiving device which does not receive the reception request message within a predetermined time interval. By doing so, the delivery of the multicast data can be stopped when the receiving device fails or a packet loss occurs on the transmission path. Further, since the receiving device continues to issue the reception request message periodically, even if the relay device closest to the receiving device changes or the load state of the relay device changes, it is possible to change the delivery route of the multicast data. Furthermore, the receiving device is only required to actively output packets, and the state transition is unnecessary.

Further, according to the inventions of claims 5 and 15, it becomes possible to efficiently add additional data such as an advertisement that suits the taste of each user to the content data or the like distributed to the receiving device. In the distribution process of content data and the like, for example, the data format of the content data can be converted into a format that can be received by each receiving device. In addition to this, according to the invention described in claims 6 and 16, distribution of required content data and the like is performed in consideration of the load state of each relay device itself and the load state of the communication link of each relay device. Is possible.

[Brief description of drawings]

FIG. 1 is an explanatory diagram showing an example of a network configuration in multicast communication according to a first embodiment of the present invention.

FIG. 2 is an explanatory diagram showing an example of a distribution table according to the first embodiment of the present invention generated and updated by a relay node.

FIG. 3 is an explanatory diagram of a process of unicasting data from a relay node according to the first embodiment of the present invention.

FIG. 4 is an explanatory diagram of a process of unicasting data from the relay node according to the first embodiment of the present invention.

FIG. 5 is a diagram showing an example of an updated distribution table according to the first embodiment of the present invention.

FIG. 6 is a diagram showing another example of a network configuration in multicast communication according to the first embodiment of the present invention.

7 is an explanatory diagram of a process of constructing a multicast tree in the network configuration of FIG.

8 is an explanatory diagram of a process of constructing a multicast tree in the network configuration of FIG.

9 is an explanatory diagram of a process of forming a multicast tree in the network configuration of FIG.

10 is an explanatory diagram of a process of constructing a multicast tree in the network configuration of FIG.

11 is an explanatory diagram of a multicast tree configuration process in the network configuration of FIG. 6;

FIG. 12 is a flowchart showing processing upon arrival of a reception request packet according to the first embodiment of the present invention.

FIG. 13 is a flow chart showing the processing when the load is high in FIG.

FIG. 14 is a flowchart showing processing when a data packet arrives according to the first embodiment of the present invention.

FIG. 15 is a flowchart showing the processing of the entry deletion operation in FIG.

FIG. 16 is a diagram showing an example of a network configuration in multicast communication according to the second embodiment of the present invention.

17 is an explanatory diagram of a process of forming a multicast tree in the network structure of FIG.

FIG. 18 is an explanatory diagram of a multicast tree configuration process in the network configuration of FIG. 16;

19 is an explanatory diagram of a process of forming a multicast tree in the network structure of FIG.

20 is an explanatory diagram of a process of constructing a multicast tree in the network configuration of FIG.

FIG. 21 is an explanatory diagram of a multicast tree configuration process in the network configuration of FIG. 16;

22 is an explanatory diagram of a multicast tree configuration process in the network configuration of FIG. 16;

FIG. 23 is a flowchart showing processing upon arrival of a reception request packet according to the second embodiment of the present invention.

FIG. 24 is a flowchart showing processing when a distribution table generation packet arrives according to the second embodiment of the present invention.

FIG. 25 is a diagram showing an example of a network configuration in multicast communication according to the third embodiment of the present invention.

FIG. 26 is an explanatory diagram of a multicast tree configuration process in the network configuration of FIG. 25.

27 is an explanatory diagram of a multicast tree configuration process in the network configuration of FIG. 25. FIG.

28 is an explanatory diagram of a multicast tree configuration process in the network configuration of FIG. 25. FIG.

29 is an explanatory diagram of a process of forming a multicast tree in the network structure of FIG. 25.

FIG. 30 is a flowchart showing processing upon arrival of a reception request packet according to the third embodiment of the present invention.

FIG. 31 is a flowchart showing processing upon arrival of a data packet according to the third embodiment of the present invention.

FIG. 32 is a block diagram showing a configuration example of a client according to the first to third embodiments of the present invention.

FIG. 33 is a block diagram showing a configuration example of a relay node according to the first to third embodiments of the present invention.

FIG. 34 is a block diagram showing a configuration example of a server according to the first to third embodiments of the present invention.

FIG. 35 is a diagram showing a state of flow identification using a specific port according to the first to third embodiments of the present invention.

FIG. 36 is a diagram showing an example of a format of a reception request packet according to the first to third embodiments of the present invention.

FIG. 37 is a diagram showing an example of a data packet format according to the first to third embodiments of the present invention.

FIG. 38 is a block diagram showing an internal configuration of a relay node according to a first device example in an application example of the invention.

FIG. 39 is a diagram showing an outline of a request phase according to a first method example in an application example of the invention.

[Fig. 40] Fig. 40 is a diagram illustrating a specific operation example of a request phase according to a first method example in an application example of the invention.

FIG. 41 is a diagram showing a specific operation example of a delivery phase according to a first method example in an application example of the invention.

[Fig. 42] Fig. 42 is a diagram illustrating a cost example in the case where required advertisement data addition / replacement processing is executed by a normal method.

[Fig. 43] Fig. 43 is a diagram illustrating a cost example when the advertisement data addition / replacement process is executed by the first method example in the application example of the invention.

FIG. 44 is a block diagram showing an internal configuration of a relay node according to a second device example in an application example of the invention.

FIG. 45 is a diagram showing an outline of a cost model in a second method example in an application example of the invention.

FIG. 46 is a diagram showing a specific operation example of a request phase according to a second method example in an application example of the invention.

FIG. 47 is a diagram showing a specific example of the cost function according to the second method example in the application example of the invention.

FIG. 48 is a diagram showing a part of a specific operation example of a request phase according to a second method example in an application example of the invention.

FIG. 49 is a diagram showing a calculation example of a cost function according to a second method example in an application example of the invention.

FIG. 50 is a diagram showing another part of a concrete operation example of the request phase according to the second method example in the application example of the invention.

FIG. 51 is a diagram showing a specific operation example of the delivery phase according to the second method example in the application example of the invention.

FIG. 52 is a diagram illustrating a specific operation example of another request phase according to the second method example in the application example of the invention.

FIG. 53 is a diagram showing a calculation example of another cost function according to the second method example in the application example of the invention.

54 is a diagram showing a part related to the relay node 1002 of FIG. 52. FIG.

55] A relay node 1002 in FIG. 54 (a)
It is a figure which shows the example of calculation of.

FIG. 56 is a diagram showing how the relay node 1002 of FIG. 52 sends out a preference vector.

FIG. 57 is a diagram illustrating a specific operation example of another delivery phase according to the second method example in the application example of the invention.

FIG. 58 is a diagram showing the number of viewers / advertisement category search table applicable to the second method example in the application example of the invention.

FIG. 59 is a block diagram showing an internal configuration of a relay node according to a first modified example of an application example of the invention.

FIG. 60 is a diagram showing a specific operation of a request phase applied to a first modification example of the application example of the invention.

FIG. 61 is a diagram showing a specific operation of a delivery phase applied to a first modified example of the application example of the invention.

[Fig. 62] Fig. 62 is a diagram illustrating a conversion constraint graph (directed graph) defining constraints on conversion between stream data formats described in the first method example in the second modification example of the application example of the invention.

FIG. 63 is a diagram showing an example of a relationship between a preference vector sent by each relay node or client and stream data delivered corresponding to the preference vector when the conversion constraint graph shown in FIG. 62 is given. Is.

FIG. 64 is a case where the conversion constraint is special, that is, if i ₁ <i ₂ , conversion from the i ₂ -th data format to the i ₁ -th data format is possible, but the reverse is not possible. FIG. 6 is a diagram showing an example of a relationship between a preference vector sent by each relay node or a client and stream data delivered in correspondence with the preference vector when there is a constraint that

[Fig. 65] Fig. 65 is a diagram illustrating a conversion constraint graph (directed graph) that defines constraints on conversion between stream data formats described in the second method example in a second modification example of the application example of the invention.

FIG. 66 is a block diagram showing an internal configuration of a relay node according to an application example of the invention having a data conversion function.

FIG. 67 is a diagram showing a format of a reception request packet in a multicast data communication system according to an application example of the present invention having a data conversion function.

FIG. 68 is a diagram showing a format of a data packet in a multicast data communication system according to an application example of the present invention having a data conversion function.

FIG. 69 is a diagram showing an internal configuration of a client in a multicast data communication system according to an application example of the present invention, which has a data conversion function.

[Fig. 70] Fig. 70 is a diagram showing an example of an integrated distribution table included in a relay node according to an application example of the present invention having a data conversion function.

FIG. 71 is an explanatory diagram showing an example of a network configuration in conventional multicast communication.

FIG. 72 is an explanatory diagram showing an example of a conventional table generated and updated by a relay node.

FIG. 73 is a diagram showing another example of a network configuration in conventional multicast communication.

74 is an explanatory diagram of a process of forming a multicast tree in the network structure of FIG. 73.

FIG. 75 is an explanatory diagram of a multicast tree configuration process in the network configuration of FIG. 73;

FIG. 76 is an explanatory diagram of a process of forming a multicast tree in the network structure of FIG. 73.

77 is an explanatory diagram of a process of forming a multicast tree in the network structure of FIG. 73. FIG.

78 is an explanatory diagram of a process of forming a multicast tree in the network structure of FIG. 73. FIG.

79 is an explanatory diagram of a process of forming a multicast tree in the network structure of FIG. 73. FIG.

FIG. 80 is an explanatory diagram showing how an inquiry is made from the relay node to the receiving host;

81 is a diagram showing an example of a table after the inquiry made in FIG. 80. FIG.

[Explanation of symbols]

21, 31-1 to 31-4, 41-1 to 41-4, 51
-1 to 51-4, 102 to 105, N1 to N4, k, 1
001 to 1004: relay nodes 22-1 to 22-4, 32-1 to 32-7, 42-1 to
42-5, 52-1 to 52-5, 1005 to 1009:
Receiving host (client) 33, 43, 53, 101, 1010: Sending host (server) 61, 71, 81: Clock 62, 75, 84, 1162, 1175: Packet generating means 63, 76, 85, 1015, 1025. 1045, 1
176: transmitting means 64, 77, 86, 1013, 1023, 1043, 1
177: receiving means 65: video decoding means 66: video display means 72, 1172: node load measuring means 73, 82, 106, 107: distribution tables 74, 83, 1174: distribution table management means 78, 87: packet duplication means 88 : Distribution data storage means 111, 121: Destination address 112, 122: Destination port 113, 123: Source address 114, 124: Source port 115, 125: Channel ID 116: Height 117: Preference vector 126: Data 127 : Data format information 128: Data formats 1011 and 1021: Advertising data storage means 1012, 1022: Additional advertisement instruction table 1014, 1024: Advertising addition / replacement means 1016, 1026, 1046: Preference information extraction means 1017, 1027, 1047: Preference Information table 1018 , 1028, 1048, 1118: Preference information aggregation means 1041: Storage means 1042: Conversion instruction table 1044: Data format conversion means 1029: Number of viewers-advertisement category search tables 1030, 1031: Conversion constraint graph (directed graph) 1201: Preference information Acquisition method

   ─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor Noriyuki Takahashi             2-3-1, Otemachi, Chiyoda-ku, Tokyo             Inside Telegraph and Telephone Corporation F-term (reference) 5K030 HD03 LD05

Claims (22)

[Claims] 1. A multicast data communication system that uses a network capable of unicast communication and broadcasts data via a relay device provided on a unicast delivery path from a transmitter to a plurality of receivers. The plurality of receiving devices include means for transmitting a reception request message addressed to the transmitting device at time intervals smaller than a predetermined value, and the transmitting device has a reception interval of the reception request message. Means for determining whether or not the receiving device side adjacent node continues to request the reception of the data depending on whether it is less than a predetermined time interval, and the receiving device side adjacent node continues to request the reception of the data Means for sending the data to the receiving device when it is determined that the relay device is adjacent to the receiving device. When the data or distribution table generation packet is received from the transmitting device side adjacent node after receiving the reception request message from the node,
Means for generating a distribution table for registering the receiving device side adjacent node to which the data is to be delivered, and registering the receiving device side adjacent node that has transmitted the reception request message after generating the distribution table in the distribution table Means for determining whether or not the receiving-apparatus-side adjacent node continues to request reception of the data depending on whether the reception interval of the reception request message is less than a predetermined time interval, and the receiving-apparatus side When it is determined that the adjacent node continues to request the reception of the data, a reception request message addressed to the transmitting device is sent at each time interval smaller than a predetermined value, and the transmitting device-side adjacent node And a means for copying the data sent from the device and delivering it to the receiving device side adjacent node registered in the distribution table. Data communication system. 2. The multicast data communication system according to claim 1, wherein the reception request message includes route information indicating a route from the reception device to the relay device or the transmission device which has received the reception request message, The receiving device sends information indicating itself as the route information in the reception request message, and the transmitting device has the receiving device side adjacent node that has sent the reception request message registered in the distribution table. If not, the distribution table generation packet including the route information in the reception request message is generated, and the distribution table generation packet is transmitted to the receiving device according to the route information, and the relay device is configured to transmit the distribution table. A means for determining whether or not it has been generated is provided, and when the distribution table is being generated, the reception request message is sent. If the receiving device side adjacent node has not been registered in the distribution table, a distribution table generating packet including the route information in the reception request message is generated, and the distribution table generating packet is transmitted to the receiving device according to the route information. When the distribution table is not generated, new route information is generated by adding information indicating itself to the route information in the reception request message transmitted from the receiving device side adjacent node. Then, a reception request message including the new route information is transmitted to the transmission device as a destination, and when the distribution table generation packet is transmitted from the transmission device side adjacent node, according to the route information in the distribution table generation packet. A multicast data communication system for transferring the distribution table generation packet to a receiving device side adjacent node and for generating the distribution table. 3. The multicast data communication system according to claim 1, wherein the relay device further comprises means for determining whether or not the distribution table has been generated, and when the distribution table has not been generated, the receiving device side. The source of the reception request message sent from the adjacent node is changed to its own relay device and transferred to the adjacent node on the transmitting device side, and the distribution is performed when the data is sent from the adjacent node on the transmitting device side. A multicast data communication system that generates a table, discards the data, and when the distribution table is generated, registers the receiving device side adjacent node of the transmission source that has transmitted the reception request message in the distribution table. 4. The multicast data communication system according to claim 2, wherein the relay device determines whether the relay device is in a high load state in which a predetermined load is exceeded, and determines that the relay device is in the high load state. For the receiving device side adjacent node that is not registered in the distribution table while being transmitted, the transmission is performed without registration in the distribution table when the reception request message is sent from the receiving device side adjacent node. A multicast data communication system further comprising means for transferring the reception request message to a device as a destination. 5. The multicast data communication system according to claim 2, wherein the reception request message represents a correlation between a preference of each user corresponding to each of the receiving devices and a conversion cost for the data. Conversion information storage means including preference information, wherein the relay device stores in advance conversion information necessary for converting the data distributed to each of the receiving devices over a plurality of required categories; Based on the preference information in the reception request message sent from the receiving device side adjacent node, the category of the conversion information to be adopted for the receiving device side adjacent node is set in advance for each receiving device side adjacent node. According to the conversion instruction table defined by classification and the data sent from the transmitting device side adjacent node, the receiving device side is referred to by referring to the conversion instruction table. A category of the conversion information to be adopted for a contact node is selected, the conversion information stored in the conversion information storage means corresponding to the selected category is read, and the read conversion information is used. A multicast data communication system further comprising: a conversion unit that converts the data into the data, and a transmission unit that transmits the data converted by the conversion unit to the receiving-device-side adjacent nodes. 6. The multicast data communication system according to claim 5, wherein the conversion unit includes, in addition to the preference information, information indicating a load state of each of the relay devices or a load of a communication link between the relay devices. A multicast data communication system for selecting the category based on a state. 7. The multicast data communication system according to claim 5, wherein the preference information extracting means extracts the preference information from the reception request message sent from the receiving device side adjacent node, and the extracted preference information. A preference information storage unit for storing the preference information stored in the preference information storage unit is intensively subjected to a predetermined calculation to generate new preference information, and the conversion instruction table is updated with the new preference information. A multicast data communication system further comprising: preference information totaling means for transmitting the new preference information to the adjacent node on the transmitting device side. 8. A multicast data communication method, which uses a network capable of unicast communication and broadcasts data via a relay device provided on a unicast delivery path from a transmitter to a plurality of receivers. The plurality of receiving devices send out a reception request message addressed to the transmitting device at time intervals smaller than a predetermined value, and the relay device transmits the reception request message from a receiving device side adjacent node. When the data or distribution table generation packet is received from the transmitting device side adjacent node after receiving,
A distribution table for registering the receiving device side adjacent node to which the data is to be distributed is generated, and the transmitting device determines whether or not the reception interval of the reception request message is less than a predetermined time interval. Judging whether or not the adjacent node continues to request the reception of data, and sending the data to the adjacent node on the receiving device side that continues to request the reception of the data, and continuously requesting the reception of the data. The delivery of the data is stopped to the receiving device side adjacent node that has stopped, and the relay device distributes the receiving device side adjacent node that has transmitted the reception request message after the distribution table is generated. Registered in the table, the relay device determines that the receiving device side adjacent node determines whether the reception interval of the reception request message is less than a predetermined time interval. When it is determined whether or not data reception is continuously requested, and when it is determined that the reception device side adjacent node continues to request data reception, the transmission device is provided at time intervals smaller than a predetermined value. A multicast data communication method in which a reception request message addressed to is sent, and the data sent from the transmitting device side adjacent node is duplicated and delivered to the receiving device side adjacent node registered in the distribution table. 9. The multicast data communication method according to claim 8, wherein the reception device includes information indicating itself in the reception request message as route information and transmits the information, and the transmission device transmits the reception request message. If the receiving device side adjacent node has not been registered in the distribution table, the distribution table generating packet including the route information in the reception request message is generated, and the distribution table generating packet is generated according to the route information. A relay device that is sent to the receiving device and is present on the path from the receiving device to the relay device for which the distribution table has been generated and for which the distribution table has not been generated New route information is generated by adding information indicating itself to the route information in the request message, and the reception request message including the new route information is generated. Sending a message to the transmission device as a destination, and when the reception request message reaches the transmission device or a relay device in which the distribution table is generated, the transmission device or the relay device sends the reception request message. If the receiving device side adjacent node has not been registered in the distribution table, a distribution table generating packet including the route information in the reception request message is generated, and the distribution table generating packet is transmitted to the receiving device according to the route information. The relay table existing on the path from the relay device in which the distribution table is generated to the receiving device and in which the distribution table is not generated, the distribution table generation packet is transmitted from the transmitter-side adjacent node. When the packet is received, the distribution table generation packet is transferred to the receiving device side adjacent node according to the route information in the distribution table generation packet and Multicast data communication method for generating a distribution table. 10. The multicast data communication method according to claim 8, wherein the relay device existing on the route from the receiving device to the relay device for which the distribution table has been generated and for which the distribution table has not been generated is the receiving device. When the source of the reception request message sent from the adjacent node on the side is changed to its own relay device and transferred to the adjacent node on the transmission device side, when the reception request message reaches the relay device in which the distribution table is generated , The relay device registers the receiving device side adjacent node of the transmission source that has transmitted the reception request message in the distribution table, transmits the data to the receiving device side adjacent node, and the distribution table is generated. A relay device existing on the path from the relay device to the receiving device and for which the distribution table has not been generated is the data sent from the adjacent node on the transmitting device side. A multicast data communication method for receiving a data, generating the distribution table, and discarding the data. 11. A relay device in a multicast data communication system, which broadcasts data from a transmitting device to a plurality of receiving devices, using a network capable of unicast communication, the relay device comprising: from the transmitting device to the plurality of receiving devices. Is provided on a unicast delivery path to the transmitting device after receiving a reception request message from the receiving device-side adjacent node to which the plurality of receiving devices send out with the transmitting device as a destination at time intervals smaller than a predetermined value. Means for generating a distribution table for registering the receiving device side adjacent node to which the data is to be delivered when the data or the distribution table generation packet is received from the side adjacent node; and the reception request after generating the distribution table. Means for registering an adjacent node on the receiving device side that has sent the message in the distribution table; Means for determining whether or not the receiving device side adjacent node continues to request the reception of the data depending on whether or not the reception interval of the page is less than a predetermined time interval, When it is determined that the reception is continuously requested, the reception request message addressed to the transmission device is transmitted at each time interval smaller than a predetermined value, and the transmission device side adjacent node transmits the reception request message. A relay device comprising means for copying data and delivering it to a receiving device-side adjacent node registered in the distribution table. 12. The relay device according to claim 11, wherein the reception request message includes route information indicating a route from the reception device to the relay device or the transmission device which has received the reception request message, The device includes means for determining whether or not the distribution table is generated, and when the distribution table is generated, the receiving device side adjacent node that has transmitted the reception request message must be registered in the distribution table. For example, the route information indicating the route from the receiving device to the own relay device is extracted from the reception request message to generate the delivery table generation packet including the route information, and the delivery table generation packet is generated according to the route information. To the receiving device, and when the distribution table is not generated, the receiving device sent from the receiving device side adjacent node is transmitted. The new routing information is generated by adding information indicating itself to the routing information in the request message, the reception request message including the new routing information is sent to the transmission device as a destination, and the distribution table generation packet is A relay device which, when sent from an adjacent node on the transmitting device side, transfers the distribution table generating packet to the adjacent node on the receiving device side and generates the distribution table according to the route information in the distribution table generating packet. 13. The relay device according to claim 11, further comprising means for determining whether or not the distribution table is generated, and when the distribution table is not generated, the relay node is transmitted from an adjacent node on the receiving device side. The source of the reception request message is changed to its own relay device and transferred to the adjacent node on the transmitting device side, and when the data is sent from the adjacent node on the transmitting device side, the distribution table is generated to store the data. A relay device that discards and registers the receiving device side adjacent node of the transmission source that has transmitted the reception request message in the distribution table when the distribution table is generated. 14. The relay device according to claim 12 or 13, wherein the relay device determines whether or not the device itself is in a high load state in which a predetermined load is exceeded, and the distribution is performed while the high load state is determined. For adjacent nodes on the receiver side that are not registered in the table,
A relay device, further comprising: a unit that transfers the reception request message received with the transmission device as a destination without performing registration in the distribution table when the reception request message is transmitted from an adjacent node on the reception device side. . 15. The relay device according to claim 12, wherein the conversion information necessary for converting the data distributed to each of the receiving devices is requested in advance in a plurality of categories. A conversion information storage unit to be stored and a correlation between a preference of each user included in the reception request message sent from an adjacent node on the receiving device side and corresponding to each receiving device and a conversion cost for the data are displayed. Based on the preference information, the conversion instruction table in which the categories of the conversion information to be adopted for the receiving device side adjacent node are defined in advance for each receiving device side adjacent node, and the conversion information table sent from the transmitting device side adjacent node According to the data, the conversion instruction table is referred to select a category of the conversion information to be adopted for each adjacent node on the receiving device side, and the selected category is selected. Corresponding to, the conversion information stored in the conversion information storage means is read, and the conversion means for converting the data using the read conversion information; A relay device further comprising a transmitting unit that transmits data to the receiving-device-side adjacent nodes. 16. The relay device according to claim 15, wherein, in addition to the preference information, the conversion unit sets information indicating a load state of each relay device or a load state of a communication link between the relay devices. A relay device for selecting the category based on the above. 17. The relay device according to claim 15, wherein the preference information extracting unit extracts the preference information from the reception request message transferred from the receiving device side adjacent node, and the extracted preference information is stored. A preference information storage unit and a preference for collectively performing a predetermined calculation on the preference information stored in the preference information storage unit to generate new preference information, and updating the conversion instruction table with the new preference information. A relay device further comprising information totaling means and means for transmitting the new preference information to a transmitting device side adjacent node. 18. A network capable of unicast communication is used, and is provided on a unicast delivery path from the transmitting device to the plurality of receiving devices when data is broadcast from the transmitting device to the plurality of receiving devices. Is a relay method for relaying the data by a relay device, wherein the plurality of receiving devices receive a reception request message transmitted to the transmitting device at a time interval smaller than a predetermined value, and the receiving device When receiving the data or the distribution table generation packet from the transmitting device side adjacent node after receiving the reception request message from the side adjacent node, a distribution table for registering the receiving device side adjacent node to which the data is to be distributed is displayed. The distribution table is generated by generating the distribution table, and generating the distribution table, and transmitting the reception request message to the adjacent node on the receiving device side. The receiving device side adjacent node determines whether or not the receiving device side adjacent node continues to request the reception of the data by checking whether the reception interval of the reception request message is shorter than a predetermined time interval, When it determines that the device continues to request the reception of the data, it transmits a reception request message addressed to the transmission device at a time interval smaller than a predetermined value, and also transmits it from the adjacent node on the transmission device side. A relay method for replicating the received data and delivering it to the receiving device side adjacent node registered in the distribution table. 19. The relay method according to claim 18, wherein the information indicating itself is added to the route information in the reception request message sent from the adjacent node on the receiving device side until the distribution table is generated. To generate a new routing information, send a reception request message including the new routing information to the transmission device, and then generate the distribution table generated by the transmission device or a relay device that generated the distribution table. When the packet is transmitted from the transmitting device side adjacent node, the distribution table generating packet is transferred to the receiving device side adjacent node according to the route information in the distribution table generating packet, and the distribution table is generated. When the reception request message is sent from the adjacent node on the receiving device side after the generation of the message, the adjacent node on the receiving device side is registered in the distribution table. If so, the route information indicating the route from the receiving device to the own relay device is extracted from the reception request message to generate the distribution table generation packet including the route information, and the distribution table generation packet is generated according to the route information. A relay method for transmitting to the receiving device. 20. The relay method according to claim 18, wherein, until the distribution table is generated, the transmission source of the reception request message sent from the adjacent node on the reception device side is changed to its own relay device and transmitted. Transfer to the device side adjacent node,
After that, when the data is transmitted from the adjacent node on the transmitting device side, the distribution table is generated and the data is discarded, and after the distribution table is generated, the transmission source that has transmitted the reception request message is generated. A relay method for registering a receiving device side adjacent node in the distribution table and transmitting the data to the receiving device side adjacent node. 21. A network capable of unicast communication is used, and when data is broadcast from a transmitter to a plurality of receivers, the data is transmitted on the unicast delivery path from the transmitter to the plurality of receivers. A computer-readable medium storing a relay program for relaying data, wherein the relay program sends the plurality of receiving devices to the transmitting device as a destination at time intervals smaller than a predetermined value. A step of receiving a reception request message, and a receiving device to which the data is delivered when the data or the distribution table generation packet is received from the transmitting device side adjacent node after receiving the reception request message from the receiving device side adjacent node Generating a distribution table for registering the adjacent node on the side, and the distribution table is generated. Registering the receiving device side adjacent node that has transmitted the reception request message afterwards on the distribution table, and the receiving device side adjacency depending on whether the reception interval of the reception request message is less than a predetermined time interval. A step of determining whether the node continues to request reception of the data, and a time interval smaller than a predetermined value when it is determined that the receiving device side adjacent node continues to request reception of the data A step of sending a reception request message addressed to the transmitting device every time, and duplicating the data sent from the transmitting device-side adjacent node and delivering the data to the receiving device-side adjacent node registered in the distribution table. A computer-readable medium comprising: 22. When the data is broadcasted from a transmitting device to a plurality of receiving devices using a network capable of unicast communication, the unicast delivery path from the transmitting device to the plurality of receiving devices is used. A relay program for relaying data, comprising a step of receiving a reception request message sent by the plurality of receiving devices to the transmitting device as a destination at time intervals smaller than a predetermined value, and the receiving device side adjacency When the data or distribution table generation packet is received from the transmission device side adjacent node after receiving the reception request message from the node, a distribution table for registering the reception device side adjacent node to which the data is to be distributed is generated. And the receiving device side adjacent node that has transmitted the reception request message after the distribution table is generated. A step of registering a code in the distribution table, and determining whether the receiving-apparatus-side adjacent node continues to request reception of the data depending on whether the reception interval of the reception request message is less than a predetermined time interval. And a reception request message addressed to the transmission device at time intervals smaller than a predetermined value when it is determined that the reception device side adjacent node continues to request reception of the data. And a step of copying the data sent from the transmitter-side adjacent node and delivering the data to the receiver-side adjacent node registered in the distribution table.