JP2005051351A - Device and system for communication, program, and communication method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To speedily and accurately distribute contents from a transmission-side communication device to a plurality of reception-side communication devices and to lighten the load on the transmission-side communication device. <P>SOLUTION: A communication system 1 transmits the contents 5 from the transmission-side communication device 2 to the reception-side communication devices 31 to 3n. The transmission-side communication device 2 performs multicast distribution of the contents by using group address information specifying a multicast group. The reception-side communication devices 31 to 3n receive the contents 5 and compares version information of the received contents 5 with version information of contents 5 that other reception-side communication devices belonging to the same multicast group to provide the received contents 5 for the other reception-side communication devices when the received contents 5 have a newer version and receive contents 5 that the other reception-side communication devices from the other reception-side communication devices when the received contents 5 have an older version. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a communication device, a communication system, a program, and a communication method for communicating various contents such as data or programs via a network.
[0002]
[Prior art]
A program or data used for correcting a part of software (including rewriting, conversion, change, etc.) is called a patch. The patch is used for correcting various software such as security software.
[0003]
In general, distribution of patches is performed by a server / client method (hereinafter referred to as “S / C method”). The server holds the patch and distributes the patch to the client that corrects the software.
[0004]
In general patch distribution using the S / C method, the user operates the client to connect to the server, confirms whether the software held by the user can be upgraded, Request a patch from the server.
[0005]
As another patch delivery method using the S / C method, there is a method in which the client automatically confirms the update information of the server, and the client automatically downloads the patch from the server in accordance with the confirmation result.
[0006]
[Patent Document 1]
JP 2003-018213 A
[0007]
[Problems to be solved by the invention]
In the distribution by the conventional S / C method, when the number of clients increases, the load on the server becomes excessive. Therefore, a service provider (including a server administrator) who operates the server needs to increase the processing capacity of the server, which increases management labor and cost.
[0008]
In addition, when the load is concentrated on the server, it becomes difficult for the user to quickly connect to the server and receive a service.
[0009]
When a CD-ROM (Compact Disk-Read Only Memory) in which a patch is recorded is sent from a service provider to a user by a courier service or the like, a delivery fee is required. Further, it is necessary to perform operations such as recording patches on a CD-ROM and reading patches to the client by the user, which increases the work effort of both the service provider and the user.
[0010]
The present invention has been made in view of the above circumstances, and a communication device, a communication system, and a program for reliably and promptly providing content while preventing an overload on the content providing side The purpose is to provide a program.
[0011]
[Means for Solving the Problems]
Specific means taken for realizing the present invention will be described below.
[0012]
1st invention is based on the information which matched the distribution request which designates the content identification information which shows the content of delivery object, the multicast address information which designates the multicast group in multicast delivery, and content identification information, Using the means for acquiring multicast address information corresponding to the content identification information specified in the distribution request and the multicast address information corresponding to the content identification information specified in the distribution request, the content identification information specified in the distribution request It is a communication apparatus provided with the delivery means which performs the multicast delivery of the content to show.
[0013]
According to a second aspect of the present invention, there is provided receiving means for receiving content distributed using multicast distribution, content version information held by another device belonging to the same multicast group, and version information of content received by the receiving means, When the content received by the receiving means is the new version, the content received by the receiving means is provided to another device, and the content received by the receiving means is the old version A communication device including means for receiving content held by another device from another device.
[0014]
According to a third aspect of the present invention, information that associates a means for accepting a distribution request that specifies content identification information indicating content to be distributed, anycast address information that specifies an anycast group in anycast distribution, and content identification information. Based on the above, the anycast address information corresponding to the content identification information specified in the distribution request and the anycast address information corresponding to the content identification information specified in the distribution request are transmitted. Means for receiving anycast replies, destination determining means for determining the destination of the content indicated by the content identification information specified in the distribution request based on the receiving order of the anycast replies, and destination determination To the destination determined by the means. A communication device and means for transmitting the content indicated by the specified content identification information in the request.
[0015]
The fourth invention is the same as means for receiving an anycast request in anycast delivery, means for returning an anycast reply to the sender of the anycast request, and means for receiving content from the sender of the anycast request Means for comparing the version information of the content held by other devices belonging to the anycast group and the version information of the content received by the receiving means, and when the content received by the receiving means is a new version, A communication device that provides content received by the receiving unit to the device, and receives content held by the other device from another device when the content received by the receiving unit is an old version is there.
[0016]
A fifth invention relates to a communication system for transmitting content from a transmission side communication device to a plurality of reception side communication devices. In this communication system, a transmission side communication device performs multicast distribution of content using group address information that designates a multicast group, and a plurality of reception side communication devices include a receiving means for receiving content, and a multicast group. The means for comparing the version information of the content held by the other receiving side communication apparatus to which it belongs and the version information of the content received by the receiving means, and the other receiving side when the content received by the receiving means is a new version Means for providing the content received by the receiving means to the communication device and receiving the content held by the other receiving communication device from the other receiving communication device when the content received by the receiving means is an old version It comprises.
[0017]
A sixth invention relates to a communication system for transmitting content from a transmission side communication device to a plurality of reception side communication devices. In this communication system, the transmission side communication device includes means for receiving a distribution request for specifying content identification information indicating content to be distributed, anycast address information for specifying an anycast group in anycast distribution, and content identification information. Based on the associated information, using means for obtaining anycast address information corresponding to the content identification information specified in the distribution request, and anycast address information corresponding to the content identification information specified in the distribution request, A means for transmitting an anycast request, a means for receiving an anycast reply, and a transmission destination determination means for determining the transmission destination of the content indicated by the content identification information specified in the distribution request based on the reception order of the anycast reply And the destination determination means The transmission destination determined Te, and means for transmitting the content indicated by the specified content identification information in the distribution request. The plurality of receiving side communication devices include means for receiving an anycast request, means for returning an anycast reply, receiving means for receiving content from the transmitting side communication device, and other receiving side communication belonging to the anycast group. The means for comparing the version information of the content held by the device with the version information of the content received by the receiving means, and when the content received by the receiving means is a new version, it is received by another receiving side communication device Means for providing the content received by the means, and accepting the content held by the other receiving side communication device from the other receiving side communication device when the content received by the receiving means is an old version.
[0018]
Each means of the above inventions can be realized by reading a program into a computer. This program may be recorded on a recording medium and applied to a computer.
[0019]
Further, the content communication method is executed by the above inventions.
[0020]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings. In the following, a case where content is provided from a server to a client will be described as an example.
[0021]
Here, the contents include multimedia contents, programs, document data, policy data, patches, setting data, log information, and the like.
[0022]
In the present embodiment, a case where content is a patch will be described as an example. However, the content distributed from the server to the client is not limited to the patch, and may be various programs or data such as client setting data and policy data.
[0023]
In the following drawings, the same elements are denoted by the same reference numerals, description thereof is omitted, and only different portions will be described in detail.
[0024]
(First embodiment)
In the present embodiment, on the network, a patch is transmitted from the server to the client using multicast distribution, and then the client that has not received the patch receives a peer-to-peer (hereinafter referred to as “P2P”). ) The patch is transmitted using communication, and the patch is shared between clients.
[0025]
In multicast distribution, content transmitted from a server to a network is copied as necessary by a router in the network and received by a plurality of clients.
[0026]
FIG. 1 is a diagram illustrating a configuration example of a communication system according to the present embodiment.
[0027]
In the communication system 1, a server (transmission side communication device) 2 and clients (reception side communication devices) 31 to 3 n are connected via a network 4.
[0028]
The network 4 is a communication network that connects the server 2 and the clients 31 to 3n. As the network 4, for example, various communication media such as the Internet, a telephone line network, a wireless LAN (Local Area Network), etc., to which various contents are transmitted and received and various devices are connected are used.
[0029]
In the communication system 1, first, the patch 5 is transmitted from the server 2 to the clients 31 to 3n using multicast distribution. Next, in the communication system 1, the patch 5 is transmitted from the client that has received the patch 5 to the client that has not received the patch 5 using P2P communication.
[0030]
In FIG. 1, among the clients 31 to 3 n, the clients 31 and 33 to 35 receive the patch 5 from the server 2. Then, the patch 5 is transmitted from the clients 31, 34, 35 that have received the patch 5 to the clients 32, 3n, 36 that have not received the patch 5, respectively.
[0031]
When the patch 5 is transmitted and received between the clients 31 to 3n, the client that has received the patch 5 accesses the communication destination determination server 44 that determines the communication destination, and enters the same multicast group notified from the communication destination determination server 44. P2P communication is performed with other clients to which it belongs.
[0032]
FIG. 2 is a block diagram showing a specific configuration example of the server 2 of the communication system 1 according to the present embodiment.
[0033]
The server 2 transmits the patch 5 via the network 4 to the clients 31 to 3n using multicast distribution.
[0034]
The server 2 reads and executes the program 6a recorded on the recording medium 6, thereby realizing functions as the request processing unit 7, the distribution confirmation unit 8, the group management unit 9, and the distribution unit 10. The server 2 includes a recording unit 11. In the present embodiment, the recording unit 11 is built in the server 2, but may be a recording device external to the server 2, for example. The server 2 may access the recording unit 11 via the network 4.
[0035]
The recording unit 11 records software information 11a, distribution information 11b, group information 11c, and patch information 11d.
[0036]
As shown in FIG. 3, the software information 11a is information in which patch identification information of a patch distributed by the server 2 is associated with software identification information of software modified based on this patch.
[0037]
In the present embodiment, it is assumed that the patch identification information includes a patch name and version information. In the example of FIG. 3, the patch identification information 14 and the software identification information 15 are associated with each other.
[0038]
The distribution information 11b includes patch identification information of patches distributed from the server 2, as shown in FIG. That is, the patch indicated by the patch identification information registered in the distribution information 11b means that transmission has been completed. In the example of FIG. 4, it is shown that the patches indicated by the patch identification information 16 and 17 have been distributed.
[0039]
As shown in FIG. 5, the group information 11c associates software identification information of software that is corrected by a patch distributed by the server 2 with multicast address information indicating a multicast group to which a client having the software belongs. Information.
[0040]
For example, the group information 11c in FIG. 5 indicates that the virus removal software is included in the clients belonging to the multicast group represented by the multicast address information “3ffe: 2001 :: 2” among the clients 31 to 3n. Yes.
[0041]
In the present embodiment, there is a case where unique multicast address information need not be associated with content.
[0042]
For example, a common address information is associated with a plurality of contents, a mechanism capable of identifying each content from the common address information is implemented in an upper layer, and each content is identified from the common address information using this mechanism. May be identified.
[0043]
More specifically, the same multicast address information may be associated with a plurality of contents, and the plurality of contents may be identified by a port number in the transport layer.
[0044]
In a computer network, an application can be identified by a port number of TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). Further, in a computer network, it is possible to group data transmitted continuously with a TCP or UDP port number.
[0045]
When each content is identified using unique address information, the address information increases as the content increases, and the address information may be insufficient. However, as described above, by enabling each content to be identified from common address information in the upper layer, it becomes possible to share the address information among a plurality of contents, and it is possible to prevent a shortage of address information.
[0046]
As shown in FIG. 6, the patch information 11d is information in which a patch distributed by the server 2 is associated with patch identification information for identifying the patch.
[0047]
For example, in the example of FIG. 6, the server 2 distributes the patch 12, and the patch identification information 14 of the patch 12 indicates “virus removal.0102513”. Further, the server 2 distributes the patch 69, and it is indicated that the patch identification information of the patch 69 is “map data. 0301234”.
[0048]
In the present embodiment, patch identification information and multicast address information are indirectly associated with each other via software identification information.
[0049]
The request processing unit 7 receives the distribution request 13 from the request issuer, and recognizes the patch identification information 14 specified by the distribution request 13. Examples of the request issuer include a service provider, another system, and other elements in the server 2.
[0050]
The request processing unit 7 refers to the software information 11a recorded in the recording unit 11 and determines whether the patch identification information 14 specified by the distribution request 13 is registered in the software information 11a.
[0051]
If the patch identification information 14 is not registered in the software information 11a, the request processing unit 7 determines that the patch indicated by the patch identification information 14 specified by the distribution request 13 is not a patch distributed by the server 2, An error is returned to the issuer of the distribution request 13.
[0052]
On the other hand, when the patch identification information 14 is registered in the software information 11a, the request processing unit 7 acquires the software identification information 15 associated with the patch identification information 14 in the software information 11a. Then, the request processing unit 7 provides the patch identification information 14 and the software identification information 15 to the distribution confirmation unit 8.
[0053]
When the distribution confirmation unit 8 receives the patch identification information 14 and the software identification information 15 from the request processing unit 7, the distribution confirmation unit 8 refers to the distribution information 11 b recorded in the recording unit 11 and is newer or the same as the patch identification information 14. It is determined whether the patch identification information of the version information is registered in the distribution information 11b.
[0054]
For example, the distribution confirmation unit 8 includes patch identification information that includes the same patch name as the patch name included in the patch identification information 14 and includes version information that is newer or the same as the version information included in the patch identification information 14. It is determined whether it is registered in the distribution information 11b. For example, whether the version information is new or old is determined based on the magnitude relationship of the version information.
[0055]
When newer version information than the patch identification information 14 or patch identification information of the same version information is registered in the distribution information 11b, the distribution confirmation unit 8 has already distributed the patch indicated by the patch identification information specified in the distribution request. A certain judgment is made and an error is returned to the issuer of the distribution request 13.
[0056]
On the other hand, if the version information included in the patch identification information 14 specified in the distribution request is newer than the version information indicated by the patch identification information registered in the distribution information 11b, the distribution confirmation unit 8 determines the patch identification information. It is determined that the patch indicated by 14 has not been transmitted, and the patch identification information 14 and the software identification information 15 are provided to the group management unit 9 and the patch identification information 14 is registered in the distribution information 11b.
[0057]
When the group management unit 9 receives the patch identification information 14 and the software identification information 15 from the distribution confirmation unit 8, the group management unit 9 refers to the group information 11 c registered in the recording unit 11 and corresponds to the multicast corresponding to the software identification information 15. Address information 18 is acquired. The acquired multicast address information 18 represents a multicast distribution destination.
[0058]
Then, the group management unit 9 provides the patch identification information 14, the software identification information 15, and the multicast address information 18 to the distribution unit 10.
[0059]
The distribution unit 10 issues a command for distributing various contents to the network 4 and issues a command for receiving various contents from the network 4.
[0060]
When the distribution unit 10 receives the patch identification information 14, the software identification information 15, and the multicast address information 18 from the group management unit 9, the distribution unit 10 refers to the patch information 11 d registered in the recording unit 11 and refers to the patch identification information. 14 is obtained.
[0061]
Then, the distribution unit 10 adds the multicast address information 18 and transmits contents such as the patch identification information 14, the software identification information 15, and the patch 12 to the network 4 using multicast distribution.
[0062]
7 and 8 are flowcharts showing an example of the operation (multicast distribution stage) of the server 2 according to the present embodiment.
[0063]
In step S <b> 1, the request processing unit 7 receives the distribution request 13. The distribution request 13 may be issued by an input from the command line by the service provider. The distribution request 13 may be issued by the service provider using a graphical user interface. Further, a command for issuing a distribution request may be executed by the server 2 every elapse of a predetermined time, and the request processing unit 7 may accept the issued distribution request 13.
[0064]
For example, “% multicast-t 3000 virus removal. 0102513” is issued as the distribution request 13. In this distribution request 13, “multicast” is an instruction name, “−t 3000” indicates an instruction to distribute after 3000 seconds, and “virus removal” indicates the name of a patch to be distributed. “0102513” below “.” Represents patch version information. That is, “virus removal.0102513” is the patch identification information 14 specified in the distribution request 13.
[0065]
In step S <b> 2, the request processing unit 7 performs option analysis and recognition of the patch identification information 14 indicating the patch to be transmitted based on the distribution request 13.
[0066]
In step S <b> 3, the request processing unit 7 refers to the software information 11 a and determines whether software identification information corresponding to the patch identification information 14 designated by the distribution request 13 is registered. Based on the presence or absence of registration, it is determined whether or not the patch indicated by the patch identification information 14 specified in the distribution request 13 is a patch to be distributed by the server 2.
[0067]
If the software identification information corresponding to the patch identification information 14 is not registered in the software information 11a, in step S4, the request processing unit 7 returns an error to the distribution request source and ends the process.
[0068]
When the software identification information corresponding to the patch identification information 14 is registered in the software information 11a, the software identification information 15 corresponding to the patch identification information 14 is acquired in step S5, and the patch identification information 14, the software identification information 15, Is provided to the delivery confirmation unit 8.
[0069]
In step S <b> 6, when the distribution confirmation unit 8 receives the patch identification information 14 and the software identification information 15 from the request processing unit 7, the distribution confirmation unit 8 refers to the distribution information 11 b and indicates the patch identification information 14 specified by the distribution request 13. It is determined whether the version information is newer than the version information indicated by the patch identification information registered in the distribution information 11b. When the version information indicated by the patch identification information 14 is newer than the version information indicated by the patch identification information registered in the distribution information 11b, it is determined that the distribution has not been performed. On the other hand, if the version information indicated by the patch identification information 14 is the same as or older than the version information indicated by the patch identification information registered in the distribution information 11b, it is determined that the distribution has been completed.
[0070]
If the version information indicated by the patch identification information 14 is the same as or older than the version information indicated by the patch identification information registered in the distribution information 11b, the distribution confirmation unit 8 returns an error to the distribution request source in step S7, Exit.
[0071]
On the other hand, if the version information indicated by the patch identification information 14 is newer than the version information indicated by the patch identification information registered in the distribution information 11b, in step S8, the distribution confirmation unit 8 determines that the patch identification information 14 and the software identification information 15 Is provided to the group management unit 9.
[0072]
In step S9, the distribution confirmation unit 8 registers the patch identification information 14 in the distribution information 11b.
[0073]
In step S10, when the group management unit 9 receives the patch identification information 14 and the software identification information 15 from the distribution confirmation unit 8, the group management unit 9 refers to the group information 11c and acquires the multicast address information 18 corresponding to the software identification information 15. To do. The multicast address information 18 corresponding to the software identification information 15 is a multicast distribution destination. When a multicast group is targeted only within the local site, addresses from 224.0.0.1 to 224.0.0.255 need to be specified by multicast address information, and the entire Internet is a multicast group. In this case, addresses from 224.0.1.0 to 238.255.255.255 need to be specified by the multicast address information.
[0074]
In step S <b> 11, the group management unit 9 provides the patch identification information 14, software identification information 15, and multicast address information 18 to the distribution unit 10.
[0075]
In step S12, when receiving the patch identification information 14, the software identification information 15, and the multicast address information 18 from the group management unit 9, the distribution unit 10 refers to the patch information 11d and acquires the patch 12 corresponding to the patch identification information 14. To do.
[0076]
In step S <b> 13, the distribution unit 10 performs multicast distribution for the multicast group indicated by the multicast address information 18 for the patch 12, the patch identification information 14, and the software identification information 15. The distribution unit 10 may execute multicast distribution to the multicast group indicated by the multicast address information 18 for content other than the patch 12, the patch identification information 14, and the software identification information 15.
[0077]
Note that step S9 may be executed at any time after step S6.
[0078]
FIG. 9 is a block diagram showing a specific configuration example of the client 31 according to the present embodiment. The same applies to the configuration examples of the other clients 32 to 3n.
[0079]
The client 31 receives content such as the patch 5, patch identification information 14, and software identification information 15 from the server 2 via the network 4, and transmits or receives content with any of the other clients 32 to 3n. In the present embodiment, a case where the client 31 and the client 32 belong to the same multicast group will be described.
[0080]
The client 31 reads and executes the program 19a recorded in the recording medium 19 to thereby execute the multicast reception unit 20, reception confirmation unit 21, version management unit 22, patch processing unit 23, communication destination acquisition unit 24, communication permission Functions as the unit 25, the authentication unit 26, the version comparison unit 27, the content communication unit 28, and the P2P communication unit 41 are realized. The client 31 includes a recording unit 29. In the present embodiment, the recording unit 29 is built in the client 31, but may be a recording device external to the client 31, for example. The client 31 may access the recording unit 29 via the network 4.
[0081]
The recording unit 29 records version management information 29a, patch information 29b, software management information 29c, communication permission information 29d, and group management information 29e.
[0082]
As shown in FIG. 10, the version management information 29a associates the software identification information of the software held in the client 31 with the patch identification information of the patch received by the client 31 and used for the correction process of the software. Information. In the example of FIG. 10, software identification information 15 and patch identification information 16 are associated with each other.
[0083]
The patch information 29b is information that associates the patch held in the client 31 with the patch identification information. For example, the information is recorded in the same format as in FIG.
[0084]
As shown in FIG. 11, the software management information 29c is information that associates software held in the client 31 with software identification information. In the example of FIG. 11, software identification information 15 and software 40 are associated with each other.
[0085]
The communication permission information 29d is information including a log or the like indicating which client 31 has communicated with and what content has been transmitted / received when the client 31 performs P2P communication with another client. It is.
[0086]
In the present embodiment, it is assumed that the communication permission information 29d includes identification information, a communication start time, and a communication end time of a communication destination client determined as a communication destination for communication between clients. By referring to the communication permission information 29d, it can be determined whether or not the client 31 is communicating with the other clients 32 to 3n.
[0087]
As shown in FIG. 12, the group management information 29e includes software identification information held in the client 31, address information of a server that transmits a patch related to software indicated by the software identification information, and software indicated by the software identification information. Information relating to the group identification information of the multicast group to which the client 31 belongs.
[0088]
In FIG. 12, software identification information 15, server address information 42, and group identification information 43 are associated with each other.
[0089]
The multicast receiving unit 20 refers to the group management information 29e recorded in the recording unit 29, and in the multicast distribution, group identification information 43 indicating the multicast group to which the client 31 belongs, and address information 42 of the server 2 that performs this multicast distribution, To get.
[0090]
The multicast receiving unit 20 refers to the group management information 29e recorded in the recording unit 29, and transmits an IGMP Join message to the server 2 indicated by the server address information 42 in order to belong to the multicast group indicated by the group identification information 43. .
[0091]
A router (not shown) on the network 4 on the way from the client 31 to the server 2 understands the IGMP Join message. Then, if the network connected to the port that received the IGMP Join message is not stored in this router and registered in the table for registering the multicast group, the router sets the port that received the IGMP Join message to the port that received the IGMP Join message. Register connected network information in the table.
[0092]
Thereby, a communication path for executing multicast distribution between the server 2 and the client 31 is secured.
[0093]
The content transmitted from the server 2 to the multicast group passes through the route secured by this process. The router copies the received content and transmits it from each registered port. As a result, multicast distribution of content is executed toward clients belonging to the same multicast group. In multicast distribution, communication is performed by UDP (User Datagram Protocol).
[0094]
The multicast receiving unit 20 receives contents such as the patch 12, patch identification information 14, and software identification information 15 transmitted from the server 2 using multicast distribution, and provides them to the reception confirmation unit 21.
[0095]
The reception confirmation unit 21 determines the integrity of the patch 12, patch identification information 14, and software identification information 15 received from the multicast reception unit 20.
[0096]
If the patch 12, the patch identification information 14, and the software identification information 15 are incomplete, the reception confirmation unit 21 discards the received patch 12, patch identification information 14, and software identification information 15.
[0097]
On the other hand, when the patch 12, the patch identification information 14, and the software identification information 15 are complete, the reception confirmation unit 21 provides the received patch 12, patch identification information 14, and software identification information 15 to the version management unit 22.
[0098]
When receiving the patch 12, patch identification information 14, and software identification information 15 from the reception confirmation unit 21, the version management unit 22 refers to the version management information 29 a recorded in the recording unit 29.
[0099]
The version management unit 22 includes the same patch name as the patch name included in the patch identification information 14 received from the server 2, and includes patch identification including version information that is newer than or the same as the version information included in the patch identification information 14. It is determined whether the information is registered in the version management information 29a. In other words, the version management unit 22 determines whether a patch having a version newer than or the same as the patch 12 received from the server 2 has been received.
[0100]
When version information newer than the patch identification information 14 or patch identification information of the same version information is registered in the version management information 29a, the version management unit 22 discards the patch 12, the patch identification information 14, and the software identification information 15.
[0101]
On the other hand, when the version information included in the patch identification information 14 is newer than the version information of the patch identification information registered in the version management information 29a, the version management unit 22 determines that the patch 12 indicated by the patch identification information 14 is not yet present. It is determined that it is received, the patch identification information 14 and the software identification information 15 are associated with each other and registered in the version management information 29a, and the patch 12 and the patch identification information 14 are associated with each other and registered in the patch information 29b. Information 14 and software identification information 15 are provided to the patch processing unit 23.
[0102]
When the patch processing unit 23 receives the patch identification information 14 and the software identification information 15 from the version management unit 22 or the content communication unit 28, the patch processing unit 23 acquires the latest version of the patch 12 corresponding to the patch identification information 14 from the patch information 29b. The software 40 corresponding to the software identification information 15 is acquired from the software management information 29c, the software 40 is corrected using the patch 12, and the corrected software 40 is registered in the software management unit 29c instead of the software 40 before the correction. To do.
[0103]
The communication destination determination server 44 registers each of the clients 31 to 3n when the clients 31 to 3n are activated.
[0104]
The communication destination determination server 44 acquires software identification information indicating software held by each client 31 to 3n from each client 31 to 3n.
[0105]
The communication destination determination server 44 determines a client that performs P2P communication from among clients that hold common software among the clients 31 to 3n, and sets a communication destination for each client that is determined to perform P2P communication. provide. In the present embodiment, a case will be described in which the client 31 is determined as a client that performs communication, and the client 32 is determined as a communication destination of the client 31.
[0106]
Further, if there is no access after a certain period of time has elapsed from the registered client, the communication destination determination server 44 determines that this client has stopped and cancels the registration.
[0107]
The P2P communication unit 41 of the client 31 performs P2P communication with other clients 32 to 3n, and transmits and receives various contents.
[0108]
The communication destination acquisition unit 24 registers in the communication destination determination server 44 when the client 31 is activated.
[0109]
Further, the communication destination acquisition unit 24 refers to the software management information 29c recorded in the recording unit 29, and obtains software identification information of software held in the client 31 every time a predetermined period elapses. To provide.
[0110]
When receiving the designation of the communication destination client 32 from the communication destination determination server 44, the communication destination acquisition unit 24 provides the designation of the communication destination client 32 to the communication permission unit 25.
[0111]
When the communication permission unit 25 receives the designation of the communication destination client 32 from the communication destination acquisition unit 24, the communication permission unit 25 accesses the communication destination client 32 via the P2P communication unit 41, and the communication destination client 32 receives the other clients 33 to 33. It is determined whether communication with 3n is in progress.
[0112]
When the communication destination client 32 is not communicating with another client, the communication permission unit 25 provides the authentication unit 26 with the designation of the communication destination client 32. If the communication destination client 32 is communicating, the process ends. When the communication destination client 32 is communicating, the process may be in a waiting state.
[0113]
When the authentication unit 26 receives designation of the communication destination client 32 from the communication permission unit 25, the authentication unit 26 accesses the communication destination client 32 via the P2P communication unit 41 and performs mutual authentication.
[0114]
When the authentication is properly performed, the authentication unit 26 registers the communication start time in the communication permission information 29d of the recording unit 29, and provides the version comparison unit 27 with the designation of the communication destination client 32. If authentication is not properly performed, the process is stopped.
[0115]
When the designation of the communication destination client 32 is received from the authentication unit 26, the version comparison unit 27 refers to the version management information 29 a recorded in the recording unit 29 and also communicates with the communication destination client 32 via the P2P communication unit 41. To obtain the version management information 29a of the client 32. Thereby, the two version management information 29a to be compared is acquired.
[0116]
The version comparison unit 27 compares the version management information 29a of the client 31 with the version management information 29a of the communication destination client 32, and provides the comparison result and the designation of the communication destination client 32 to the content communication unit 28. .
[0117]
When the patch 12 held by the client 31 is newer than the patch held by the client 32 of the communication destination, the content communication unit 28 transmits the held patch 12, patch identification information 14, and software identification information 15 to the P2P communication unit 41. To the client 32 of the communication destination.
[0118]
When the patch 12 held by the client 31 is older than the patch held by the communication destination client 32, the content communication unit 28 holds the communication destination client 32 from the communication destination client 32 via the P2P communication unit 41. A patch, patch identification information, and software identification information are received. Then, the content communication unit 28 performs registration in the version management information 29a and the patch information 29b based on the patch received from the communication destination client 32, the patch identification information, and the software identification information. The patch identification information 14 and the software identification information 15 are provided to the patch processing unit 23.
[0119]
In addition, the content communication unit 28 registers the communication end time in the communication permission information 29 d recorded in the recording unit 29.
[0120]
FIG. 13 is a flowchart showing an example of processing when the client 31 according to the present embodiment receives content distributed by multicast from the server 2.
[0121]
In step T1, the multicast receiving unit 20 refers to the group management information 29e recorded in the recording unit 29, and in multicast distribution, the group identification information 43 indicating the multicast group to which the client 31 belongs and multicast distribution to this multicast group. It recognizes the address information 42 of the server 2 that executes.
[0122]
In step T2, since the multicast receiver 20 belongs to the multicast group indicated by the group identification information 43, the multicast receiver 20 transmits an IGMP Join message to the server 2 indicated by the address information.
[0123]
In step T <b> 3, the multicast receiver 20 receives content such as the patch 12, patch identification information 14, and software identification information 15 transmitted from the server 2 using multicast distribution.
[0124]
In step T <b> 4, the reception confirmation unit 21 determines the integrity of the patch 12, patch identification information 14, and software identification information 15 received from the multicast reception unit 20.
[0125]
If the determination result by the reception confirmation unit 21 indicates incomplete, in step T5, the reception confirmation unit 21 discards the received patch 12, patch identification information 14, and software identification information 15, and ends the process.
[0126]
On the other hand, if the determination result by the reception confirmation unit 21 indicates complete, the version management unit 22 refers to the version management information 29a recorded in the recording unit 29 in step T6.
[0127]
In step T7, the version management unit 22 determines whether the version of the patch 12 received from the server 2 is new.
[0128]
If the version of the patch 12 received from the server 2 is not new, in step T8, the version management unit 22 discards the patch 12, the patch identification information 14, and the software identification information 15, and ends the process.
[0129]
On the other hand, when the version of the patch 12 received from the server 2 is new, in step T9, the version management unit 22 registers the patch identification information 14 and the software identification information 15 in association with each other in the version management information 29a, and also updates the patch 12 And the patch identification information 14 are registered in the patch information 29b in association with each other.
[0130]
In step T10, the patch processing unit 23 modifies the software 40 using the latest version of the patch 12, and registers the modified software 40 in the software management information 29c instead of the unmodified software 40.
[0131]
14 and 15 are flowcharts showing an example of processing for transmitting and receiving content by P2P communication between the client 31 and another client 32 according to the present embodiment.
[0132]
In step U <b> 1, the communication destination acquisition unit 24 registers in the communication destination determination server 44 when the client 31 is activated.
[0133]
In step U2, the communication destination acquisition unit 24 determines whether a certain time has elapsed.
[0134]
In step U3, the communication destination acquisition unit 24 accesses the communication destination determination server 44 when a predetermined time has elapsed, and provides information of the recording unit 29 such as software management information 29c, for example. If it is before a certain period of time, it will be in a waiting state.
[0135]
In step U <b> 4, the communication destination acquisition unit 24 accepts designation of the communication destination client 32 from the communication destination determination server 44.
[0136]
In step U5, the communication permission unit 25 accesses the communication destination client 32 via the P2P communication unit 41, and determines whether or not the communication destination client 32 is communicating with the other clients 33 to 3n.
[0137]
When the communication destination client 32 is communicating, the communication permission unit 25 ends the process or waits.
[0138]
When the communication destination client 32 is not communicating, in step U6, the authentication unit 26 accesses the communication destination client 32 via the P2P communication unit 41 and performs mutual authentication.
[0139]
If the authentication is not properly performed, the authentication unit 26 stops the process.
[0140]
If the authentication is properly performed, the authentication unit 26 registers the communication start time in the communication permission information 29d of the recording unit 29 in step U7.
[0141]
In step U8, the version comparison unit 27 refers to the version management information 29a recorded in the recording unit 29, accesses the communication destination client 32 via the P2P communication unit 41, and compares the version of the client 31 to be compared. The management information 29a and the version management information 29a of the communication destination client 32 are acquired.
[0142]
In step U9, the version comparison unit 27 compares the version management information 29a of the client 31 with the version management information 29a of the client 32 that is the communication destination.
[0143]
When the patch 12 held by the client 31 is newer than the patch held by the communication destination client 32, in step U10, the content communication unit 28 performs P2P communication between the patch 12, the patch identification information 14, and the software identification information 15. The data is provided to the communication destination client 32 via the unit 41.
[0144]
In step U11, the content communication unit 28 registers the communication end time in the communication permission information 29d recorded in the recording unit 29.
[0145]
When the patch 12 held by the client 31 is older than the patch held by the communication destination client 32, in step U12, the content communication unit 28 determines the patch, patch identification information, and software identification held by the communication destination client 32. Information is received from the communication destination client 32 via the P2P communication unit 41 and recorded in the recording unit 29.
[0146]
In step U13, the patch processing unit 23 corrects the software using the latest version of the patch, and registers the corrected software in the software management information 29c instead of the software before the correction.
[0147]
In step U14, the content communication unit 28 registers the communication end time in the communication permission information 29d recorded in the recording unit 29.
[0148]
Steps U13 and U14 may be executed in reverse order or in parallel.
[0149]
FIG. 16 is a sequence diagram illustrating an example of the cooperative operation of the communication system 1. In FIG. 16, the communication destination determination server 44 is used when determining the communication destination of P2P communication between clients.
[0150]
FIG. 16 shows an example in which content such as a patch is transmitted from the server 2 to the clients 31 and 32 and then content such as a patch is transmitted from the client 31 to the client 32.
[0151]
The transmission of content by the communication system 1 includes a multicast distribution stage in which transmission using multicast distribution is performed and an inter-client communication stage in which transmission using P2P communication is performed between clients.
[0152]
First, the multicast distribution stage in FIG. 16 will be described.
[0153]
The request processing unit 7 of the server 2 executes option analysis for the distribution request 13 and recognition of patch identification information 14 indicating a distribution target patch.
[0154]
Further, the request processing unit 7 refers to the software information 11 a and confirms whether the patch 12 indicated by the patch identification information 14 designated by the distribution request 13 is a distribution target of the own server 2.
[0155]
If the patch identification information 14 specified in the distribution request 13 is not registered in the software information 11a and is not a distribution target by the own server 2, the request processing unit 7 returns an error to the distribution request 13 and ends the process. To do.
[0156]
The distribution confirmation unit 8 refers to the distribution information 11b and determines whether the patch identification information 14 designated by the distribution request 13 is registered.
[0157]
When the patch identification information 14 is registered in the distribution information 11b, the distribution completion confirmation unit 8 determines that the patch 12 indicated by the patch identification information 14 specified by the distribution request 13 has been distributed, and determines the distribution request source. An error is returned and the process ends.
[0158]
On the other hand, when the patch identification information 14 is not registered in the distribution information 11b, the distribution confirmation unit 8 determines that the patch 12 indicated by the patch identification information 14 specified in the distribution request 13 has not been distributed, and performs group management. The processing is moved to part 9.
[0159]
The group management unit 9 refers to the group information 11c, and acquires multicast address information 18 indicating the multicast group to which the clients 31 and 32 holding the software corrected by the distribution target patch 12 belong.
[0160]
The distribution unit 10 refers to the patch information 11 d and acquires the patch 12 corresponding to the patch identification information 14 specified by the distribution request 13.
[0161]
Then, the distribution unit 10 transmits contents such as the patch 12, patch identification information 14, and software identification information 15 to the clients 31 and 32 belonging to the multicast group indicated by the multicast address information 18 by using multicast distribution.
[0162]
Prior to the execution of multicast distribution as described above, the multicast receivers 20 of the clients 31 and 32 execute pre-processing for handling multicast distribution.
[0163]
After the multicast distribution is executed, the multicast receiver 20 of the clients 31 and 32 receives the content transmitted from the server 2.
[0164]
The reception confirmation unit 21 of the clients 31 and 32 confirms the integrity of the received content.
[0165]
In the example of FIG. 16, it is assumed that the content received from the server 2 to the client 31 is complete, but the content received from the server 2 to the client 32 is incomplete.
[0166]
The version management unit 22 of the client 31 refers to the version management information 29a, compares the received content version with the version registered in the version management information 29a, and determines whether the received content is a new version.
[0167]
If the received content is not a new version, the version management unit 22 of the client 31 returns the process to a standby state for multicast distribution.
[0168]
When the received content is a new version, the version management unit 22 registers the received content in the recording unit 29.
[0169]
The patch processing unit 23 corrects the software based on the received content.
[0170]
On the other hand, the reception confirmation unit 21 of the client 32 discards the received content when the received content is incomplete.
[0171]
Next, the inter-client communication stage in FIG. 16 will be described.
[0172]
In the client communication stage, each client 31 and 32 shares and updates content with other clients belonging to the same multicast group.
[0173]
The content shared between the clients 31 and 32 is content transmitted from the server 2 to each of the clients 31 and 32 using multicast distribution.
[0174]
In FIG. 16, the client 32 has been discarded because the content received from the server 2 is not complete. Therefore, among the clients 31 and 32 belonging to the same multicast group, the client 31 that holds the new version of the content and the client 32 that does not hold the content are mixed.
[0175]
In the inter-client communication stage, content is transmitted and received between the client 31 that holds the content received by multicast distribution and the client 32 that does not hold it.
[0176]
The communication destination acquisition unit 24 of the clients 31 and 32 accesses the communication destination determination server 44 when activated.
[0177]
The communication destination determination server 44 registers the clients 31 and 32 in response to access from the clients 31 and 32.
[0178]
Thereafter, the communication destination acquisition unit 24 of each of the clients 31 and 32 accesses the communication destination determination server 44 every time a fixed time elapses to request designation of the communication destination client (communication destination information). Get the specification.
[0179]
The communication destination determination server 44 determines that a client that does not require designation of a communication destination client even after a predetermined time has elapsed, and deletes the registered information.
[0180]
Here, in FIG. 16, it is assumed that the communication destination determination server 44 determines to provide content from the client 31 to the client 32. The communication destination acquisition unit 24 of the client 31 connects to the communication destination determination server 44 and acquires the designation of the communication destination client 32.
[0181]
The client 31 requests connection to the communication destination client 32 based on the acquired designation of the communication destination client 32.
[0182]
Connection from the client 31 to the client 32 is performed, for example, according to the following processing.
[0183]
First, the communication permission unit 25 of the client 31 transmits a connection request to the communication destination client 32 using the P2P communication unit 41.
[0184]
The communication permission unit 25 of the communication destination client 32 that has received the connection request accepts the connection request, refers to the communication permission information 29d recorded in the recording unit 29 of the client 32, and the communication destination client 32 receives another client. Make sure that there is no communication between them.
[0185]
When the communication destination client 32 is communicating, the communication permission unit 25 of the communication destination client 32 returns a connection rejection message to the client 31 using the P2P communication unit 41.
[0186]
When the communication destination client 32 is not communicating, the authentication unit 26 of the client 31 uses the P2P communication unit 41 to perform mutual authentication in cooperation with the authentication unit 26 of the communication destination client 32, and authenticate. Check if you are a communication partner.
[0187]
The authentication unit 26 of each client 31, 32 confirms the group to which each client 31, 32 belongs, for example, using a group signature. The authentication unit 26 of the client 31 also checks the group to which the communication destination client 32 belongs.
[0188]
When the authentication is correctly performed, the authentication unit 26 of the communication destination client 32 registers the information of the client 31 and the communication start time in the communication permission information 29d of the communication destination client 32 using the P2P communication unit 41. The connection establishment response message is transmitted to the client 31.
[0189]
When receiving the response message, the authentication unit 26 of the client 31 registers the information of the communication destination client 32 and the communication start time in the communication permission information 29 d of the client 31.
[0190]
When the connection is established, the version comparison unit 27 of the client 31 uses the P2P communication unit 41 in cooperation with the version comparison unit 27 of the client 32 of the communication destination, and the version information of the patches held in the clients 31 and 32 Confirm.
[0191]
For example, the version comparison unit 27 of the client 31 provides the version management information 29a of the client 31 to the version comparison unit 27 of the client 32 that is the communication destination.
[0192]
The version comparison unit 27 of the communication destination client 32 compares the received version management information 29 a of the client 31 with the version management information 29 a of the communication destination client 32.
[0193]
When the version of the client 31 is newer than the version of the communication destination client 32, the version comparison unit 27 of the communication destination client 32 transmits a reception request message to the client 31.
[0194]
When the version of the client 31 is older than the version of the communication destination client 32, the version comparison unit 27 of the communication destination client 32 transmits a transmission request message to the client 31.
[0195]
When the versions are the same, the version comparison unit 27 of the communication destination client 32 transmits a message to the client 31 indicating that the versions are the same.
[0196]
When the client 31 receives a reception request message from the client 32 of the communication destination, the content communication unit 28 of the client 31 acquires content such as a patch, patch identification information, and software identification information recorded in the recording unit 29. It transmits to the client 32 of a communication destination using the P2P communication part 41, P2P communication is complete | finished, and communication end time is registered into the communication permission information 29d.
[0197]
When the client 31 receives a transmission request message from the communication destination client 32, the content communication unit 28 of the client 31 records the content provided from the content communication unit 28 of the communication destination client 32 in the recording unit 29 of the client 31. Then, the P2P communication is terminated, and the communication end time is registered in the communication permission information 29d.
[0198]
When the message indicating that the client 31 is the same version is received from the client 32 of the communication destination, the content communication unit 28 of the client 31 ends the P2P communication and registers the communication end time in the communication permission information 29d.
[0199]
In the P2P communication executed between the clients 31 and 32, since TCP communication is used, data integrity is guaranteed.
[0200]
In the communication system 1 according to the present embodiment described above, first, content is transmitted from the server 2 to the clients 31 to 3n using multicast distribution.
[0201]
Thereby, the total amount of data transmitted from the server 2 can be reduced, and the labor and cost relating to the server capability enhancement of the service provider can be suppressed.
[0202]
In this embodiment, when content is not normally received by all clients in transmission of content from the server to the client using multicast distribution, the content is normally received from the client that has received the content normally. The content is transmitted to the client that has not been received, and the content distribution is supplemented.
[0203]
Thereby, each client can acquire content reliably and rapidly.
[0204]
(Second Embodiment)
In the present embodiment, a modification of the first embodiment will be described. In the first embodiment, content is transmitted from the server to the client using multicast distribution, and then P2P communication is performed between the clients to complement the multicast distribution.
[0205]
However, in this embodiment, anycast distribution is used instead of multicast distribution.
[0206]
In the present embodiment, a client to which content is provided from the server is determined using anycast distribution, and the content is provided from the server to the determined client. Then, the content is distributed from the determined client to other clients.
[0207]
In the present embodiment, it is assumed that P2P communication is used in the same manner as in the first embodiment for transmitting / receiving content between clients.
[0208]
Anycast distribution is a function implemented in IPv6 (Internet Protocol Version 6). Anycast distribution is used for applications such as selecting the one with the lightest load from a designated DNS (Domain Name System) server.
[0209]
In the anycast distribution, the server transmits an anycast request to a plurality of clients belonging to the anycast group, and receives an anycast reply that is a response to the anycast request from each client.
[0210]
Then, the server recognizes the load level of each client based on the anycast reply.
[0211]
FIG. 17 is a diagram illustrating an example of a state of anycast distribution by the communication system according to the present embodiment.
[0212]
In the communication system 45, a server 46, clients 471 to 47 n and a communication destination determination server 44 are connected via a subnetwork 48. The clients 471 to 47n connected to the subnetwork 48 are represented by a common network address.
[0213]
In the communication system 45, first, an anycast request is transmitted from the server 46 to the clients 471 to 47n by anycast distribution. Next, the anycast reply is returned to the server 46 from the clients 471 to 47n that have received the anycast request.
[0214]
Next, the server 46 determines a client with a light load based on the anycast reply received from each of the clients 471 to 47n. In the example of FIG. 17, the case where the load of the client 471 is the lightest among the clients 471 to 47n is shown.
[0215]
Then, the content including the patch 5 and the like is transmitted from the server 46 to the determined client 471. When content is transmitted from the server 46 to the client 471, the content may be signed.
[0216]
In the present embodiment, description will be made assuming that all of the clients 471 to 47n belong to the anycast group that is the target of anycast distribution.
[0217]
The subnetwork 48 is a communication network that is represented by the same network address or broadcast address and is not divided by a router or a switch, and may be wireless or wired. Anycast requests, anycast replies, and contents are transmitted and received via the subnetwork 48.
[0218]
FIG. 18 is a diagram illustrating an example of a state of communication between clients by the communication system 45 according to the present embodiment.
[0219]
The content is transmitted from the client 471 that has received the content from the server 46 to the other clients 472 to 47n using P2P communication. The same method as in the first embodiment can be applied to the transmission / reception of content between the clients 471 to 47n, and the description thereof will be omitted in this embodiment.
[0220]
FIG. 19 is a block diagram illustrating a specific configuration example of the server 46 of the communication system 45 according to the present embodiment.
[0221]
The server 46 reads and executes the program 49a recorded in the recording medium 49, whereby a request processing unit 50, an address acquisition unit 51, a request transmission unit 52, a reply reception unit 53, a distribution destination determination unit 54, a distribution unit. The function as 55 is realized. The server 46 includes a recording unit 56. In the present embodiment, the recording unit 56 is built in the server 46. However, for example, a recording device external to the server 46 may be used. The server 46 may access the recording unit 56 via the subnetwork 48.
[0222]
The recording unit 56 records software information 11a, address management information 56a, reply management information 56b, distribution information 56c, and patch information 11d.
[0223]
Since the software information 11a and the patch information 11d recorded in the recording unit 56 are the same as those in the first embodiment, description thereof is omitted.
[0224]
As shown in FIG. 20, the address management information 56a includes software identification information of software to be corrected by a patch distributed from the server 46, anycast address information indicating an anycast group to which a client holding the software belongs. Is information associated with each other. For example, in this address management information 56a, anycast address information 57 having the content “3ffe: 2001 :: 2” is associated with the software identification information 15 having the content “virus removal software”. The address management information 56 a in FIG. 20 indicates that the virus removal software represented by the software identification information 15 is provided in a client belonging to the anycast group represented by the anycast address information 57.
[0225]
In the present embodiment also, there is a case where unique anycast address information does not have to be associated with content for the same reason as in the first embodiment.
[0226]
As shown in FIG. 21, the reply management information 56b is information that holds the anycast replies 581 to 58n received from the clients 471 to 47n by the reply receiving unit 53 in a state where the reception order can be recognized.
[0227]
The reply management information 56b in FIG. 21 shows a case where anycast replies 581 to 58n are received in the order of the clients 471 to 47n.
[0228]
The anycast reply 581 to 58n includes address information 591 to 59n of the transmission source clients 471 to 47n.
[0229]
As shown in FIG. 22, the distribution information 56c is information in which patch identification information is associated with address information of a destination client that has transmitted the patch indicated by the patch identification information. In the example of FIG. 22, the patch identification information 14 having the content “virus removal.0102513” is associated with the address information 60 having the content “3ffe: 2001: 30”.
[0230]
In the present embodiment, patch identification information and anycast address information are indirectly associated with each other via software identification information.
[0231]
The request processing unit 50 receives the distribution request 61 from the request issuer, and recognizes the patch identification information 14 specified by the distribution request 61.
[0232]
Further, the request processing unit 50 refers to the software information 11a recorded in the recording unit 56, and determines whether the patch identification information 14 designated by the distribution request 61 is registered in the software information 11a.
[0233]
When the patch identification information 14 is not registered in the software information 11a, the request processing unit 50 determines that the patch indicated by the patch identification information 14 specified by the distribution request 61 is not a patch distributed by the server 46, An error is returned to the issuer of the distribution request 61.
[0234]
On the other hand, when the patch identification information 14 is registered in the software information 11a, the request processing unit 50 acquires the software identification information 15 corresponding to the patch identification information 14 from the software information 11a. Then, the request processing unit 50 provides the patch acquisition information 14 and the software identification information 15 to the address acquisition unit 51.
[0235]
When receiving the patch identification information 14 and the software identification information 15 from the request processing unit 50, the address acquisition unit 51 refers to the address management information 56a recorded in the recording unit 56.
[0236]
The address acquisition unit 51 determines whether anycast address information corresponding to the software identification information 15 received from the request processing unit 50 is registered in the address management information 56a.
[0237]
When anycast address information corresponding to the software identification information 15 is not registered in the address management information 56a, the address acquisition unit 51 distributes the patch indicated by the patch identification information 14 specified in the distribution request 61 by the server 46. It is determined that the patch is not a patch, and an error is returned to the issuer of the distribution request 61.
[0238]
When anycast address information corresponding to the software identification information 15 is registered in the address management information 56a, the address acquisition unit 51 distributes the patch indicated by the patch identification information 14 specified in the distribution request 61 by the server 46. The anycast address information 57 corresponding to the software identification information 15 is acquired.
[0239]
Then, the address acquisition unit 51 provides the patch transmission information 52 with the patch identification information 14, the software identification information 15, and the anycast address information 57.
[0240]
Upon receiving the patch identification information 14, the software identification information 15, and the anycast address information 57 from the address acquisition unit 51, the request transmission unit 52 transmits an anycast request in anycast address distribution based on the anycast address information 57. . The anycast request transmitted from the request transmission unit 52 of the server 46 includes address information indicating the server 46.
[0241]
The reply receiving unit 53 receives anycast replies 581 to 58n from the clients 471 to 47n that have received the anycast requests.
[0242]
Then, the reply receiving unit 53 registers the anycast replies 581 to 58n in the reply management information 56b according to the reception order, and provides the patch identification information 14 and the software identification information 15 to the distribution destination determining unit 54.
[0243]
When receiving the patch identification information 14 and the software identification information 15, the distribution destination determination unit 54 refers to the reply management information 56b.
[0244]
The delivery destination determination unit 54 acquires the anycast reply 581 received first among the anycast replies 581 to 58n registered in the reply management information 56b, and is included in the anycast reply 581 received in this re-election. Address information 591 is obtained.
[0245]
Then, the delivery destination determination unit 54 refers to the delivery information 56c recorded in the recording unit 56, and determines whether information in which the patch identification information 14 and the address information 591 are associated is registered in the delivery information 56c.
[0246]
When the information relating the patch identification information 14 and the address information 591 is not registered in the distribution information 56c, the distribution destination determination unit 54 determines the client indicated by the acquired address information 591 as the distribution destination, and the address information 591. And the patch identification information 14 and the software identification information 15 are provided to the distribution unit 55. That is, when the information relating the patch identification information 14 and the address information 591 is not registered in the distribution information 56c, the patch indicated by the patch identification information 14 is not transmitted to the client 471 indicated by the address information 591. It is judged.
[0247]
On the other hand, when information relating the patch identification information 14 and the address information 591 is registered in the distribution information 56c, the distribution destination determination unit 54 determines that the patch indicated by the patch identification information 14 is the client 471 indicated by the address information 591. It is determined that it has already been sent. Then, the delivery destination determination unit 54 refers to the reply management information 56b, acquires the anycast reply 582 received next to the previously acquired anycast reply 581, and performs the above-described processing for the newly acquired anycast reply 582. A process similar to the process for the anycast reply 581 is executed. As a result, the client that has returned the anycast reply first among the clients that have not transmitted the patch indicated by the patch identification information 14 is determined as the delivery destination.
[0248]
In the present embodiment, it is assumed that the delivery destination determination unit 54 determines the client 471 indicated by the address information 591 as the delivery destination.
[0249]
When the distribution unit 55 receives the patch identification information 14, the software identification information 15, and the address information 591 from the distribution destination determination unit 54, first, in order to compare the version with the client 471 indicated by the address information 591, the distribution unit 55 The patch identification information 14 is transmitted to 471.
[0250]
The client 471 includes the same patch name as the patch name included in the patch identification information 14 received from the server 46, and searches for the patch identification information registered in the client 471.
[0251]
Then, the client 471 compares the version information included in the received patch identification information 14 with the version information included in the searched patch identification information.
[0252]
If the version information included in the received patch identification information 14 is newer, the client 471 returns a content transmission request to the server 47.
[0253]
If the version information included in the received patch identification information 14 is not newer, the client 471 returns a cancel request to the server 47.
[0254]
When the distribution unit 55 receives a cancellation request from the client 471 indicated by the address information 591 determined by the distribution destination determination unit 54, the distribution unit 55 ends the process.
[0255]
On the other hand, when receiving a content transmission request from the client 471, the distribution unit 55 refers to the patch information 11 d registered in the recording unit 56 and acquires the patch 12 corresponding to the patch identification information 14.
[0256]
The distribution unit 10 transmits contents such as the patch identification information 14, the software identification information 15, and the patch 12 to the client 471 indicated by the determined address information 591.
[0257]
Then, the distribution unit 10 registers the patch identification information 14 indicating the transmitted patch 12 and the determined address information 591 in association with the distribution information 56c.
[0258]
23 and 24 are flowcharts showing an example of the operation of the server 46 according to the present embodiment.
[0259]
In step V <b> 1, the request processing unit 50 receives a distribution request 61.
[0260]
For example, “% anycastsend -t now virus removal.0102513” is issued as the distribution request 61. In this distribution request 61, “anycastsend” is an instruction name, “−t now” represents an instruction to perform distribution when the request is issued, and “virus removal” represents a name of a patch to be distributed. “0102513” below “.” Represents patch version information. That is, this “virus removal. 0102513” is the patch identification information 14 specified by the distribution request 61.
[0261]
In step V <b> 2, the request processing unit 50 performs option analysis and recognition of the patch identification information 14 to be distributed based on the distribution request 61.
[0262]
In step V3, the request processing unit 50 refers to the software information 11a and determines whether software identification information corresponding to the patch identification information 14 is registered.
[0263]
If the software identification information corresponding to the patch identification information 14 is not registered in the software information 11a, in step V4, the request processing unit 50 returns an error to the distribution request source and ends the process.
[0264]
When the software identification information corresponding to the patch identification information 14 is registered in the software information 11a, the request processing unit 50 acquires the software identification information 15 corresponding to the patch identification information 14 in step V5, and the patch identification information 14 And the software identification information 15 are provided to the address acquisition unit 51.
[0265]
In step V6, the address acquisition unit 51 refers to the address management information 56a.
[0266]
In step V7, the address acquisition unit 51 determines whether anycast address information corresponding to the software identification information 15 received from the request processing unit 50 is registered in the address management information 56a.
[0267]
If anycast address information corresponding to the software identification information 15 is not registered in the address management information 56a, the address acquisition unit 51 returns an error to the issuer of the distribution request 61 in step V8.
[0268]
If anycast address information corresponding to the software identification information 15 is registered in the address management information 56a, the address acquisition unit 51 acquires anycast address information 57 corresponding to the software identification information 15 in step V9.
[0269]
In step V <b> 10, the request transmission unit 52 transmits an anycast request in anycast address distribution based on the anycast address information 57.
[0270]
In step V11, the reply receiving unit 53 receives anycast replies 581 to 58n from the clients 471 to 47n that have received the anycast request.
[0271]
In step V12, the reply receiving unit 53 registers the anycast replies 581 to 58n in the reply management information 56b according to the reception order.
[0272]
In step V13, the delivery destination determination unit 54 acquires the anycast reply 581 received first among the anycast replies 581 to 58n registered in the reply management information 56b, and receives the anycast reply 581 received first. The address information 591 included in is acquired.
[0273]
In step V <b> 14, the distribution destination determination unit 54 refers to the distribution information 56 c recorded in the recording unit 56, and information that associates the patch identification information 14 specified by the distribution request 61 with the acquired address information 591. It is determined whether it is registered in the distribution information 56c, that is, whether the patch indicated by the patch identification information 14 has been distributed to the client 471 indicated by the address information 591.
[0274]
When the information that associates the patch identification information 14 with the address information 591 is not registered in the distribution information 56c, that is, when the information is not yet distributed, in step V15, the distribution destination determination unit 54 selects the client indicated by the acquired address information 591. Determine delivery destination.
[0275]
When information in which the patch identification information 14 and the address information 591 are associated is registered in the distribution information 56c, the distribution destination determination unit 54 refers to the reply management information 56b in step V16, and anycast currently handled The anycast reply received next to the reply is acquired, and the address information included in the next anycast reply is acquired. Then, the process of step V14 is repeated.
[0276]
In this embodiment, it is assumed that the client 471 indicated by the address information 591 is determined as the distribution destination.
[0277]
In step V <b> 17, the distribution unit 55 transmits the patch identification information 14 to the client 471 indicated by the determined address information 591 in order to perform version comparison on the client 471 side.
[0278]
In step V18, the distribution unit 55 receives a content transmission request or a cancel request from the client 471 indicated by the determined address information 591.
[0279]
When receiving a cancel request from the client 471, the distribution unit 55 ends the process.
[0280]
On the other hand, when a content transmission request is received from the client 471, in step V19, the distribution unit 55 refers to the patch information 11d registered in the recording unit 56 and acquires the patch 12 corresponding to the patch identification information 14.
[0281]
In step V20, the distribution unit 55 transmits contents such as the patch identification information 14, the software identification information 15, and the patch 12 to the client indicated by the determined address information 591.
[0282]
In Step V21, the distribution unit 55 registers the transmitted patch identification information 14 indicating the patch 12 and the determined address information 591 in association with the distribution information 56c.
[0283]
Note that step V21 may be executed at any time as long as the content transmission request is received in step V18.
[0284]
FIG. 25 is a block diagram illustrating a specific configuration example of the client 471 according to the present embodiment. The same applies to the configuration examples of the other clients 472 to 47n.
[0285]
The client 471 reads and executes the program 62a recorded in the recording medium 62, thereby executing a request reception unit 63, a reply transmission unit 64, a version management unit 65, a content reception unit 66, a patch processing unit 67, and a communication destination acquisition. Functions as the unit 24, the communication permission unit 25, the authentication unit 26, the version comparison unit 27, the content communication unit 28, and the P2P communication unit 41 are realized. The client 471 includes a recording unit 68. In the present embodiment, the recording unit 68 is built in the client 471. However, for example, a recording device external to the client 471 may be used. The client 471 may access the recording unit 68 via the subnetwork 48.
[0286]
The recording unit 68 records version management information 68a, patch information 29b, software management information 29c, and communication permission information 29d.
[0287]
In the version management information 29a, as shown in FIG. 26, patch identification information of patches received by the client 471 and used for the software correction processing held in the client 471 is registered.
[0288]
In the example of FIG. 26, the patch identification information 16 having the content “virus removal.0100001” is registered.
[0289]
When receiving the anycast request from the server 46, the request reception unit 63 provides the received anycast request to the reply transmission unit 64.
[0290]
When the reply transmission unit 64 receives the anycast request from the request reception unit 63, the reply transmission unit 64 acquires the address information of the server 46 included in the anycast request.
[0291]
Then, the reply transmission unit 64 transmits an anycast reply including the address information of the client 471 to the server 46 based on the acquired address information of the server 46.
[0292]
When receiving the patch identification information 14 from the server 46, the version management unit 65 refers to the version management information 68a.
[0293]
The version management unit 65 searches the patch management information 68a for patch identification information 16 that includes the same patch name as the patch name contained in the received patch identification information 14.
[0294]
Then, the version management unit 65 compares the version information included in the received patch identification information 14 with the version information included in the searched patch identification information 16.
[0295]
The version management unit 65 returns a content transmission request to the server 46 when the received version information is newer than the retrieved version information.
[0296]
On the other hand, if the received version information is not newer than the retrieved version information, the version management unit 65 returns a cancel request to the server 46.
[0297]
When the content receiving unit 66 returns a content transmission request to the server 46, the content receiving unit 66 receives content such as the patch identification information 14, the software identification information 15, and the patch 12 from the server 46.
[0298]
Then, the content receiving unit 66 registers the patch identification information 14 in the version management information 68a, registers the patch 12 and the patch identification information 14 in association with each other, and registers the patch identification information 14 in the patch information 29b. Is provided to the patch processing unit 67.
[0299]
When the patch processing unit 67 receives the patch identification information 14 and the software identification information 15 from the content receiving unit 66 or the content communication unit 28, the patch processing unit 67 acquires the latest version of the patch 12 corresponding to the patch identification information 14 from the patch information 29b. The software 40 corresponding to the software identification information 15 is acquired from the software management information 29c, the software 40 is corrected using the patch 12, and the corrected software 40 is registered in the software management information 29c instead of the software 40 before the correction. To do.
[0300]
27 and 28 are flowcharts showing an example of processing in which the client 471 according to the present embodiment receives content from the server 46. FIG.
[0301]
In step W <b> 1, the request reception unit 63 receives the anycast request transmitted from the server 46.
[0302]
In step W2, the reply transmission unit 64 acquires address information of the server 46 included in the anycast request.
[0303]
In step W <b> 3, the reply transmission unit 64 transmits the anycast reply 581 including the address information 591 of the client 471 to the server 46 based on the acquired address information of the server 46.
[0304]
In step W <b> 4, the version management unit 65 receives the patch identification information 14 from the server 46.
[0305]
In step W5, the version management unit 65 refers to the version management information 68a.
[0306]
In step W6, the version management unit 65 searches the version management information 68a for the patch identification information 16 including the same patch name as the patch name included in the patch identification information 14.
[0307]
In step W7, the version management unit 65 compares the version information included in the received patch identification information 14 with the version information included in the searched patch identification information 16.
[0308]
If the received version information is newer than the retrieved version information, the version management unit 65 returns a content transmission request to the server 46 in step W8.
[0309]
On the other hand, if the received version information is not newer than the retrieved version information, the version management unit 65 returns a cancel request to the server 46 in step W9. In this case, the process ends.
[0310]
When a content transmission request is returned to the server 46, in step W10, the content receiving unit 66 receives content such as the patch identification information 14, the software identification information 15, and the patch 12 from the server 46.
[0311]
In step W11, the content receiving unit 66 registers the patch identification information 14 in the version management information 68a, and registers the patch 12 and the patch identification information 14 in association with each other in the patch information 29b.
[0312]
In Step W12, the patch processing unit 67 modifies the software 40 using the latest version of the patch 12, and registers the modified software 40 in the software management information 29c instead of the unmodified software 40.
[0313]
Below, the cooperation operation | movement of the communication system 45 which concerns on this Embodiment is demonstrated.
[0314]
FIG. 29 is a sequence diagram illustrating an example of the cooperative operation of the communication system 45.
[0315]
The server 46 transmits an anycast request to the clients 471 to 47n.
[0316]
When the clients 471 to 47n receive the anycast request from the server 47, they return anycast replies 581 to 58n to the server 47.
[0317]
The server 47 determines a client that transmits the content by increasing the priority of the previously received anycast reply. In FIG. 29, it is assumed that the client 471 is determined.
[0318]
The server 47 transmits the patch identification information 14 (version information only needs to be transmitted) specified by the distribution request 61 to the determined client 471.
[0319]
The client 471 compares the received version information with the version information held by itself.
[0320]
When the comparison result indicates the new version, the client 471 transmits a content transmission request to the server 46.
[0321]
When the server 36 receives a content transmission request from the client 471, the server 36 transmits the content specified by the distribution request 61 to the client 471.
[0322]
The client 471 transmits content to other clients 472 to 47n belonging to the same anycast group.
[0323]
In the communication system 45 according to the present embodiment described above, content is distributed from the server 46 to the specific client 471 using anycast, and the distributed content is spread from the specific client 471 to the other clients 472 to 47n. Is done.
[0324]
As a result, the load on the server 46 is reduced, and the content can be reliably and promptly received by the clients 471 to 47n.
[0325]
(Third embodiment)
In this embodiment, a modification of each of the above embodiments will be described.
[0326]
For example, instead of the anycast delivery of the second embodiment, delivery may be executed to a large number of networks using Xcast.
[0327]
Xcast is a multicast distribution for a small group. In this Xcast, a plurality of address information indicating the destination is described in the header of a packet that flows in the network, and the packet is copied and distributed when the route for each address information branches in the stage of passing through the router.
[0328]
If anycast addresses of a large number of networks are described in the address information described in Xcast, an anycast request can be transmitted to a plurality of sub-networks, and various contents can be distributed by the same method as the above-described anycast communication. It can be performed.
[0329]
In each of the above embodiments, each component of the communication systems 1 and 45 may be realized by hardware as a part realized by a program.
[0330]
The client in each of the above embodiments may be an appliance used at home, for example. Thereby, the control program of the electric appliance which can communicate via a network can be corrected quickly, correctly and easily.
[0331]
In the above embodiments, for example, a storage device, a memory device, or the like can be used for the recording units 11, 29, 46, and 68.
[0332]
Further, in the communication systems 1 and 45 according to each of the above embodiments, each component may be rearranged as long as the same operation can be realized, or each component may be freely combined. The components may be freely divided, and some components may be deleted.
[0333]
For example, the recording units 11, 29, 46, and 68 may be divided into a plurality of recording units. In other words, each of the above embodiments is not limited to the above-described configuration as it is, and can be embodied by modifying the components without departing from the scope of the invention in the implementation stage.
[0334]
【The invention's effect】
As described in detail above, according to the present invention, content can be quickly and accurately distributed from a transmission-side communication device to a plurality of reception-side communication devices, and the load on the transmission-side communication device is reduced. .
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration example of a communication system according to a first embodiment of the present invention.
FIG. 2 is a block diagram showing a specific configuration example of a server of the communication system according to the embodiment.
FIG. 3 is a view showing an example of software information according to the embodiment.
FIG. 4 is a view showing an example of distribution information according to the embodiment.
FIG. 5 is a view showing an example of group information according to the embodiment.
FIG. 6 is a view showing an example of patch information according to the embodiment.
FIG. 7 is a flowchart showing an example of the first half of the operation of the server according to the embodiment;
FIG. 8 is a flowchart showing an example of the second half of the operation of the server according to the embodiment;
FIG. 9 is an exemplary block diagram showing a specific configuration example of a client according to the embodiment;
FIG. 10 is a diagram showing an example of version management information according to the embodiment.
FIG. 11 is a diagram showing an example of software management information according to the embodiment.
FIG. 12 is a diagram showing an example of group management information according to the embodiment.
FIG. 13 is a flowchart showing an example of processing after the client according to the embodiment receives the content distributed by multicast from the server.
FIG. 14 is a flowchart showing an example of the first half of processing for transmitting and receiving content by P2P communication between clients according to the embodiment;
FIG. 15 is an exemplary flowchart illustrating an example of the second half of processing for transmitting and receiving content through P2P communication between clients according to the embodiment;
FIG. 16 is a sequence diagram showing an example of cooperative operation of the communication system according to the embodiment.
FIG. 17 is a diagram showing an example of a state of anycast distribution by the communication system according to the second embodiment of the present invention.
18 is a diagram showing an example of a state of communication between clients by the communication system according to the embodiment. FIG.
FIG. 19 is a block diagram showing a specific configuration example of a server of the communication system according to the embodiment;
FIG. 20 is a diagram showing an example of address management information according to the embodiment.
FIG. 21 is a diagram showing an example of reply management information according to the embodiment.
FIG. 22 is a diagram showing an example of distribution information according to the embodiment.
FIG. 23 is a flowchart showing an example of the first half of the operation of the server according to the embodiment;
FIG. 24 is a flowchart showing an example of the second half of the operation of the server according to the embodiment;
FIG. 25 is a block diagram showing a specific configuration example of a client according to the embodiment;
FIG. 26 is a diagram showing an example of version management information according to the embodiment.
FIG. 27 is a flowchart showing an example of the first half of processing in which a client according to the embodiment receives content from a server;
FIG. 28 is a flowchart showing an example of the latter half of the process in which the client according to the embodiment receives content from the server;
FIG. 29 is a sequence diagram showing an example of cooperative operation of the communication system according to the embodiment.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1,45 ... Communication system 2, 46 ... Server, 31-3n, 471-47n ... Client, 4 ... Network, 5, 12a, 12b ... Patch, 6, 19, 49, 62 ... Recording medium, 6a, 19a, 49a, 62a ... program, 13, 61 ... distribution request, 14 ... patch identification information, 15 ... software identification information, 7, 50 ... request processing unit, 8 ... distributed confirmation unit, 9 ... group management unit, 10, 55 ... Distribution unit, 11, 29, 56, 68 ... Recording unit, 11a ... Software information, 11b, 56c ... Distribution information, 11c ... Group information, 11d, 29b ... Patch information, 20 ... Multicast reception unit, 21 ... Reception confirmation unit, 22, 65 ... version management unit, 23, 67 ... patch processing unit, 24 ... communication destination acquisition unit, 25 ... communication destination permission unit, 26 ... authentication unit, 27 ... version ratio , 28 ... content communication part, 29 a ... version management part, 29 c ... software management information, 29 d ... communication permission information, 29 e ... group management information, 41 ... P2P communication part, 48 ... sub-network, 51 ... address acquisition part, 52 ... request sending unit, 53 ... reply receiving unit, 54 ... delivery destination determining unit, 56a ... address management information, 56b ... reply management information, 63 ... request receiving unit, 64 ... reply sending unit, 66 ... content receiving unit, 68a ... Version control information

