JP3406991B2 - Mass data delivery method and system - Google Patents

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a large-capacity data delivery method and system, and more particularly to delivering large-capacity data stored in a CDROM, a multimedia database, etc., to one or a plurality of terminals. The present invention relates to a mass data delivery method and system.

More specifically, the present invention relates to a large-capacity data delivery method and system for highly reliable data delivery in which data is retransmitted in response to transmission error or loss of transmission data.

[0003]

2. Description of the Related Art FIG. 15 shows a conventional data delivery sequence to a plurality of terminals. As shown in the figure, conventionally, a server delivers data to one or more terminals, and when each terminal has an error or loss, it responds by saying that there is unreceived data (negative). Response) to the server,
The server retransmits the unreceived data to the terminal. There is a retransmission procedure in which this is repeated until the data is completely received or the retransmission is repeated a proper number of times. Below,
This procedure is called the basic delivery procedure.

Since the terminal makes a reliable report to the server,
In some cases, when the delivery is successful (all the data is complete), a positive response is returned to the server. Especially when delivering data to multiple terminals,
Data delivery from the server to the terminals uses multicast (broadcast to a designated terminal group) to transmit data to a plurality of terminals in one transmission process.

In data communication, data is usually divided into packets, and reception and non-reception are managed in packet units by both the server and the terminal, and the above basic delivery procedure is executed. FIG. 16 shows a table for managing this packet.
17 and FIG. The procedure for performing the above-mentioned multicast multiple times to retransmit lost data is
ternet Society (ISOC) (Headquarters and Secretariat Reston VA US
A) Published document RFC (Request for comment)
s) 1301: Multicast Transport Protocol and RFC
1458: Requirements for Multicast Protocols.

Further, prior to the start of data delivery, the server notifies the terminal of the total size of data and the number of packets (delivery start notification), and after the end of data delivery, sends a delivery end notification. In response to these notifications, the terminal sometimes returns a response for confirmation. The delivery start / end procedure is a procedure normally performed by a connection type communication protocol.

[0007]

However, in the above-mentioned conventional method, the server is restricted by the main memory capacity of the terminal or by the restriction of the management of one-time data delivery.
There is a limit to the amount of data that can be delivered by the basic delivery procedure (one transmission and subsequent retransmission).

The present invention has been made in view of the above points, and relates to large-capacity data that cannot be transmitted in one delivery procedure (one transmission and subsequent necessary number of retransmissions) due to restrictions of memory and the like. In addition, even if data loss occurs due to deterioration of network data transmission errors or temporary deterioration of reception performance at terminals, it is possible to deliver large volumes of data stably and reliably to many terminals. An object is to provide a capacity data delivery method and system.

[0009]

FIG. 1 is a diagram for explaining the principle of the present invention. According to the present invention, when data is continuously delivered from a server to at least one terminal via a communication network, if the delivery fails halfway.
In large data delivery method for performing retransmission case, the server divides deliver large amounts of data using a plurality of times the basic delivery steps (step 1), 1 unit of
Manages the success or failure of individual delivery by basic delivery procedure (Step 2), row a retransmitted delivery failed delivery unit
Cormorant (step 3).

Further, according to the present invention, in the server, continuous data is divided into blocks to which a sequence number is added, a plurality of blocks are delivered by an existing packet delivery procedure, and success or failure of delivery of one unit in the delivery procedure. Record,
The terminal receives the block delivered from the server, records the success or failure of the block reception, the server delivers the last block, and after the terminal receives the block, the delivery success or failure information recorded from the server is recorded. It forwards <br/> to said terminal, the terminal collates the success of information delivery that has been delivered from the server, and information success or failure of reception, in the case of disagreement, the success or failure of receiving the server Transfers the information and the server
The delivery success / failure information is corrected based on the reception success / failure information received from the terminal, and the block for which the delivery has failed is retransmitted based on the corrected delivery success / failure information.

In addition, according to the present invention, when a plurality of blocks are delivered by an existing packet delivery procedure in a server, delivery information of blocks delivered after the packet is provided at the beginning of data delivery and every delivery of blocks. Send a delivery start notification packet for sending, and at the terminal,
The response to the delivery start notification packet is returned to the server.

