JPH06252897A - Method and system for multiple address file transfer - Google Patents

Abstract

PURPOSE:To avoid data omission on the way by ensuring the management at first and end of file transfer when a file is subject to multiple address distribution. CONSTITUTION:A file to be transferred is read from a transmission file 11 in a transmitter 10 and the file is decomposed into plural blocks after data compression. A serial number 0 is given to a start text and includes a final serial number of a final text. Succeeding texts add serial numbers incremented sequentially and block data are included in the text. A final serial number is added to a final text. The text is subject to multiple address distribution at every constant time by a UDP/IP from file transmission processing 12. A receiver 20 uses a file generating processing 24 to check serial number and when any omitted: number is found out, a re-transmission request processing 25 makes a re-transmission request. The file transmission processing 12 distributes the text again based on the UDP/IP for a 1st re-transmission request and re-transmission reply processing 15 re-transmits the data to the re- transmission request processing 25 with a re-transmission made request by a TCP/IP for a 2nd re-transmission request.

Description

Detailed Description of the Invention

[0001]

TECHNICAL FIELD The present invention relates to a broadcast file transfer method and system for transmitting data (file data) constituting a file from a transmitter to a plurality of receivers through a communication line or by using radio waves.

[0002]

2. Description of the Related Art The most important condition required for file transfer is to correctly transmit all of the data that makes up a file, and no data loss is allowed. A reliable file transfer can be achieved by using a communication protocol (for example, TCP / IP) suitable for connection-type communication that guarantees the reliability of transfer data.

However, since the connection-type communication protocol is premised on one-to-one communication between the transmitting device and the receiving device, if there are a plurality of receiving devices for receiving the files to be transferred, there will be as many receiving devices as there are receiving devices. File transfer must be repeated, and when the number of receiving devices increases, the load on the transmitting device and the transmission medium increases and it takes time.

A protocol suitable for broadcast distribution in which data is transmitted from a transmitter to a plurality of receivers at once (for example, UDP
/ IP), but if such a communication protocol is used, it is not possible to confirm whether or not the data has indeed arrived at the receiving device, and there is a problem that the reliability of data delivery is lacking.

The item that must be confirmed is the presence or absence of data loss. If the data is missing, it is necessary to retransmit the corresponding data. Also, in file transfer, confirmation of the start and end of file transfer is required.

Next, it is necessary to perform fault management on the transmission device, the reception device, or the transmission path on the way. This includes detecting and responding to faults. When a failure occurs, the lost data must be retransmitted. If the failure is recovered, the data distribution will be resumed, and if it is not recovered, it is necessary to forcibly terminate the file transfer for the corresponding receiving device.

It is also necessary to manage which receiving device has forcibly terminated the file transfer.

[0008]

SUMMARY OF THE INVENTION An object of the present invention is to provide a method and system capable of efficiently and reliably transferring the data making up a file to a plurality of receiving devices from the beginning to the end.

It is another object of the present invention to provide a method and system capable of surely retransmitting lost data even when data is lost.

A further object of the present invention is to provide a method and system capable of appropriately coping with a failure even if the failure occurs.

A further object of the present invention is to provide a method and system capable of managing whether or not a file transfer has been completed by a plurality of receiving devices.

The broadcast file transfer method according to the present invention is
At the transmitting station, the file to be transferred is divided into a plurality of blocks, and a start message including the initial sequence number and the last sequence number to be included in the end message, a sequence number that is sequentially incremented from the initial sequence number, and a divided file data block A continuation message that is sent after the start message, including at least, and an end message that is sent at the end including at least the final serial number,
Broadcasts to multiple receiving stations using a communication protocol suitable for broadcasting, and when a receiving station specifies a serial number and requests to resend, a message with the specified serial number is retransmitted. It is a thing.

Each receiving station receives a message sent from the transmitting station, checks the serial number included in the received message, and when it determines that there is a missing number, sends a resend request specifying the missing serial number. Store the message that has been sent and passed the serial number check in a file.

The broadcast file transfer system according to the present invention comprises a transmitter having a file to be transferred, and a plurality of receivers communicable with the transmitter.

The transmission device divides a file to be transferred into a plurality of blocks, and a start message including an initial sequence number and a final sequence number to be included in an end message, a sequence number that is sequentially incremented from the initial sequence number, and a divided file. A plurality of receiving devices including a data block, a continuation telegram transmitted subsequent to a start telegram, and at least an end telegram transmitted at the end including a final serial number by using a communication protocol suitable for broadcast delivery. When there is a resend request by designating a serial number from the delivery means and the receiving device that broadcasts to
A retransmitting means for retransmitting a message having a designated serial number is provided.

Each receiving device checks the receiving means for receiving the electronic message distributed from the transmitting station, checks the serial number included in the received electronic message, and when it determines that there is a missing number, resends it by designating the missing serial number. It is provided with a resend requesting means for sending a request and a means for storing a message that has passed the serial number check in a file.

According to the present invention, block data constituting a file is broadcast from one transmitting station (communication device) to a plurality of receiving stations (receiving devices), so that a plurality of files can be efficiently produced in a short time. Can be transferred to the receiving station. In order to deliver the block data of the file, a start message with a predetermined initial sequence number, a continuation message with sequentially incremented sequence numbers, and an end message with the last sequence number notified by the start message are used. Therefore, not only the serial number management but also the first and last management are possible, and the file can be reliably transferred. Furthermore, even if there is a missing message, the corresponding message is resent in response to the resend request, so various errors can be sufficiently dealt with.