Claims (18)

Means for accepting a distribution request for specifying content identification information indicating content to be distributed;
Means for acquiring multicast address information corresponding to the content identification information specified in the distribution request based on information associating the multicast address information specifying the multicast group in the multicast distribution with the content identification information;
A communication device comprising: distribution means for executing multicast distribution of content indicated by the content identification information specified by the distribution request using multicast address information corresponding to the content identification information specified by the distribution request. The communication device according to claim 1.
The content identification information specified in the distribution request includes version information of the content to be distributed,
Means for comparing the version information of the content identification information specified in the distribution request with the version information of the content identification information indicating the content distributed by the distribution means;
The communication device according to claim 1, wherein the distribution unit executes multicast distribution when the content to be distributed is a new version. Receiving means for receiving content distributed using multicast distribution;
Means for comparing version information of content held by other devices belonging to the same multicast group and version information of content received by the receiving means;
When the content received by the receiving means is a new version, the content received by the receiving means is provided to the other device, and when the content received by the receiving means is an old version, A communication device comprising: means for receiving content held by the other device from another device. The communication device according to claim 3.
A communication apparatus further comprising means for confirming the integrity of the content received by the receiving means and discarding the content received by the receiving means if integrity is not ensured. Means for accepting a distribution request for specifying content identification information indicating content to be distributed;
Means for acquiring anycast address information corresponding to the content identification information specified in the distribution request based on information associating anycast address information specifying an anycast group in the anycast distribution with content identification information; ,
Means for transmitting an anycast request using anycast address information corresponding to the content identification information specified in the distribution request;
Means for receiving an anycast reply;
Based on the reception order of the anycast reply, a transmission destination determination unit that determines a transmission destination of content indicated by the content identification information specified in the distribution request, and a transmission destination determined by the transmission destination determination unit, Means for transmitting content indicated by the content identification information specified in the distribution request. The communication device according to claim 5.
The transmission destination determination means indicates the transmission source of the anycast reply that has not been transmitted yet but the content indicated by the content identification information specified in the distribution request is indicated in the content identification information specified in the distribution request. A communication apparatus that is determined as a content transmission destination. Means for receiving an anycast request in anycast delivery;
Means for returning an anycast reply to the sender of the anycast request;
Receiving means for receiving content from the sender of the anycast request;
Means for comparing the version information of the content held by another device belonging to the same anycast group with the version information of the content received by the receiving means;
When the content received by the receiving means is a new version, the content received by the receiving means is provided to the other device, and when the content received by the receiving means is an old version, A communication device comprising: means for receiving content held by the other device from another device. The communication device according to claim 7.
Receiving the version information of the content from the sender of the anycast request to determine whether it is a new version;
The communication device is characterized in that the receiving means receives content determined to be a new version. In a communication system for transmitting content from a transmitting communication device to a plurality of receiving communication devices,
The transmission side communication device performs multicast distribution of the content using group address information designating a multicast group,
The plurality of receiving side communication devices are:
Receiving means for receiving the content;
Means for comparing the version information of the content held by another receiving communication device belonging to the multicast group with the version information of the content received by the receiving means;
When the content received by the receiving means is a new version, the content received by the receiving means is provided to the other receiving side communication device, and the content received by the receiving means is an old version And a means for accepting content held by the other receiving communication device from the other receiving communication device. In a communication system for transmitting content from a transmitting communication device to a plurality of receiving communication devices,
The transmission side communication device is:
Means for accepting a distribution request for specifying content identification information indicating content to be distributed;
Means for acquiring anycast address information corresponding to the content identification information specified in the distribution request based on information associating anycast address information specifying an anycast group in the anycast distribution with content identification information; ,
Means for transmitting an anycast request using anycast address information corresponding to the content identification information specified in the distribution request;
Means for receiving an anycast reply;
Based on the reception order of the anycast reply, a transmission destination determination unit that determines a transmission destination of the content indicated by the content identification information specified in the distribution request, and a transmission destination determined by the transmission destination determination unit, Means for transmitting the content indicated by the content identification information specified in the distribution request,
The plurality of receiving side communication devices are:
Means for receiving the anycast request;
Means for returning the anycast reply;
Receiving means for receiving content from the transmitting communication device;
Means for comparing the version information of the content held by another receiving communication device belonging to the anycast group with the version information of the content received by the receiving means;
When the content received by the receiving means is a new version, the content received by the receiving means is provided to the other receiving side communication device, and the content received by the receiving means is an old version And a means for accepting content held by the other receiving communication device from the other receiving communication device. Computer
Means for accepting a distribution request specifying content identification information indicating content to be distributed;
Means for accessing recording means for recording information in which multicast address information specifying a multicast group in multicast distribution is associated with content identification information, and acquiring multicast address information corresponding to the content identification information specified in the distribution request ,
A program for functioning as distribution means for executing multicast distribution of content indicated by content identification information specified by the distribution request using multicast address information corresponding to the content identification information specified by the distribution request. Computer
Receiving means for receiving content distributed using multicast distribution;
Means for recording the received content in a recording means;
Means for comparing version information of content held by other devices belonging to the same multicast group with version information of content recorded in the recording means;
When the content recorded in the recording means is a new version, the content recorded in the recording means is provided to the other device, and the content recorded in the recording means is an old version And a program for causing the other device to receive content held by the other device. Computer
Means for accepting a distribution request specifying content identification information indicating content to be distributed;
Anycast address information corresponding to the content identification information specified in the distribution request is accessed by accessing a recording unit that records information in which anycast address information specifying the anycast group in the anycast distribution is associated with the content identification information. Means to obtain the
Means for transmitting an anycast request using anycast address information corresponding to the content identification information specified in the distribution request;
Means for receiving anycast replies,
A transmission destination determination means for determining a transmission destination of the content indicated by the content identification information specified in the distribution request based on the reception order of the anycast reply;
The program for functioning as a means to transmit the content which the content identification information designated by the said delivery request | requirement transmits to the transmission destination determined by the said transmission destination determination means. Computer
Means for receiving an anycast request in anycast delivery,
Means for returning an anycast reply to the sender of the anycast request;
Receiving means for receiving content from the sender of the anycast request;
Means for recording the received content in a recording means;
Means for comparing version information of content held by other devices belonging to the same anycast group with version information of content recorded in the recording means;
When the content recorded in the recording means is a new version, the content recorded in the recording means is provided to the other device, and the content recorded in the recording means is an old version And a program for causing the other device to receive content held by the other device. Accept a distribution request that specifies content identification information indicating the content to be distributed,
Based on information in which multicast address information specifying a multicast group in multicast distribution and content identification information are associated with each other, acquire multicast address information corresponding to the content identification information specified in the distribution request,
A communication method, wherein multicast distribution of content indicated by content identification information specified in the distribution request is executed using multicast address information corresponding to the content identification information specified in the distribution request. Receive content distributed using multicast distribution,
Comparing the version information of the content held by other devices belonging to the same multicast group with the version information of the received content;
When the received content is a new version, the received content is provided to the other device, and when the received content is an old version, from the other device to the other device. A communication method characterized by receiving content to be held. Accept a distribution request that specifies content identification information indicating the content to be distributed,
Obtaining anycast address information corresponding to the content identification information specified in the distribution request, based on information associating anycast address information specifying the anycast group in the anycast distribution with content identification information;
Using the anycast address information corresponding to the content identification information specified in the delivery request, send an anycast request,
Receive anycast reply,
Based on the reception order of the anycast reply, determine a destination of content indicated by the content identification information specified in the distribution request,
A communication method, comprising: transmitting content indicated by content identification information specified in the distribution request to the determined transmission destination. Receive anycast request in anycast delivery,
Return an anycast reply to the sender of the anycast request,
Receiving content from the sender of the anycast request,
Comparing the version information of the content held by other devices belonging to the same anycast group with the version information of the received content,
When the received content is a new version, the received content is provided to the other device, and when the received content is an old version, from the other device to the other device. A communication method characterized by receiving content to be held.

Images