Further, according to the present invention, in the server, when the delivery start notification packet is other than the first packet of data delivery, the delivery start notification packet is not waited for a response to the delivery start notification packet from the terminal. Will be shipped in duplicate.

Further, according to the present invention, in the server, if there is at least one delivery failure block with reference to the delivery success / failure record, the delivery failure block is retransmitted based on the record. Further, according to the present invention, in the server, after the final block is transmitted, the record of the success or failure of delivery is included in the delivery end notification packet and transmitted to the terminal, and the success or failure of the delivery end notification packet notified by the server in the terminal. The record is compared with the record of the success or failure of the reception in the self terminal, and if they match, an affirmative response is sent to the server, and if they do not match, the record of the success or failure of the reception of the self terminal is sent to the server. In (1), the record of the success or failure of the delivery is corrected based on the record of the success or failure of the reception transmitted from the terminal, and based on the corrected record of the success or failure of the delivery, the delivery is retransmitted to the terminal whose delivery is not completed.

FIG. 2 is a block diagram showing the principle of the present invention. The present invention (Claim 6) comprises a server 400S connected via a communication network and at least one terminal 400R to which data is continuously delivered from the server 400S. From the server 400S to the terminal 400R. Delivery of
Is a large-capacity data delivery system for retransmitting data in the middle of the process , dividing the large-capacity data into blocks, and managing the success or failure of delivery in block units; The server 400S and the terminal 400R each include a delivery management unit 404 that executes the basic delivery procedure of 1 as a unit, and a communication control unit 407 that controls communication between the terminal 400R and the server 400S.

[0015] The application program management unit 401, the application program buffer 402 for storing large amounts of data in block units, has a success and failure managing unit 4031 for dividing managing the block, from the delivery management means 404 1 When the success / failure of the block transfer of the unit is notified, the success / failure management means 4031 includes means for recording the success / failure of the transfer of the block.

Further, the delivery management means 404 sends a delivery start notification packet for transmitting delivery information of blocks delivered after the packet at the beginning of data delivery and each delivery of a block. including. The delivery management means 404R of the terminal 400R includes a start notification returning means for returning a response to the delivery start notification packet to the server 400S.

When the delivery start notification packet is other than the first packet for data delivery, the delivery management means 404S of the server 400 does not wait for a response to the delivery start notification packet from the terminal 400R. includes a start notification packet duplication delivery means for delivering duplicate the delivery start notification packet.

The delivery management means 404S of the server 400S refers to the success / failure management means 4031S and if there is at least one delivery failure block, the delivery failure block is based on the success / failure management means 4031S. Retransmission means for retransmitting is included. Further, the application management means 401S of the server 400S described above includes a delivery end notification means for transmitting the information of the success / failure management means of the server 400S to the terminal 400R by including the information in the delivery end notification packet, and the terminal 400.
The application management unit 401R of the terminal 400R includes a table correction unit that corrects the information of the success / failure management unit 4031S according to the response from R, and the application management unit 401R of the terminal 400R and the information of the success / failure management unit of the server 400S notified by the delivery end notification unit. If the reception success / failure determination unit that collates the contents of the success / failure management unit 4031R in the terminal 400R and the reception success / failure determination unit match, an affirmative response is transmitted to the server 400S, and if they do not match, the own terminal And an end response means for transmitting the content of the success / failure management means.

As described above, according to the present invention, for the delivery of a large amount of data, the basic delivery procedure is used a plurality of times to carry out the division delivery, and the success or failure of each delivery is managed. The data can be retransmitted, and a large amount of data can be reliably delivered to a plurality of terminals.

Further, according to the present invention, in the server, when the delivery start notification packet is other than the first packet of data delivery, the delivery start notification packet is not waited for a response to the delivery start notification packet from the terminal. Duplicated delivery makes it possible to prevent packet loss in the network and the like, and shortens the time until block retransmission because there is no need to wait for a response.

[0021]

DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 3 shows the configuration of the entire system to which the present invention is applied. In the information communication system shown in the figure, a server 101 has a plurality of terminals 1031, 1032, 1 through a wired or wireless communication network 102.
It is connected to 03x.