In a preferred embodiment of the present invention, when the receiving station checks the serial number included in the received electronic message and determines that there is a missing number, it sends a first resend request designating the missing serial number. After the transmission, the second retransmission request is transmitted when the electronic message having the designated serial number is not received even after a lapse of a predetermined time after the first retransmission request is transmitted.

Further, at the transmitting station, when any of the receiving stations makes a first resend request, the telegram of the designated serial number is broadcast and redelivered using a communication protocol suitable for broadcast delivery. Then, when there is a second retransmission request, the requested message is retransmitted toward the receiving station that has transmitted the second retransmission request.

In response to the first resend request, the missing message is re-distributed to all the receiving stations, so that even if a plurality of receiving stations cannot receive the same message, one resending process is performed. Is sufficient and processing is simple. Since a highly reliable communication protocol can be used in the second retransmission, the retransmission is reliable.

In another embodiment of the present invention, the transmitting station periodically transmits a message at a first constant time interval, and the receiving station receives a second constant time longer than the first constant time. Checks whether or not a message has been received during the period. If there is no message, it determines that a fault has been detected and sends a fault notification to the transmitting station.

As a result, the transmitting station can recognize that there is a transmission path failure.

In a preferred embodiment, when the transmitting station does not receive the fault notification, the dummy telegram is distributed at the first fixed time interval, and when the receiving station which has transmitted the fault notification receives the dummy telegram. Send a recovery notice to the transmitting station.

By receiving the dummy message in the receiving station which has not detected the failure, it can be known that any one of the receiving stations has the failure. Further, the receiving station that has detected the failure detects the recovery of the failure by receiving the dummy message, and this is notified to the transmitting station, so that the transmitting station can recognize the recovery of the failure.

Since the transmitting station restarts the delivery of the above-mentioned start, continue or end message when the recovery notices are transmitted from all the receiving stations which have transmitted the fault notice within a predetermined time, it is possible to continue the file transfer. Become.

Also, if there is a receiving station that has sent a failure notification and does not send a restoration notification within a predetermined time, the sending station notifies the receiving station of forced termination, and the reception of the forced termination notification. Remember the station.

As a result, it is possible to manage and grasp the receiving station that has completed the file transfer and the receiving station that has not completed the file transfer.

In a further preferred embodiment of the present invention, the transmitting station divides the file to be transferred into a plurality of blocks after data compression processing, and the receiving station receives the data received after receiving all the electronic messages. The block is expanded and the file obtained by the expansion is stored in the received file.

Since the data to be transferred is compressed, the transfer time can be shortened and the efficiency can be improved.

In the transmitting station, by including the execution shell script indicating the processing to be executed by the receiving station in the start message, it is possible to instruct the receiving station to execute the processing using the received file. .

[0031]

DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 1 shows the overall structure of a broadcast file transfer system.

A single transmitter 10 and a plurality of receivers 20 are communicatively coupled to each other via a transmission line 8 via a relay device 9 as required. The transmitter 10 and the receiver 20 are generally constituted by work stations. The transmission line 8 will usually be realized by a communication line. As a communication line, for example, Ethernet type L
AN (Local Area Network) or WAN (Wide Area)
Network) is used. A part of the transmission line 8 may include an existing or future public or private line. In this case, the transmitting device 10 and the receiving device 20 could be installed at locations far apart from each other. A communication satellite may be considered as the relay device 9. In this case, a terrestrial network (including the above-mentioned public line or dedicated line) is also used as a complement to the transmission path via the communication satellite. In any case, the transmission line 8 is a connection type TCP / IP (Transmission Control Pro).
tocol / Internet Protocol) and connectionless UDP / IP (User Datagra
Data transmission is possible using both communication protocols (m Protocol / Internet Protocol). The transmitting device 10 and the receiving device 20 also include computers capable of utilizing these communication protocols.

FIG. 2 shows the functional configurations of the transmitting device 10 and the receiving device 20, and the data flow between and inside them. Various "processes" described below are realized by the operation of a computer according to a processing program (process or program module). These respective processes communicate with each other by inter-program communication.

The transmission device 10 includes a transmission file 11, a file transmission process 12, a retransmission data buffer 13, and a retransmission management process 14.
And a resend response process 15. The retransmission management process 14 is accompanied by a retransmission management table 14A. Send file
11 is realized by a recording medium that stores a file to be transmitted to the receiving device 20.

The receiving device 20 includes a receiving file 21, a receiving process 22, a receiving data buffer 23, a file creating process 24,
A resend request process 25, a resend data buffer 26, and a temporary storage file 27 are provided. The file creation process 24 is provided with a serial number management table 24A. The temporary storage file 27 is for temporarily storing the received file data, and thereafter, the final file data restored (expanded as described later) is stored in the reception file 21. It will be. These files 21, 27
Is realized by a semiconductor memory, a magnetic recording medium, or the like.

As will be described later in detail, the file stored in the transmission file 11 is compressed, divided into a plurality of blocks, and each block is edited and distributed so as to form a message and distributed. The transmission of the electronic message is performed at a constant cycle T1.

A file from the transmitter 10 to the receiver 20
Broadcast data transmission is performed by the file transmission process 12 of the communication device 10.
To the reception process 22 of the reception device 20 using UDP / IP.

When an error occurs in the file data transmitted from the transmitter 10 to the receiver 20 by the broadcast distribution, the receiver 20 gives a retransmission request to the transmitter 10. That is, the retransmission request processing 25 of the reception device 20 transmits the retransmission request using the TCP / IP that guarantees the reliability.
It is transmitted to the resend response processing 15 of.

In response to the first retransmission request (this is referred to as "retransmission request 1"), the file transmission processing 12 of the transmitter 10 sends the file data for which the retransmission request has been made to the UDP.
/ IP to redistribute the data to the retransmission request processing 25 of the receiving device 20. Therefore, even if a plurality of receiving devices 20 make duplicate requests for the same file / data, one re-delivery is sufficient.

For the second retransmission request for the same file / data (this is referred to as “retransmission request 2”), TCP / IP is used to ensure reliability, and the retransmission of the transmission device 10 is performed. Receiving device 20 for which the response process 15 has requested the retransmission
Resend request processing 25
Resend the data.

When a transmission line failure occurs, the file transmission process 12 of the transmission device 10 will have a fixed period T, as will be described later.
1 delivers a dummy message. This is also done using UDP / IP.

Failure notification from the receiving device 20 to the transmitting device 10,
Retransmission request processing 25 sends TCP / I for restoration notification, end notification, etc.
The retransmission response process 15 is performed using P.

The identification of the destination and the sender for such broadcast delivery, resend request, resend, various notifications, etc. is performed by the device 10,
Addresses are used for 20 (work station), and port numbers are used for various processes 12, 15, 22, 25.

FIG. 3 shows the format of a file transfer message used when the file data is distributed or retransmitted from the transmitter 10 to the receiver 20. Where U
Illustration of header information according to DP / IP or TCP / IP is omitted.

There are four types of messages, a start message, a continuation message, an end message and a dummy message. The start message is used at the beginning of one transfer for one file, and the end message is used at the end thereof. The continuation message is used to substantially transmit the file data between the start message transmission and the end message transmission. The dummy telegram is a telegram having no data, and is used to continue the operation of sending the telegram at a constant cycle T1 when a failure occurs. This dummy message allows the receiving device 20 to recognize the restoration of the fault and the occurrence of the fault in another receiving device.

These messages are message type, resource I
D, details of message type, file transfer ID, serial number, record length, and data (main body) fields.

The system shown in FIG. 1 or 2 is used not only for file transfer but also for delivery of real time data. The message type is file transfer or real time.
Indicates whether it is for data distribution or other purposes. The resource ID is an identification code of the data source. In the case of file transfer, both the message type and the resource ID are set to “FT (data transfer)”.

For details of message types, refer to the above-mentioned start message ("S
T ”), continuation message (“ MD ”), or end message (“ L ”)
S ”) or a dummy message (“ DM ”).