For example, 650 Mbyte of CD-ROM is
It is divided into 10Kbyte blocks, and the basic delivery procedure is repeated 65 times for each block, and the whole data 650M
Deliver byte to the terminal. In the basic delivery procedure, one block is divided into packets of about 1 Kbyte and transmitted, and retransmission management is performed for each packet.

Multicast transmission to multiple terminals by the basic retransmission procedure (broadcast transmission of data specifying a group)
Can be realized by using an OS (operating system) capable of multicast communication. That is, as the communication control unit 407S / R of the server and the terminal, for example, UDP (User Datagram Protocol) and IP (Inter
This can be realized by using an OS capable of net protocol) protocol processing. In particular, an OS capable of processing an IP group address (class D address) is used.
UDP processing also includes detection of bit errors in received packets and discarding of bit error packets.

FIG. 4 shows the configuration of the large capacity delivery system of the present invention. In the following description, each constituent element will be described by adding a symbol S that means the server internal configuration and an R that means the terminal internal configuration. The system shown in the figure is composed of a server 400S and a terminal 400R, and an application management unit 401S / R,
The delivery management unit 404S / R and the communication control unit 407S / R are configured, and the application management unit 401S / R is
It has an application buffer 402S / R and application processing 403S / R, and a delivery management unit 404S / R.
Is a block buffer 405 S / R and a delivery processing unit 406.
Has S / R.

In the application management section 401S of the server 400S, an application buffer (hereinafter,
An application processing unit (hereinafter referred to as an AP) that manages the large-capacity data of the 402S by dividing it into blocks.
403S is provided. Also, the server 400
In the delivery management unit 404S of S, basic delivery processing in block units is performed, and A is delivered every time one block delivery is completed.
A delivery processing unit 406S that requests the next block is provided in the P processing unit 403S. Further, the AP processing unit 403S stores a block management table 403 for recording the success or failure of delivery.
1S is provided.

The terminal side 400R is also provided with a delivery processing unit 406R that executes the basic delivery procedure in block units, and passes or fails the reception and the received block to the AP processing unit 403R each time block reception is completed. The AP processing unit 403R has a block management table 4031 for recording the success or failure of delivery.
R is provided.

FIG. 5 shows the configuration of the delivery processing unit of the server of the present invention, and FIG. 6 shows the configuration of the delivery processing unit of the terminal of the present invention. The delivery processing unit 406S / R includes a large-scale delivery processing unit 501S / R, a basic delivery processing unit 502S / R, and a delivery start / end processing unit 503S / R. The basic delivery processing unit 406S / R divides and normally delivers a block of about 10 KB bytes in packets of about 1 Kbyte size.

Next, an outline of a series of operations in the above configuration will be described. FIG. 7 is a diagram for explaining the outline of a series of operations of the present invention. First, when the AP processing unit 403S of the server 400S receives a delivery request from the outside (step 101), it divides the data in the AP buffer 402S into blocks (step 102) and sends a delivery start notification to the terminal 4
00R is notified (step 103).

When the terminal 400R receives the delivery start notification, the delivery management unit 404R of the terminal 400R prepares the block buffer 405R, and the AP processing unit 403R
AP buffer 402R and block management table 4031
Prepare R and prepare for reception.

The AP processing unit 403 of the server 400S transfers data to the delivery processing unit 406S in block units. As a result, in the delivery processing unit 406S, the block buffer 4
05S is prepared and the given block is delivered to the terminal 400R using the basic delivery procedure (step 10).
4).

The server 400S and the AP processing unit 403S / R of the terminal 400R record the success or failure of delivery in each block. After the entire series of delivery of the large-capacity data, referring to this record, the server 400S delivers the delivery failure block to the terminal 400R (step 105).

The connection processing with the network and the packet transfer processing in which the blocks are subdivided are performed by the server 400S,
And the communication control unit 407S / R of the terminal R. Next, the delivery start notification packet first transmitted from the server 400S to the terminal 400R will be described. This delivery start notification packet is sent to the server 400 before the delivery of the next block at the very beginning of data delivery and every delivery of a block.
This is a packet notified from the S to the terminal 400R, and is multicast to a plurality of terminals for efficiency.

FIG. 8 shows the data structure of the delivery start notification packet of the present invention. The delivery start notification packet includes a terminal destination 601, a packet type 602, and transfer information 603. The group address is used as the terminal destination 601 for delivery to a plurality of terminals. Packet type 6
02 indicates that the packet is a delivery start notification packet. The delivery information 603 includes a total data size 604 of the entire large-capacity data, a block size 605, and a block number 606 that indicates the order of block delivery. The size of the total data size 604 needs to be a size that can be expressed up to the maximum data size assumed in each system using the present invention. For example, even if the size in bytes is encoded with 32 bits, it is 4,294,967,296 bytes in 2 32, that is, about 4.29 Gby
A data delivery system up to te (gigabyte) can be realized. Approximately 18,446,744T by encoding with 64 bits
Encoding is possible up to te (terabyte), so there is no practical problem. The specific code length depends on individual system settings.

The same applies to block numbers. If encoded with 16 bits, it is 6553 by 2 16
Up to 6 can be expressed, and about 655.3 in 10Mbyte block
It can handle up to 6 Gbyte. When encoded with 32 bits, 4,32,967,296 can be represented by 2 to the power of 32, and 1
A 0 Mbyte block can handle up to about 42949.6 Tbyte, which is not a practical problem.

As described above, according to the present invention, by using the basic delivery procedure for a large amount of data a plurality of times, the data divided into blocks is delivered, and the success or failure of the delivery result is recorded. After the delivery, the recorded delivery result is referred to, and if there is an undelivered block, the block is retransmitted.

[0036]

Embodiments of the present invention will be described below with reference to the drawings. [First Embodiment] In the following first embodiment, first,
It will be explained with the delivery of fixed length data whose data size is fixed before delivery. An example of delivery of indefinite length data whose size is not fixed at the time of delivery start will be described later in the second embodiment.

At the beginning of data delivery, the server 400S delivers the delivery start notification packet 600 to the terminal 400R. The server 400S uses the delivery start notification packet 600.
For confirmation, the terminal 400R returns a response. In addition, in the delivery of blocks other than the first block in the middle,
This response waiting can be omitted and efficiency can be improved. Instead, transferring the notification packet in duplicate is effective for packet loss in a network or the like.

FIG. 9 shows an example of the block management table of the server according to the first embodiment of the present invention. The figure shows a server 40
In the 0S AP processing unit 403S, the management status of the block management table 4031S that records the success or failure of delivery of each block is shown for each terminal. The server 400S receives the management table 4031S after the series of block delivery processing.
The failed block is retransmitted based on.

FIG. 10 shows an example of the block management table of each terminal according to the first embodiment of the present invention. The success or failure of delivery of each block shown in FIG. 9 and FIG. 10 is indicated by ◯ / × for the sake of understanding in each figure.
/ 0 can be associated with success / failure. This is a so-called bitmap.

The server 400S and the terminal 40 shown in FIGS.
In any of 0R, the block storage position in the AP buffer 402S / R is also described for each block. Reading / writing of the block is performed based on this position. For example, in the case of a file, it is the read / write start position of the file.

Below, an example of the processing of this embodiment will be explained with reference to the flow charts of FIGS. Figure 11
6 is a flowchart of a delivery processing operation of the server according to the first embodiment of this invention.

Step 801) AP processing unit 4 from the outside
Data delivery is instructed to 03S. At this time, a group of terminals and data to be transmitted are designated.
The data is stored in the AP buffer 402S. Step 802) Prepare for delivery start. The AP buffer 402S of the AP management unit 401S is a file,
Block management table 4031S of AP processing unit 403S
The file read position is associated with the block number of. Block buffer 4 of the delivery management unit 404S of the server
05S is based on the premise that an area in consideration of the available memory size of the server 400S and each terminal 400R is secured in the memory in advance.

Step 803) The AP processing unit 403S instructs the large-scale delivery processing unit 501S of the delivery processing unit 406S to start delivery. The large-scale delivery processing unit 501S instructs the delivery start / end processing unit 503S, and the delivery start / end processing unit 503S generates a delivery start notification packet and transmits it to the terminal 400S by multicast.