A different identification code is attached to the file transfer ID for each file transfer. This is because even the same file may be transferred multiple times with different dates.

The serial number indicates the order of delivering the electronic messages, and is incremented by one each time one electronic message is delivered. As will be described later, this serial number is effectively used to check whether there is any omission in the message received by the receiving device 20. The serial number of the start message is fixed to "0". A positive integer that sequentially increases from "1" is assigned to the serial number of the continuation message in the order of transmission. The serial number of the end message is the final serial number included in the data (main body) of the following start message. The serial numbers of the start message and the end message only need to be known in advance, so any code can be used without being limited to the above.

The record length represents the length of the data (main body) included in each message.

The contents of the data (main body) differ depending on the type of message. In the start message, the data (main body) includes the file name of the file to be transferred, the size of the file, the final serial number used in the end message, and the execution shell script. The execution shell script is
Represents the contents of processing that should be executed using the file in the receiving device that has received the file. In the continuation message and the termination message, the data (main body) is the file data (compressed and decomposed into blocks) to be transferred.

The dummy message does not include the serial number, record length, and data (body) fields.

FIGS. 4 and 5 show the flow of processing when the file transfer is executed normally without any data loss or failure.

The file transmission process 12 of the transmission device 10 reads the file (all of the file data) to be transferred from the transmission file 11, compresses the data, and has the length of the compressed data suitable for the file transfer. Divide into a plurality of blocks (step 31). In this embodiment, the block is divided into 100 blocks. Therefore, the final serial number of the end message is "100".

After this, the file transmission process 12 transmits a start notification to the retransmission management process 14 (step 32). The retransmission management process 14 that has received the start notification shifts from the idle state to the communication state (step 61).

The file transmission process 12 edits the start message and delivers it to the reception process 22 of the reception device 20 using UDP / IP (step 33). Following the transmission of the start message, the file transmission process 12 sequentially edits the continuation message and similarly delivers it to the reception process 22 (steps 33 and 34). Finally, the end message is edited and delivered to the reception process 22 (step 35).

The delivery of these electronic messages is continuously carried out at a cycle of a fixed time T1. It goes without saying that a serial number that is incremented each time a message is transmitted is added to each message.

The file transmission process 12 also transfers and stores the transmitted electronic message to the resend data buffer 13 every time the electronic message is transmitted. This is to prepare for the retransmission request from the receiving device 20.

When receiving the start message, the receiving process 22 of the receiving device 20 stores it in the reception data buffer 23 and notifies the file creating process 24 that the message has been received. Also, a timer for fault detection is set (step 101).

As described above, the file transmission process 12 sends some message (including a dummy message which will be described later) at a constant cycle T1, so a predetermined time T2 that is equal to or longer than this cycle T1.
If no message is received over the entire range, it can be determined that a failure has occurred. The timer for fault detection is set each time any message is received (this point will not be repeated here).

Upon receiving the electronic message reception notification, the file creation processing 24 stores the serial number contained therein in the serial number management table 24A, confirms that it is the start electronic message, and opens the temporary storage file 27 and the reception file 21. (Step 121).

Upon receiving the continuation message, the reception process 22 writes it in the reception data buffer 23 and notifies the file creation process 24 that the message has been received (step 102).

The file creation processing 24 checks the serial number when receiving the message reception notification. The serial number of the last received electronic message is stored in the serial number management table 24A. If the serial number of the message received this time is equal to the value obtained by adding 1 to the serial number of the previous received message, the serial number of the received message this time is correct.
If the difference between the current received message serial number and the previous received message serial number is 2 or more, it is determined that the data is missing for some reason. If the serial number of the received message of this time is equal to the serial number of the previously received message, the received message of this time is the same as the previous one.

When it is determined by the serial number check that the serial number of the current received message is continuous with the serial number of the previous received message, the file creation processing 24 writes the serial number of the current received message in the serial number management table 24A and sets the serial number. With updating,
The message received this time is read from the received data buffer 23 and written in the temporary storage file 27 (step 122).

The reception process 22 and the file creation process 24 repeat the above-described processes of steps 102 and 122 each time a continuation message is received.

When the end message is received, the reception process 22 writes this end message in the reception data buffer 23 and sends a reception notice to the file creation process 24 (step 103).

The file creation processing 24 checks the serial number and, if it is OK, updates the serial number and writes the end message read from the received data buffer 23 to the temporary storage file 27 (step 123).

Since the reception of the end message means that all the file data has been received, the file creation processing 24 reads the received data stored in the temporary storage file 27 and performs the data expansion processing. The file creation processing 24 writes the file thus restored in the reception file 21, and closes the files 27 and 21. The file creation process 24 also sends an end notification to the resend request process 25 and the reception process 22 (steps 124 and 125).

The receiving process 22 that has received the end notification resets the failure detection timer (step 104). The resend request process 25 that has received the end notification transmits the end notification to the resend response process 15 of the transmission device 10 using TCP / IP (step
151).

The resend response process 15 that has received the end notification sends this end notification to the resend management process 14 (step 81).

On the other hand, the file transmission process 12 which has transmitted the termination message transmits the termination notice to the retransmission management process 14 (step 36).

Upon receiving the end notification from the file transmission process 12, the resend management process 14 sets the end waiting timer (step 62). This end waiting timer is for confirming that the end telegram has been correctly received by all of the receiving devices 20, and as will be described later, the set time of this timer depends on the retransmission request from the receiving device 20 and in response thereto. The length is set long enough to include the time required for resending the end message.

The resend management processing 14 checks whether or not end notifications have been sent from all the receiving devices 20 within the set time of the end waiting timer. When the end notifications are delivered from all the receiving devices 20, the file transmission processing 12 is notified of the normal end and the end waiting timer is reset (step 63). By this processing, it is possible to know whether or not the file transfer has been completed normally for all the receiving devices 20 which are the object of the file transfer, and whether there is any abnormal receiving device.

6 and 7 show the processing in the case where one or a plurality of continuation telegrams are not received by the one or a plurality of receiving devices 20 for some reason.

As described above, the file transmission process 12 transmits the continuous electronic message at the cycle of the constant time T1 (step 3).
7, 38, 39, 40). In the following description, the number in parentheses following the term continuous telegram indicates the serial number of the continuous telegram. For example, “continuation message (10)” is a continuation message with the serial number 10.
The same applies to the start message, end message, resend request, and resend response message.

When the receiving process 22 and the file creating process 24 of the receiving device 20 receive the continuation message without any error, the processes of steps 102 and 122 described above are performed, respectively.

It is assumed that the continuation telegrams (11) and (12) are missing and have not reached the reception processing 22.

Upon reception of the subsequent continuation message (13), the reception process 22 writes the received continuation message in the reception data buffer 23 and transmits the reception notification to the file creation process 24, as in step 102. Do (step 105)
).

Upon receipt of the reception notice, the file creation processing 24 checks the serial number as described above. Since the serial number of the last received electronic message is 10 and the serial number of the electronic message received this time is 13, the file creation processing 24 discovers that the serial numbers 11 and 12 are missing. Then the file creation process is serial number 11
The first retransmission request for packets 1 and 12, that is, retransmission request 1 (11, 12) is transmitted to the retransmission request process 25 (step 12).
6).

When this resend request is received, resend request processing 25
Transmits the retransmission request 1 (11, 12) to the retransmission response processing 15 of the transmitter 10.
(Step 152). It goes without saying that the resend request message includes a code indicating that it is resend request 1.

Even after the file creating process 24 sends the resend request 1, the file sending process 12 continues to send continuous telegrams at fixed time intervals, so the receiving process 22 continues to receive these continuous telegrams ( Continue writing the receive message to the receive data buffer 23), and create the receive notification file 24
Continue to give. The file creating process 24 does not process the continuous telegram written in the received data buffer 23 even if the reception notification is received. Receive data buffer
In 23, the received messages form a queue in the order of reception (step 126).

The resend response process 15 that has received the resend request 1 (11, 12) passes the resend request 1 (11, 12) to the resend management process 14 (step 82).

The resend management processing 14 manages the serial number of the message for which a resend is requested in the resend management table 14A. As described above, in response to the resend request 1, the message of the serial number for which the resend request is made is delivered to all the receiving devices 20 by UDP / IP. Therefore, the receiving device 20 receives a message having the same serial number.
There is no need to resend each time there is a resend request from. Therefore, the resend management processing 14 checks whether or not a resend request has already been made from another receiving device for the serial number for which a resend request has been made, and if it has already been redistributed, does not resend the message of that serial number.

Retransmission management processing is performed by referring to the retransmission management table 14A when it is found that the sequence number is the first request for retransmission.
14 sends a resend request 1 (11, 12) to the file sending process 12 (step 64).