Step 804) The delivery start / end unit 503S waits until the responses from the terminals 400R to the delivery start notification packet are complete. When all the responses are complete,
Alternatively, when the time limit is reached by the timer, the member of the terminal 400R to be delivered is determined. This member is
This is the group range specified in step 801. The AP processing unit 403S according to the decided member and the data size and block buffer size given in step 801.
To the block management table 4031S shown in FIG. In the basic delivery processing unit 502S, according to the decided member, block size, and packet size, FIG.
The packet management table 5021S as shown in is set.

Step 805) The first one block is fetched from the AP buffer 402S into the block buffer 405S of the delivery management unit 404S. Step 806) The basic delivery processing unit 502S executes transmission / retransmission of the block buffer. Multicast is used for delivery to multiple terminals.

Step 807) The basic delivery processing unit 502S of the delivery processing unit 406S reports the success or failure of the block transfer to the AP processing unit 403S. The AP processing unit 403S records the success or failure of the block delivery in the block management table 4031S. Step 808) If the basic delivery procedure is executed for all the blocks of the AP buffer 402S, Step 81
Move to 0. If the delivery according to the basic delivery procedure for each block is not completed, the process proceeds to step 809 to prepare the delivery of the next undelivered block.

Step 809) The block number is incremented by one, and a delivery start notification packet is sent to each terminal 400R.
Will be notified that the next block delivery will continue. Control goes to step 805. In particular, unlike the case of the first notification of large-scale delivery (step 803), the terminal 40
By not making a response from the 0R and immediately moving to the next retransmission, the time until the next block retransmission is shortened.
In this case, a plurality of delivery start notification packets are sent to each terminal 40.
By sending the packet to the 0R, it is possible to deal with the loss of the packet on the network or the like.

Step 810) Delivery processing unit 406S
Sends a delivery end notification packet. Multiple terminals 400
For R, this is also performed by multicast. The process moves to the determination of the presence / absence of a retransmission block in step 811. Step 811) Block management table 4 shown in FIG.
In 031S, if all blocks are successfully delivered to all terminals, the delivery ends. In other words, it is the time when all the block management tables 4031S are filled with ◯. Also,
When there is even one unsuccessful block, the process proceeds to step 812. Hereinafter, a block in which delivery is unsuccessful at any one of the terminals to be delivered is referred to as an “unsuccessful block”. In the block management table 4031S, an unsuccessful block has at least one x in each column (corresponding to each terminal).

Step 812) The unsuccessful block is retransmitted based on the block management table 4031S. Resending shall be performed by any of the following resending methods. Retransmission method 1: The unsuccessful block is retransmitted for each terminal by a 1: 1 communication means (for example, TCP protocol).

Retransmission method 2: Retransmits to a plurality of terminals all at once by multicast delivery of the basic delivery procedure. Retransmission method 3: (use retransmission methods 1 and 2 together for each unsuccessful block) In each unsuccessful block, when the number of overlapping unsuccessful terminals is a certain number or less (for example, 10% or less of the number of resending terminals), the block Uses retransmission method 1. Further, in each unsuccessful block, when the number of unsuccessful terminals overlapping exceeds a certain number (for example, when the number of resending terminals exceeds 10%), retransmission method 2 is used for the block.

Which of the above-mentioned retransmission methods 1 to 3 is to be used can be notified to each terminal by using the retransmission start notification packet at the time of starting retransmission in step 812 and distinguishing the packet type among them. . The procedure of step 820 is performed when retransmission of all blocks is completed, or
The process is terminated when a predetermined number of retransmissions is reached for each block or terminal, or when a predetermined time limit is reached.

As described above, after the delivery by the series of basic delivery procedures, the block management table 4031S is referred to, the delivery for each block can be executed, and the reliable delivery and delivery recording of a large amount of data can be performed. Next, the above server 40
A procedure on the side of each terminal corresponding to the processing procedure of 0S will be described.
FIG. 12 is a flowchart of the delivery processing operation of the terminal according to the first embodiment of this invention.