When the file transmission process 12 receives the resend request 1, the transmission of the continuous message is temporarily interrupted, the message for which the resend request has been made is read from the resend data buffer 13, and these are sent as resend response message 1 (11 , 12) using UDP / IP to deliver to the resend request processing 25 (step 41).

When the resend request message 25 receives this resend response message, it stores it in the resend data buffer 26 and notifies the file creation process 24 that the resend response message has been received (step 153).

The file creation processing 24 checks the serial number contained in the retransmitted electronic message, updates the serial number in the serial number management table 24A, and stores the electronic message in the temporary storage file 27 (step 127). After that, the same processing is performed for the continuous message waiting in the reception data buffer 23 (step 128).

FIG. 8 and FIG. 9 show the flow of processing for the start message loss as a special case of message loss.
In these figures, the substantially same processes as those shown in FIGS. 4 to 7 are designated by the same reference numerals.

As described above, the file transmission process 12 transmits the continuation message (1) after the start message (0) (steps 33 and 34).

It is assumed that the reception process 22 cannot receive the start message (0) and receives the subsequent continuation message (1) (step 102).

Since the file creation process 24 detects that the start message (0) is missing by the serial number check, it sends the resend request 1 (0) of the start message and the received message (continued The message (including the message (1)) is not processed (step 129).

The resend request 1 (0) is sent through the file creation process 24, resend request process 25, resend response process 15, and resend management process.
14 (steps 152, 82).

The resend management process 14 confirms that the start message is the first resend request, and sends the resend request 1 (0) to the file sending process 12 (step 64).

The file transmission process 12 temporarily interrupts the transmission of the continuation message, and the resend response message (0) for the start message.
Is sent to the resend request processing 25 using UDP / IP (step 41).

The resend request process 25 uses this resend response message (0).
When this is received, it is stored in the resend data buffer 26,
The file creation processing 24 is notified of the reception (step 15).
3).

The file creation processing 24 confirms that the start message has the serial number 0, stores the serial number in the serial number management table 24A, and opens the file (step 12).
1). After this, the file creation process 24 moves to the process for the continuation message stored in the received data buffer 23 (step 128).

FIG. 10 shows the flow of processing relating to the retransmission request 2 performed when the retransmitted continuation message is lost again. This figure is drawn as the process following FIG.

As described with reference to FIG. 6 and FIG. 7, the file transmission process 12 responds to the resend request 1 (11, 12) for the omission of the continuation telegrams (11) and (12) by the continuation telegram. Re-deliver (11) and continuation message (12) (step 4)
1).

Retransmission request processing 25 of the receiving device 20 uses retransmission request 1
After (11, 12) is transmitted (step 152 in FIG. 6), the retransmission monitoring timer is set and it is monitored whether or not the retransmission response message is received within the fixed time.

As shown in FIG. 10, it is assumed that the retransmission of the continuous telegram (12) has been received, but the continuous telegram (11) has not been received even after the elapse of the above-mentioned fixed time. In such a case, the resend request processing 25 identifies the same serial number (11, 12) as previously identified in the resend request 1 to determine the second resend request,
That is, the resend request 2 (11, 12) is transmitted to the resend response process 15 by TCP / IP (step 154).

Since the retransmitted continuation message (12) has been received, the retransmission request 2 may be transmitted only for the continuation message (11), but in order to avoid the complexity of the process, The second resend request is issued for all messages that were lost the first time.

When the resend request 2 (11, 12) is received, the resend response process 15 reads out the requested message (11, 12) from the resend data buffer 13 and uses TCP / TCP as the resend response message 2 (11, 12). It is transmitted to the resend request processing 25 by IP (step 83). This ensures that the data will be retransmitted in the second retransmission.

When the resend response message 2 (11, 12) is received, the resend request process 25 sends the received message to the resend data buffer 26.
Then, the file creation processing 24 is notified that the message has been received (step 155).

Upon receipt of this notification, the file creation processing 24 checks the serial number, updates the serial number, stores the retransmitted message in the temporary storage file 27 (step 127), and then holds it in the received data buffer 23. Proceed to processing of continuation message (step 128).

FIG. 11 shows the flow of the second retransmission processing for the start message. This figure is drawn as the process following FIG. Since the same steps as those in the processing shown in FIG. 9 and the above-mentioned FIG. 10 are designated by the same reference numerals, the processing in this case can be easily understood from FIG.

FIG. 12 shows the flow of forced termination processing due to overflow of the received data buffer. This figure is drawn as a continuation of FIG.

Retransmission request 1 (11, 12) occurs due to the lack of continuous telegrams (11) (12), and in response to this, file transmission process 12 redistributes continuous telegrams (11, 12) ( Step 41). After that, the file transmission process 12 restarts the distribution from the continuous message (14) (steps 40 and 42).

The reception process 22 receives these continuation telegrams (14) and the like and continues to sequentially store them in the reception data buffer 23 (step 105). The file creation process 24 is in a standby state until it processes the retransmitted message, so
No message is read from the reception data buffer 23 (step 130).

If there are many retransmitted messages and they do not reach the resend request processing 25, many messages will overflow in the receive data buffer 23 with the passage of time.

The reception data buffer 23 has a flag for each area in which a message is stored. The reception process 22 sets this flag when the message is written, and the file creation process 24 resets this flag when the message is read. . Therefore reception processing
The flag 22 can know that there is no room for writing a message in the received data buffer 23 due to the state of the flag.

When the reception data buffer 23 becomes full and it is no longer possible to write a message, the reception process 22 sends a message of forced termination to the file creation process 24 (step 106). Upon receiving this, the file creation processing 24 sends a forced termination to the resend request processing 25 (step 131).

Upon receiving the forced termination, the retransmission request processing 25 resets the above-mentioned retransmission monitoring timer, and transmits the forced termination to the retransmission response processing 15 by TCP / IP (step 156).

Since the resend response process 15 passes the received forced termination to the resend management process 14 (step 84), the resend management process 14
Stores the fact that the file transfer has been compulsorily completed for the receiving device and notifies the file transmission process 12 to that effect (step 65). It goes without saying that the file transmission process 12 continues to deliver the continuation message for another normal receiving device 20.

FIG. 13 and FIG. 14 show the flow of processing when a transmission line failure occurs and is then restored. The same steps as those in the processes shown in FIGS. 6 and 7 are designated by the same reference numerals.

As described above, the reception process 22 is provided with the failure detection timer, and by this means, it is monitored whether or not the communication state has been lost for a certain period of time T2 or longer, which is longer than the message transmission period T1.

Since the failure detection timer times out in the reception processing 22 of the receiving device which has not received the message for the fixed time T2 or more due to the transmission path failure, the reception processing 22 sends the failure notification to the file creation processing 24. Send (step 107).

Upon receipt of this notification, the file creation processing 24 adds the serial number of the message normally received at the end and sends a failure notification to the resend request processing 25 (step 132). The resend request process 25 sends this failure notification to the resend response process 15 by TCP /
It is transmitted by IP (step 157).

This failure notification is passed from the resend response process 15 to the resend management process 14 (step 85). Upon receiving the failure notification, the resend management processing 14 stores in the resend management table 14A the identification number of the receiving device 20 that sent the failure notification and the serial number of the last message received by the receiving device, and sends the failure notification to a file. It is given to the process 12 (step 66).

When the file transmission process 12 receives the failure notification, the file transmission process 12 distributes the dummy electronic message to all the receiving devices 20 in the above-mentioned constant time period T1 (step 43).

When receiving the dummy message, the receiving device 20 which has not issued the fault notification recognizes that one of the receiving devices has a fault.

The receiving device which has issued the fault notification does not receive the dummy electronic message as long as the fault continues. The reception of the dummy message by the reception process 22 of the reception device 20 that has issued the failure notification means that the failure has been recovered. Therefore, when the receiving process 22 receives the dummy message, it sends a recovery notice to the file creating process 24 (step 108).
). The recovery notification is sent from the resend request process 25 through the file creation process 24 by the resend response process of the transmitter 10 by TCP / IP.
It is transmitted to 15 (steps 133 and 158).

The restoration notice is further given from the resend response process 15 to the resend management process 14 (step 86).

The retransmission management processing 14 stores in the retransmission management table 14A the receiving device 20 in which a failure has occurred and the last serial number received by the receiving device as described above. Retransmission management process
If there is a failure in the plurality of receiving devices 20, 14 waits for the recovery notifications from all of these receiving devices.

If a recovery notice is transmitted from all the receiving devices 20 that have failed within the failure recovery monitoring time described later,
The resend management process 14 gives a recovery notification to the file transmission process 12 and also notifies the file transmission process 12 of the smallest serial number received from the last receiving serial numbers by the failed receiving device (step 67).

When this serial number is received, file transmission processing 12
Restarts delivery of the continuous telegram from the serial number obtained by adding 1 to the smallest serial number (step 44). In this way,
When a failure occurs and it is recovered, a continuation message is delivered to the receiving device 20 without any missing number (may be duplicated in some receiving devices).

The receiving device 20 restarts the reception of the delivered electronic message and the processing for it (steps 102 and 122).

FIG. 15 shows the flow of processing in the case where a transmission line failure has occurred and it cannot be recovered. This figure is drawn as a continuation of FIG.

The retransmission management processing 14 of the transmission device 10 activates the above-mentioned failure recovery monitoring timer when the first failure notification is received. Even if the failure recovery monitoring timer times out, if the recovery notification is not received from at least one of the failed receiving devices 20, the resend management processing 14 receives the recovery notification not received. In order to forcibly terminate the device 20, the retransmission response processing 15 is notified of the forced termination. Further, if there is at least one receiving device in which no failure has occurred or one in which the error has been recovered, a recovery notice is given to the file transmission processing 12 (step 68).

Upon receiving the restoration notice, the file transmission process 12 resumes the delivery of the continuous telegram as described above (step 4).
Four).

When the resend response process 15 receives the notification of the forced termination, the resend response process 15 sends the forced termination by TCP / IP to the resend request process 25 of the receiving device 20 in which the failure is not recovered (step 87). .

If the corresponding resend request process 25 receives this forced termination notice, this forced termination notice is transmitted to the reception process 22 via the file creation process 24. Therefore,
The reception process 22 thereafter discards the message even if it is received (steps 159, 134, 109).
).

FIG. 16 shows the flow of processing when electronic messages having the same serial number are received in a superposed manner.

As described above, when the failure occurs and the recovery is made thereafter, the receiving device 20 may receive the electronic message having the same serial number. Since the file creation processing 24 performs the serial number check as described above, it is possible to find that the serial numbers are duplicated. In such a case, the file creation processing 24 discards the double received message without writing it in the temporary storage file 27 (step 135).

17 and 18 show the flow of processing when the final message is missing. Also in this case, the processing is basically the same as the processing of the retransmission request 1. Therefore, substantially the same steps as those shown in FIGS. 4, 5, 6 and 7 are designated by the same reference numerals.