Step 901) The delivery start / end processing unit 503R receives the delivery start notification packet A
Notify the P processing unit 403R. Step 902) Upon receiving the delivery start notification, the AP processing unit 403R prepares the block management table 4031R and the AP buffer 402R according to the values of the total data size of the delivery information 603 and the divided block size. The delivery management unit 404R prepares the block buffer 405R according to the value of the divided block size of the delivery information 603.
The basic delivery processing unit 502R of the delivery processing unit 406R sets the packet management table 5021 shown in FIG. 17 according to the divided block size.

Step 903) The response to the delivery start notification is returned to the server 400S. Step 904) Data of one block is received (including packet retransmission) by the basic delivery procedure. (Step 905) When reception of one block ends, A
The block is passed to the AP buffer 402R via the P processing unit 403R. The AP processing unit 403R records the success or failure of reception of each block. Here, when all the packets for one block are received, it is set as “success”, and when even a part of the packet is missing, it is set as “no”.

Step 906) When the basic delivery procedure has been carried out for all the blocks designated by the delivery start notification, the process proceeds to step 908. If the delivery by the basic delivery procedure for each block is not completed, step 90
7 and waits for the delivery start notification of the next block.

Step 907) Wait for reception of the delivery start notification packet from the server 400S. The server 400S may send a plurality of the same packets,
When even one is received, a block buffer of the divided block size included in the same packet is prepared, and step 904
Move to. The size of the packet management table in the basic procedure should correspond to this block size.

In the above description, the block size is variable. However, when the block size is fixed, the block buffer size specified by the first delivery start notification of large-scale delivery may be used fixedly. It is possible. Step 908) When the delivery end notification is received, the process proceeds to step 909 for determining whether or not there is retransmission.

Step 909) In the block management table 4031R shown in FIG. 10, if the reception of all blocks is successful, the delivery ends. In other words, this is the time when all the block management tables 4031R are filled with ◯. If there is also one unfinished block, step 9
Go to 10.

Step 910) The unsuccessful block is retransmitted based on the block management table 4031R. Depending on the completion status of the block delivery of the server 400S,
There are cases of one-to-one procedure and cases of multicast by the basic delivery procedure. It can be determined by which packet is notified first. When all are completed, when the retransmission is repeated a specified number of times, or when an appropriate timer times out, the processing is terminated.

In step 810 of the delivery processing of the server 400S and step 908 of the terminal 400R,
The block management table 403 shown in FIG. 9 is included in the delivery end notification packet during transmission and reception of the delivery end notification packet.
Success / failure (bit 1/0) of each block of each terminal of 1S
(Column) and send. This also uses multicast from the viewpoint of efficiency.

When each terminal 400R receives this information from the server 400R, it collates with the contents of the block management table 4031R managed by itself, shown in FIG. 10, and if they match, it returns an affirmative response to the server 400S, If there is a difference, success / failure of delivery of each block recorded in the block management table 4031 shown in FIG. 10 (bit 1/0)
The information in the column) is included in the response and returned to the server 400S. Based on this response, the server 400S corrects the block management table 4031S and retransmits the subsequent block based on the correction value.

FIG. 13 shows the data structure of the delivery end notification packet of the first embodiment of the present invention, and FIG. 14 shows the data structure of the response packet to the delivery end notification of the first embodiment of the present invention. Show. The delivery end notification packet shown in FIG.
It is composed of a terminal destination F01, a packet type F02, and delivery success / failure information F03 of each block. The delivery success / failure information F03 of each block is a block success / failure bitmap for each terminal.

Further, the response packet FA00 to the delivery end notification shown in FIG. 14 is composed of a server destination FA01, a packet type FA02, and information (bitmap) FA03 of success or failure of each block delivery to the terminal. In FIGS. 13 and 14, the bit map is a sequence of bits 0 or 1 in the above block number order.

As described above, by using the end notification packet and its response in step 810 and step 908, even if there is a difference between the server 400S and the terminal 400R in the success or failure of block delivery, the block reception is not completed. The packet can be reliably delivered to the terminal. Such a difference is that the terminal 400R to the server 400
This may occur when the response in the basic delivery procedure after each block delivery to S is lost in the network or the like.

In the above description, the case where the entire data size is known at the time of the data delivery start notification when the server 400S requests the terminal 400R to send data to the application has been described. [Second Embodiment] Next, as a second embodiment of the present invention,
A case where the entire data size is uncertain at the start of delivery will be described.

If the data size is indefinite, a symbol of indefinite data size is inserted into the total data size 604 of the delivery start notification packet shown in FIG. 8 described in the first embodiment and transmitted. For example, as the indeterminate symbol, a code value in which all parts of the total data size 604 have 1 bit is used. This code value is not used for the normal total data size value.

In this case, in step 809 of the delivery start notification immediately before the transmission of the last lower block, the delivery start notification packet 60 of FIG.
It is specified in the block number portion 606 of 0. For example, a code value in which all bits in the block number portion 606 are set to 1 is used as the final symbol. This code value is not used for normal number values.

As a result, even if the total data size is uncertain at the start of data delivery, the success or failure of each block can be recorded, and the block can be retransmitted reliably based on the recording. The present invention is not limited to the above embodiments, and various modifications and applications are possible within the scope of the claims.

[0069]

As described above, according to the capacity data delivery method and system of the present invention, transmission cannot be completed in one delivery procedure (one transmission and subsequent required number of retransmissions) due to the restrictions of memory and the like. It is possible to reliably retransmit large blocks of data even in large blocks by recording delivery records in blocks.

As a result, even if data loss occurs due to deterioration of network data transmission errors or temporary deterioration of reception performance at terminals, a large amount of data can be reliably and reliably delivered to a large number of terminals. It becomes possible. Further, the above invention can be implemented regardless of whether the data size is fixed or variable.

[Brief description of drawings]

FIG. 1 is a diagram for explaining the principle of the present invention.

FIG. 2 is a principle configuration diagram of the present invention.

FIG. 3 is a configuration diagram of an entire system to which the present invention is applied.

FIG. 4 is a block diagram of a large capacity delivery system of the present invention.

FIG. 5 is a configuration diagram of a delivery processing unit of the server of the present invention.

FIG. 6 is a configuration diagram of a delivery processing unit of the terminal of the present invention.

FIG. 7 is a diagram for explaining an outline of a series of operations of the present invention.

FIG. 8 is a data configuration diagram of a delivery start notification packet of the present invention.

FIG. 9 is an example of a block management table of the server according to the first embodiment of this invention.

FIG. 10 is an example of a block management table of the terminal according to the first embodiment of this invention.

FIG. 11 is a flowchart of delivery processing operation of the server according to the first embodiment of this invention.

FIG. 12 is a flowchart of a delivery processing operation of the terminal according to the first embodiment of this invention.

FIG. 13 is a data configuration diagram of a delivery end notification packet according to the first embodiment of this invention.

FIG. 14 is a data configuration diagram of a response packet to the delivery end notification according to the first embodiment of this invention.

FIG. 15 is a conventional data delivery sequence to a plurality of terminals.

FIG. 16 is an example of a packet management table of a server.

FIG. 17 is an example of a packet management table of each terminal.

[Explanation of symbols]

101, 400S server 1031, 1032, 103x, 400R terminal 401S, 401R application management unit, application management unit 402S, 402R application buffer 403S, 403R application processing unit, application processing unit 404S, 404R delivery management unit, delivery management unit 405S, 405R Block buffer 406S, 406R Delivery processing unit 407S, 407R Communication control unit, communication control means 501S, 501R Large-scale delivery processing unit 502S, 502R Basic delivery processing unit 503S, 503R Delivery end processing unit 600 Delivery start notification packet 601 Terminal destination 602 packet Type 603 Delivery information 604 Total data size 605 Block size 606 Block number F00 Delivery end notification packet F01 Terminal destination 02 Packet type F03 Delivery success / failure information of each block F031 Block success / failure bitmap of terminal 1 F032 Block success / failure bitmap of terminal 2 FA00 Response end notification packet FA01 Server destination FA02 Packet type F03 Each block to the terminal Delivery success / failure information (bitmap) 4031S, 4031R block management table, success / failure management means 5021S, 5021R packet management table

─────────────────────────────────────────────────── ─── Continuation of the front page (58) Fields surveyed (Int.Cl. ⁷ , DB name) H04L 12/00 H04L 1/00