The loss of the final message is detected not as a serial number check but as a non-communication state for a certain period of time T2 or more as in the failure detection. Therefore, the reception processing 22 sends a failure notification to the file creation processing 24. Send (step 110).

Since the serial number of the last message is known in advance from the contents of the data (main body) of the start message, the file creation process will be performed if the message of the previous serial number is normally received.
24 recognizes this as an error in the final message and gives a resend request 1 (100) to resend request processing 25 (step 136).

Since the resend request process 25 sends resend request 1 (100) to the resend response process 15 (step 152), the final message is re-distributed from the file sending process 12 (step 8).
2, 64, 46).

When the receiving device can correctly receive this final electronic message, the end notification is given from the receiving device 20 to the transmitting device 10 and the file transfer ends (steps 153, 151, 123).
, 125, 104, 81, 63, 47). After the file transmission process 12 gives an end notification to the resend management process 14 (step 3
6) If there is a receiving device that does not send the end notification even after the set time of the end waiting timer elapses, the resend management process 14 records a file transfer failure for that receiving device.

It is needless to say that the second retransmitting as well as the first retransmitting can be performed for the final missing message.

[Brief description of drawings]

FIG. 1 is a block diagram showing an overall configuration of a broadcast file transfer system.

FIG. 2 is a block diagram showing a functional configuration of a transmission device and a reception device.

FIG. 3 shows a format of a file transfer message.

FIG. 4 is a flow chart showing a flow of processing when file transfer is normally performed.

FIG. 5 is a flow chart showing a flow of processing when file transfer is normally performed.

FIG. 6 is a flow chart showing a flow of a first retransmission process due to a continuation telegram omission.

FIG. 7 is a flow chart showing the flow of a first retransmission process due to a continuation telegram omission.

FIG. 8 is a flow chart showing a flow of a first retransmission process due to a missing start message.

FIG. 9 is a flow chart showing a flow of a first retransmission process due to a missing start message.

FIG. 10 is a flow chart showing a flow of a second retransmission process due to a continuation telegram omission.

FIG. 11 is a flow chart showing a flow of a second retransmission process due to a missing start message.

FIG. 12 is a flow chart showing a flow of termination processing due to overflow of a reception data buffer.

FIG. 13 is a flow chart showing the flow of processing when a failure occurs in a transmission line and then recovery is performed.

FIG. 14 is a flow chart showing the flow of processing when a failure occurs in a transmission line and then recovery is performed.

FIG. 15 is a flow chart showing the flow of termination processing when a failure occurs in a transmission line and recovery is impossible.

FIG. 16 is a flow chart showing the flow of processing when a message with the same serial number is received twice.

FIG. 17 is a flow chart showing the flow of the first retransmission process due to the loss of the final telegram.

FIG. 18 is a flow chart showing the flow of a first retransmission process due to the loss of a final telegram.

[Explanation of symbols]

 8 transmission line 9 relay device 10 sending device 11 sending file 12 file sending process 13 resending data buffer 14 resending management process 14A resending management table 15 resending response process 20 receiving device 21 receiving file 22 receiving process 23 receiving data buffer 24 creating file Processing 24A Serial number management table 25 Retransmission request processing 26 Retransmission data buffer 27 Temporary storage file

Front page continuation (72) Inventor Kazuhiko Yoda 1-9-1, Nihonbashi, Chuo-ku, Tokyo Inside Nomura Research Institute, Inc. (72) Inventor Satoshi Nishino, 134 Kobe-cho, Hodogaya-ku, Yokohama, Kanagawa Nomura (72) Inventor Tsutomu Miyawaki 6-7 Nihombashi Koamimachi, Chuo-ku, Tokyo Daini Yamaman Building Nomura Research Institute, Ltd. Nihonbashi Software Center

Claims (22)