Claims (12)

(57) [Claims] 1. Data is continuously delivered from a server to at least one terminal via a communication network .
In this case, if the delivery fails on the way, it will be resent.
In the large-capacity data delivery method of the above, the server delivers the large-capacity data in a divided delivery using the basic delivery procedure multiple times, manages the success or failure of individual delivery by one unit of the basic delivery procedure , and delivers the delivery failure. mass data delivery method and performing retransmission about unit. 2. The server divides continuous data into blocks to which sequence numbers are added, delivers a plurality of blocks by an existing packet delivery procedure, and records success or failure of delivery of one unit of the delivery procedure , In the terminal, the block delivered from the server is received, the success or failure of the block reception is recorded, the server delivers the last block, and the delivery recorded from the server after the terminal receives the block. of
The success / failure information is transferred to the terminal, and at the terminal, the delivery success / failure information delivered from the server is collated with the reception success / failure information. If they do not match, the server receives the success / failure information. transfer the information of success or failure of the server, on the basis of the information of success or failure of the reception received from the terminal, the fix information success or failure of delivery, the delivery based on the information of the modified success or failure of delivery The mass data delivery method according to claim 1, wherein the failed block is retransmitted. 3. The server, when delivering a plurality of blocks according to an existing packet delivery procedure, for transmitting delivery information of blocks delivered after the packet at the beginning of data delivery and every delivery of blocks. 3. The mass data delivery method according to claim 2, wherein the delivery start notification packet is transmitted, and the terminal returns a response to the delivery start notification packet to the server. 4. In the server, when the delivery start notification packet is other than the first packet of data delivery, the delivery start notification packet is not waited for a response to the delivery start notification packet from the terminal. The method for delivering large-capacity data according to claim 3, wherein: 5. The server according to claim 2, wherein if there is at least one delivery failure block by referring to the delivery success / failure record, the delivery failure block is retransmitted based on the record. Mass data delivery method. 6. A server, which is connected via a communication network, and at least one terminal to which data is continuously delivered from the server, the server to the terminal .
Is a large-capacity data delivery system for re-sending when the delivery of data fails in the middle, and an application program management means for dividing the large-capacity data into blocks and managing the success or failure of the block-based delivery, A large-capacity data delivery system having the server and the terminal, which includes delivery management means for executing each basic delivery procedure as one unit, and communication control means for controlling communication between the terminal and the server. 7. The application program management means includes an application program buffer for storing a large amount of data in block units , and success / failure management means for dividing and managing the blocks, and one unit from the delivery management means . 7. The mass data delivery system according to claim 6, further comprising means for recording the success or failure of the block transfer in the success or failure management means when the success or failure of the block transfer is notified. 8. The delivery management means includes means for transmitting a delivery start notification packet for transmitting delivery information of a block delivered more than the packet at the beginning of data delivery and each delivery of a block. 6
Large-capacity data delivery system described. 9. The mass data delivery system according to claim 8, wherein the delivery management means of the terminal includes start notification returning means for returning a response to the delivery start notification packet to the server. 10. The delivery management means of the server does not wait for a response to the delivery start notification packet from the terminal when the delivery start notification packet is other than the first packet of data delivery, mass data delivery system of claim 8 including a start notification packet duplication delivery means for delivering duplicate the delivery start notification packet. 11. The delivery management means refers to the success / failure management means and, if there is at least one delivery failure block, a resending means for resending the delivery failure block based on the success / failure management means. 6 the claim including
Is a large-capacity data delivery system described in 7. 12. The application program management means of the server includes a delivery end notification means for transmitting the information of the success / failure management means of the server to the terminal by including it in a delivery end notification packet, and in response to a response from the terminal. And a table correction unit that corrects information of the success / failure management unit, wherein the application program management unit of the terminal is the success / failure management unit of the server and the information of the success / failure management unit of the server notified by the delivery end notification. In the reception success / failure determination means for collating the contents of the above and the reception success / failure determination means, if they match, an affirmative response is transmitted to the server, and if they do not match, the contents of the success / failure management means of the own terminal. 8. The mass data delivery system according to claim 7, further comprising: end response means for transmitting the message.