[Claims] 1. The transmitting station divides a file to be transferred into a plurality of blocks, and divides it into a start message including a start sequence number and a last sequence number to be included in an end message, and a sequence number sequentially incremented from the start sequence number. A continuous telegram sent after the start telegram, including a file data block, and at least the final telegram sent at the end, and the end telegram sent at the end are transmitted using a communication protocol suitable for broadcast delivery. Broadcast to the receiving station, and when the receiving station specifies a serial number and makes a resend request, the electronic message with the specified serial number is retransmitted. When a received message is received, the serial number included in the received message is checked, and if it is determined that there is a missing number, a resend request specifying the missing sequence number is sent, and the message that passed the serial number check is checked. Stored in yl, broadcast file transfer method. 2. When the receiving station checks the serial number included in the received message and determines that there is a missing number, it sends the first resend request specifying the missing serial number, and the first resending request is sent. After sending the resend request, if the message with the specified serial number is not received even after the lapse of a predetermined time, the second resend request is sent, and the sending station sends the first resend from any receiving station. When a request is made, the message with the specified serial number is broadcast and redelivered using a communication protocol suitable for broadcast delivery, and when the second resend request is made, the requested message is sent as a second message. The broadcast file transfer method according to claim 1, wherein the retransmission request is retransmitted to the receiving station that transmitted the retransmission request. 3. The transmitting station periodically transmits a message at a first fixed time interval, and the receiving station receives the message during a second fixed time which is longer than the first fixed time. The broadcast file transfer method according to claim 1, further comprising checking whether or not the failure is detected, and transmitting a failure notification to the transmitting station when the failure is detected. 4. The transmitting station distributes a dummy message at the first fixed time interval when it receives a failure notification, and sends a recovery notification when the dummy message is received at the receiving station that has sent the failure notification. The broadcast file transfer method according to claim 3, wherein the broadcast file is transmitted to the station. 5. The delivery station resumes delivery of the start, continuation or termination message when a restoration notice is sent within a predetermined time from all the receiving stations that have sent the fault notice. Broadcast file transfer method. 6. The transmitting station, if any of the receiving stations that has transmitted the failure notification does not transmit the recovery notification within a predetermined time, the forced termination is notified to the receiving station. Broadcast file transfer method. 7. The broadcast file transfer method according to claim 6, wherein the transmitting station stores the receiving station notified of the forced termination. 8. The transmission of the start, continuation, or termination message is restarted if there is a reception station that does not transmit a failure notification or a reception station that has transmitted a restoration notification within the predetermined time, in the transmission station. Broadcast file transfer method described. 9. The transmitting station divides a file to be transferred into a plurality of blocks after data compression processing, and after the receiving station receives all telegrams, decompresses the received data block and The broadcast file transfer method according to claim 1, wherein the obtained file is stored in a received file. 10. The broadcast file transfer method according to claim 1, wherein in the transmitting station, the start message includes an execution shell script indicating a process to be executed by the receiving station. 11. A transmitter having a file to be transferred,
And a plurality of receiving devices capable of communicating with this transmitting device, the transmitting device divides a file to be transferred into a plurality of blocks, and a start message including a beginning serial number and a final serial number to be included in an end message,
The continuation message that includes a sequence number that is sequentially incremented from the beginning sequence number and the divided file data block, that is, the continuation message that is transmitted after the start message, and the last message that includes at least the last sequence number and that is transmitted last are the same. Using a communication protocol suitable for broadcast delivery, a delivery means for broadcast delivery to a plurality of receiving devices, and when a receiving device specifies a serial number and makes a resend request, a message with the specified serial number is sent. Each receiving device has a resending means for resending, and each receiving device checks the receiving means for receiving the telegram delivered from the transmitting station, checks the serial number included in the received telegram, and when it determines that there is a missing number, the missing serial number A broadcast file transfer system equipped with a resend request means for sending a resend request that specifies, and a means for storing a message that has passed the serial number check in a file. 12. When the resending request means in the receiving device checks the serial number included in the received electronic message and determines that there is a missing number, it sends the first resending request specifying the missing serial number. A first resend request means, and a second resend request for sending a second resend request when a message having a designated serial number is not received even after a lapse of a predetermined time after sending the first resend request. When the first retransmission request is made from any of the receiving devices, the above-mentioned retransmitting device in the transmitting device uses a communication protocol suitable for broadcast delivery of the telegram of the designated serial number. A first retransmitting means for broadcast redelivery, and a second retransmitting means for retransmitting the requested electronic message toward the receiving device which has transmitted the second retransmission request when there is a second retransmission request. According to claim 11, consisting of Broadcast file transfer system. 13. The transmitting means of the transmitting device periodically transmits a message at a first fixed time interval, and the receiving device sets a second fixed time longer than the first fixed time. 12. The broadcast file transfer system according to claim 11, further comprising: failure detection means for checking whether or not a message has been received between them, determining failure detection if there is not, and transmitting a failure notification to a transmitting station. 14. The delivery means of the transmitting device delivers a dummy electronic message at the first constant time interval when a failure notification is received, and the failure detection means sends the failure notification, and then 14. The broadcast file transfer system according to claim 13, wherein the receiving device is provided with recovery notifying means for transmitting a recovery notification to the transmitting station when the receiving means receives the dummy message. 15. The delivery means of the sending device restarts the delivery of the start, continuation or end message when a restoration notification is sent within a predetermined time from all the receiving devices that sent the failure notification. The broadcast file transfer system according to claim 14. 16. The transmission device further comprises means for notifying the receiving station of forced termination if there is a receiving station that has transmitted the failure notification and does not transmit the restoration notification within a predetermined time. The broadcast file transfer system according to claim 14. 17. The broadcast file transfer system according to claim 16, wherein said notifying means of the transmitting device stores the receiving station which has notified the forced termination. 18. The delivery means of the sending device restarts delivery of the start, continuation or end message if there is a receiving station that does not send a failure notification or a receiving station that sends a restoration notification within the predetermined time. The broadcast file transfer system according to claim 16, wherein 19. The distribution means of the transmission device compresses a file to be transferred and then divides the data into a plurality of blocks for distribution, and the storage means of the reception device receives all electronic messages. 12. The broadcast file transfer system according to claim 11, wherein the data block received later is expanded, and the file obtained by the expansion is stored in the received file. 20. The broadcast file transfer system according to claim 11, wherein the distribution means of the transmission device includes an execution shell script indicating a process to be executed by the reception station in the start message. 21. A transmission file in which file data to be transferred is stored, file data is read from the transmission file, this file data is divided into a plurality of blocks, and an initial serial number and a final serial number to be included in an end message are provided. Including a start message including a start message, a sequence number that is sequentially incremented from the beginning sequence number, and a divided file data block, a continuation message that is transmitted after the start message, and at least the last sequence number that is transmitted last. A delivery method for delivering an end message to a plurality of receiving devices by using a communication protocol suitable for broadcast delivery, and a message with a specified serial number when a resend request with a specified serial number is received. A sending device for sending a broadcast file, which is provided with a resending means for resending the. 22. A first resending means for, when the resending means receives a first resend request, re-deliver a telegram of a designated serial number by using a communication protocol suitable for broadcast delivery. And a second resending unit that resends the requested message to the receiving device that sent the second resend request when the second resend request is received for the same serial number message. A transmitting device for transferring a broadcast file according to Item 21.