Data file distribution method by multicast

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to a method of delivering a specified file to multiple points by multicast, and more particularly to a method of delivering a designated file to multiple points by multicast using a wireless link such as a satellite line. It is a thing.

【0002】

[Conventional technology]

A file to be distributed as a conventional technique of this type is divided into a plurality of blocks and transmitted to multicast from a transmitting station, and an error DTU (Data Transmission Unit) that could not be received is retransmitted from a receiving station on the client side, and the file is transmitted. An MFTP (Multicast File Transmission Protocal) method has been proposed in which file transfer is completed by resending the DTU for which a resend request has been made from the transmitting side (see Japanese Patent Application Laid-Open No. 10-512726).

【0003】

Fig. 28 (a) shows the data delivery packet format by this MFTP method, and the file consists of blocks # 1, block # 2, block # 3, and block # 4, and each block is frame # 11 ~. It consists of frame # 1N, and each frame contains MFTP-OH, which is an OH (overhead) used for communication between MFTP-type transmission / reception processors, and MFTP-OH (option), which is used as an option. Each frame containing this MFTP-OH (optional) constitutes 1DTU, and in addition to this 1DTU and MFTP-OH, UDP (User Datagram Protocol) -OH and IP (Internet Protocol) 1MTU (Multicast Transmission Unit) is configured including IP-OH which is OH for. Further, FIG. 28 (b) shows the retransmission request packet format by the MFTP method, and displays the reception status for each bit in 1DTU. In this example, a cross indicates unreceived.

【0004 】

[Problems to be Solved by the Invention]

In this conventional MFTP method, a method of receiving response confirmation including a DTU instruction requesting retransmission from a plurality of receiving stations is adopted during the transmission of the distribution file by multicast. In the MFTP method, data errors are represented by bitmaps, so even if an error is 1 DTU, a retransmission request packet consisting of a bitmap [usually a size of 1 MTU (= 1500 bytes)] corresponding to 1 block. Needs to be returned from the receiving station to the transmitting station. In the MFTP method, it is carried out in a communication system that secures an exclusive line such as a telephone line from a plurality of receiving stations in the direction of the transmitting station (also referred to as "upward direction"), but the retransmission request packets are discrete. In a communication system that uses a wireless transmission line such as a satellite line shared by multiple access in the uplink direction, there is a big restriction in performing efficient error retransmission processing. And have drawbacks.

【0005】

The present invention provides a multi-toast file distribution method capable of efficiently executing highly reliable multicast data file distribution even in a communication system using a wireless transmission line such as a satellite line shared by multiple access in the uplink direction. It is a thing.

【0006】

[Means for solving problems]

In order to achieve this object, the multicast file distribution method according to the present invention is a data file distribution method by multicast, in which a step of transmitting a data file composed of a plurality of blocks to each distribution destination and after the distribution of the data file is completed. At each delivery destination, a step of testing whether or not any of the transmitted packets in the data file consisting of the plurality of blocks is erroneous, and after the distribution of the data file is completed, the data file is composed of the plurality of blocks. One of the delivery destinations that detected that there is an error in one of the transmitted packets by the test for the data file detects that there is an error in the data file received at the delivery destination to the transmission side. A step of sending a retransmission request signal requesting retransmission of the transmitted packet so that the retransmission request signal indicates the offset position of the error data in the transmission packet and the data length of the error data. The configuration is characterized in that, in response to the retransmission request signal, the transmission side includes a step of retransmitting the transmission packet detected to be the error to any of the distribution destinations. Have. The retransmission request can be defined to send, for example, a total of 8 bytes, which is 4 bytes representing the offset position of the erroneous data delivery packet and 4 bytes representing the data length of the erroneous data.

【0007】

BEST MODE FOR CARRYING OUT THE INVENTION

The functional outline of the method of the present invention is as follows. (1) Outline of required functions as a protocol Delivery method This is a limited delivery method (with delivery confirmation), in which the sender confirms the delivery only to the recipients who have registered (registration) to receive at the start of file transfer. Delivery confirmation method Delivery confirmation is performed by connecting from the sender to the receiver. The management method is a centralized management method in which the server of the broadcast distribution source confirms delivery to all recipients (registered). Delivery speed setting function This is a function that allows the sender to set the multicast broadcast delivery speed in consideration of the line speed and the number of recipients. Delivery destination folder specification function This is a function that allows you to specify the recipient's folder for storing files delivered by the sender. File legitimacy function In the broadcast distribution phase and broadcast retransmission phase, when file data is transmitted from the server to the client, a checksum check is performed on a packet-by-packet basis to confirm the validity of the file transmission.

【0008】

The contents of the above functions will be further described below. (2) Protocol stack Figure 1 shows the protocol stack of the multicast file transfer software for implementing the method of the present invention.

【0009】

(3) Communication procedure The communication procedure is the "announcement / registration phase" that distributes file distribution information, the "broadcast distribution phase" that distributes broadcasts, the "broadcast resend phase" that resends broadcasts, and the "delivery" that confirms delivery. It is divided into "confirmation phase". All data distribution from the server to the client in the announcement / registration phase, broadcast distribution phase, and broadcast resend phase is performed by multicast-compatible UDP distribution. On the other hand, data transmission from the client to the server in the announcement / registration phase, broadcast retransmission phase, and delivery confirmation phase, and data transmission from the server to the client in the delivery confirmation phase are performed by unicast UDP distribution. Each sequence is shown in Fig. 2, Fig. 3, Fig. 4, and Fig. 5.

【0010】

Announcement Registration Phase The server sends a "broadcast distribution start announcement packet" using the multicast IP address for the announcement by the distribution start request trigger. In addition to the MF common header information, this packet contains the file name, file size, delivery speed, multicast IP address for data broadcasting, and boat number information to be transmitted. After transmitting the first "broadcast delivery start announcement packet", the server further periodically (every fixed time length specified by the Ts4 timer) sends a "broadcast delivery start announcement packet". When the server receives "registration packets" from all clients belonging to the GroupID specified as the destination, or after a certain period of time specified by the timer Ts1, these are used as transmission start triggers and the server shifts to the broadcast distribution phase. To do. In addition, a delivery confirmation list is created according to the contents of the packets received during the registration reception period, and the application program (Application Program) is created before the broadcast retransmission phase starts. Ask: AP) for confirmation. The client receives the "broadcast distribution start announcement packet", and if it is the Group ID to which the station belongs, after inquiring to the AP, sends back the "registration packet" including the result (registration code) to the server. , Move to the broadcast distribution phase. The program ends when the Tc3 timer that specifies the timeout between packets times out.

【0011】

Broadcast distribution phase The server sends a "file data packet" according to the transmission start trigger. The "file data packet" sends the offset position in the file, the checksum value of the file data information in the packet, and the file data information. Therefore, even if the client cannot receive the "file data packet" on the way, it is possible to continue receiving the data. When the data transmission is completed, the "broadcast delivery end packet" is finally transmitted, and if the confirmation of the delivery confirmation list by the AP is completed, the process shifts to the broadcast resend phase. Note that different port numbers are used for transmission of the "file data packet" and the "broadcast delivery end packet". While receiving the "file data packet", the client creates a retransmission request data list when it detects a missing file data. In addition, each time a "file data packet" is received, the checksum value of the received file data is calculated and compared with the checksum value calculated by the server. If the checksum value calculated by the server and the checksum value calculated by the client are different, a retransmission request data list is created. After receiving the "broadcast delivery end packet", the client shifts to the broadcast resend phase. The program ends when the Tc3 timer times out.

【0012】

Broadcast resend phase The server waits for the retransmission request after sending the "broadcast delivery end packet" or the "broadcast retransmission end packet" of the retransmission data, and waits for the "retransmission request packet" and "retransmission request" from the client until the Ts2 timer times out. Wait for "end packet". The server retransmits the data list based on the missed reception list received from the client after the timer Ts2 times out or after receiving the "retransmission request (end) packet" from all the clients registered in the delivery confirmation list. Create and send a "broadcast retransmission start packet" and a "broadcast retransmission data packet" with the same multicast IP address as the broadcast distribution phase. The broadcast resend phase is repeated up to N2 (described later) until the missed reception list of all registrants in the delivery confirmation list becomes empty or the Ts2 timer times out. After the broadcast retransmission phase ends, the server shifts to the delivery confirmation phase. As in the broadcast distribution phase, different port numbers are used for transmission of the "broadcast retransmission data packet" and the "broadcast retransmission end packet". When the client detects the omission of file data as in the broadcast distribution phase, it creates a retransmission request data list. Further, as in the broadcast delivery phase, the checksum value calculated by the server and the checksum value calculated by the client are compared for each packet, and if the values are different, a retransmission request data list is created. After receiving the "broadcast delivery end packet" or the "broadcast retransmission end packet", the "retransmission request packet" and the "retransmission request end packet" are transmitted to the server. If there is no omission of file data, a "retransmission request end packet" consisting of only the common header part is sent. When the client receives the "delivery confirmation start packet", it shifts to the delivery confirmation phase. The program ends when the Tc3 timer times out.

【0013】

Delivery confirmation phase The server confirms the delivery of all clients in the delivery confirmation list to ensure the reliability of the file transfer. When the client receives the "delivery confirmation start packet", it sends a "delivery confirmation response packet" including the confirmation result. The program ends when the Tc3 timer times out.

【0014】

(4) Packet format The basic packet format of the announcement / registration phase is shown in Fig. 6, the basic packet format of the broadcast delivery phase is shown in Fig. 7, the basic packet format of the broadcast retransmission phase is shown in Fig. 8, and the basic packet format of the delivery confirmation phase is shown in Fig. 9.

【0015】

(5) Common header Figure 10 shows the format of the common header (= MF header) that is common to all packets.

【0016】

Each field of the common header part will be described in detail below. Version The length is 1 byte and is used to identify the protocol version. Control The length is 1 byte and is used to identify the packets shown in Table 1.

【0017】

[table 1]

<img file="JP2002124992A_D0001.tif" />【0018】

Stn ID The Stn ID is 4 bytes long and is an identifier for identifying the sender of the packet. Group ID The Group ID is 4 bytes long and is an identifier for identifying the recipient's group. Ref ID Ref ID is an identifier for identifying each packet from the start to the completion of file transfer, and is a 2-byte long number that manages servers so that they are not duplicated. All packets from the start to the end of one file transfer have the same Ref ID and are distinguished from other files of file transfer. Since it is 2 bytes long, it can be used for 65535 file transfers without duplication, but it is reset and used based on the agreement between the sender and the receiver. Since file transfers are distinguished by Ref ID, it is possible to proceed with multiple file transfers at the same time. When there are multiple senders in the same multicast environment, it is necessary to determine the range of Ref IDs that can be used for each sender in advance. Length Length is a 2-byte length field that represents the length of the packet, and represents the length of the information portion as shown in FIG.

【0019】

(6) Packet type and format 1) Broadcast start announcement packet Sent by the server during the announcement / registration phase. The packet format is shown in Figure 12. This packet is used as a signal to start the file broadcast distribution. During the announcement / registration phase, the server periodically sends out this packet at regular intervals determined by the Ts4 timer. The client associates the Ref ID with the multicast address, port number, delivery speed, file size, and file name of the "file data packet" received in the broadcast delivery phase by the first received packet.

【0020】

2) Registration packet Sent by the client during the announcement / registration phase. The packet format is shown in Figure 13. This packet is the same as the "broadcast delivery start announcement packet", but the Stn ID of the common header part is the client's Stn ID. This packet is used to notify the server of file reception. The server grasps the recipient to be confirmed for delivery by the "registration packet" and creates a delivery confirmation list. The server starts the broadcast delivery phase after the Ts1 timer times out or after receiving "registration packets" from all clients belonging to the Group ID specified as the destination.

【0021】

3) File data packet The server sends in the broadcast distribution phase. The packet format is shown in Figure 14. This packet contains the binary data of the file to be transferred, the sequence number which is an offset value indicating the position of the data in the file, and the checksum value of the binary data calculated by the server. The sequence number has a length of 4 bytes, and is an offset value expressed in byte units indicating the position occupied by the data carried by the packet in the file. The client reconstructs the file from the sequence number and Length value of this packet. If the received data is missing due to packet error or loss, create a retransmission request data list consisting of a list of the offset value (sequence number) of the missing data part and the length (length value) of the missing data. To do. In addition, the client compares the sent checksum value with the checksum value calculated from the received binary data to determine the success / failure of data transfer in packet units. If the checksum check reveals a transfer failure, the offset value and length value of the relevant data are added to the retransmission request data list.

【0022】

4) Broadcast end packet The server sends in the broadcast distribution phase. The packet format is shown in Figure 15. The server sends this packet and activates the Ts2 timer as a signal to start the broadcast retransmission phase after all data transmission is completed. The server sends the "broadcast delivery end packet" at the cycle specified by the timer Ts5 until it receives the "retransmission request end packet" from all the recipients registered in the delivery confirmation list or the Ts2 timer times out. Keep sending. After receiving this packet for the first time, the client considers that the broadcast distribution by multicast has been completed and shifts to the broadcast retransmission phase. When the client receives this packet, it sends a "retransmission request (end) packet" to the server.

【0023】

5) Broadcast retransmission start packet The server sends in the broadcast resend phase. The packet format is shown in Figure 16. The server sends a "broadcast retransmission start packet" after the Ts2 timer times out, or after receiving a "retransmission request end packet" from all clients registered in the delivery confirmation list, and sends a "broadcast retransmission data packet". To start. Upon receiving this packet, the client side signals the start of broadcast retransmission by multicast.

【0024】

6) Broadcast resend end packet The server sends in the broadcast resend phase. The packet format is the same as that of the broadcast retransmission start packet in FIG. After sending all the "broadcast retransmission data packets", the server sends this packet to notify the end of the broadcast retransmission phase and activates the Ts2 timer. The server continues to send this packet at a fixed cycle specified by the Ts5 timer after the timer Ts2 times out or until it receives the "retransmission request end packet" from all the clients registered in the delivery confirmation list. When the client receives this packet, it sends a "retransmission request packet" and a "retransmission request end packet" to the server.

【0025】

7) Retransmission request packet, retransmission request end packet The packet format of the packet transmitted by the client in the broadcast retransmission phase is shown in FIG. This is a packet requesting retransmission of data that the client could not receive in the broadcast distribution phase or the broadcast retransmission phase. The client sends a set of missing data (offset value + data length) based on the created retransmission request data list to the server. A plurality of (offset value + data value) pairs may be included in this packet. On the server side, after receiving the "broadcast delivery (retransmission) end packet", this packet from each client is accepted until the Ts2 timer times out, and a data retransmission request list is created based on the information of this packet. When each client has a large number of retransmission request data and the "retransmission request packet" spans multiple packets, the first to (last-1) th is the "retransmission request packet", and the last is the "retransmission request end packet". To the server. If the received missing data fits in one packet, only the "retransmission request end packet" is transmitted.

【0026】

8) Broadcast retransmission data packet The server sends in the broadcast resend phase. The packet format is the same as the file data packet in FIG. This packet is created and transmitted according to the retransmission request list. The client supplements the missing part with this packet.

【0027】

9) Delivery confirmation start packet In the delivery confirmation phase, the server sends to request the client to confirm delivery and activates the Ts3 timer. The server continues to send a "delivery confirmation start packet" for each Ts6 timer timeout until it receives a "delivery confirmation response packet" from all recipients registered in the delivery confirmation list or the Ts3 timer times out. .. The packet format is shown in Figure 18. Upon receiving this packet, the client enters the delivery confirmation phase. The client sends back a "delivery confirmation response packet" containing the response code to the server.

【0028】

10) Delivery confirmation start response packet In the delivery confirmation phase, when the client receives the "delivery confirmation start packet", the packet is sent back to the server. The packet format is shown in Figure 19.

【0029】

11) Delivery confirmation end packet This packet is sent when the server receives a "delivery confirmation response packet" from all clients, or when the Ts3 timer times out. The packet format is shown in Figure 20.

【0030】

(7) Timer The timer notation is TcY for the timer held by the client and TsX for the timer waiting on the server. TcY is a numerical value calculated according to a certain algorithm after the client receives the "broadcast delivery start announcement packet". On the other hand, TsX is a numerical value set and handed over by the AP.

【0031】

Tc3 timer The Tc3 timer is a timer on the client side and is used to guarantee the reliable end of file transfer. In each phase, the Tc3 timer restarts each time it receives an appropriate packet for each phase. The client terminates the program when the Tc3 timer times out.

【0032】

Ts1 timer The Ts1 timer sets the time for the server to accept "registration packets" in the announcement / registration phase. Registration is closed due to a timeout, a recipient list is created, and it is passed to the AP.

【0033】

Ts2 timer A timer used by the server that specifies the waiting time for the "retransmission request end packet" from the time of transmission of the "broadcast delivery end packet" or "broadcast retransmission end packet". When the timeout occurs, the next broadcast retransmission phase is started.

【0034】

Ts3 timer The Ts3 timer is a timer used by the server in the delivery confirmation phase and is activated when the first "delivery confirmation start packet" is sent. It is the waiting time of the "delivery confirmation response packet", and stops when the "delivery confirmation response packet" is received from all the clients in the delivery confirmation list. If there is a client that does not return the "delivery confirmation response packet" even if the Ts3 timer times out, that client is recorded in the server log as a delivery confirmation failure.

【0035】

Ts4 timer The Ts4 timer is the delivery interval of the "broadcast delivery start announcement packet". Every time the Ts4 timer times out, the server delivers the "broadcast start announcement packet" until the Ts1 timeout occurs.

【0036】

Ts5 timer The Ts5 timer is the delivery interval of the "broadcast delivery (retransmission) end packet". The server "broadcasts (resends)" each time the Ts5 timer times out to the client until it receives a "resend request packet" from all clients (registered) in the receive list or the Ts2 timer times out. Continue to deliver "end packet".

【0037】

Ts6 timer The Ts6 timer is the delivery interval of the "delivery confirmation start packet". The server continues to deliver "delivery confirmation start packets" to clients each time the Ts6 timer times out until it receives "delivery confirmation response packets" from all clients in the delivery confirmation list or the Ts3 timer times out. ..

【0038】

(8) N2 N2 specifies the number of repetitions of the broadcast retransmission phase.

【0039】

(9) How to start the delivery confirmation procedure The server sends a "delivery confirmation start packet" and waits for the Ts3 timer to time out or for all recipients in the recipient list to return a "delivery confirmation response packet". If the "delivery confirmation response packet" is not returned from all the registered recipients even after the lapse of a certain period specified by the Ts6 timer, the "delivery confirmation start packet" is transmitted again. For clients that do not return the "delivery confirmation response packet" even if the Ts3 timer times out, it is recorded as a delivery confirmation failure in the log.

【0040】

A specific embodiment of the present invention will be described based on the above description of each function. FIG. 21 (a) shows the data delivery packet format used in the multicast file delivery method (also referred to as the MSAT method) according to the present invention, and the file consists of block # 1, block # 2, block # 3, and block # 4. In this case, MSAT-OH, which is an OH (overhead) used for communication between MSAT transmission / reception processors, is added to each block # 1 to block # 4. Each frame containing this MSAT-OH also contains UDP (User Datagram Protocol) -OH and IP-OH, which is an OH for IP (Internet Protocol). The MSAT-OH is composed of a control signal Control, a station identification signal Stn ID, a group identification signal Group ID, a block identification signal Ref ID, and a block length Length.

【0041】

Furthermore, Fig. 21 (b) shows the retransmission request packet format by the MSAT method, and the unit of the retransmission request is composed of a total of 8 bytes, which is the sequence number (4 bytes) indicating the offset position and the data length (4 bytes). There is. As a result, the retransmission request can be executed with a short number of bytes for a single error and a continuous error.

【0042】

[Example]

The operation of the method of the present invention will be described below. FIG. 22 is a flowchart showing an operation on the transmitting side of the announcement / registration / broadcast distribution phase, which is a preliminary operation for starting data transmission in the method of the present invention. In the operation in this case, the operation starts (S)₀) After that, start the Ts1 timer and Ts4 timer, and send the "broadcast start announcement packet" (S).₁), Check if you are receiving a "registration packet" from the recipient (S)₂). This inspection (S₂) If YES, add to the delivery confirmation list (S)₃), S₂When the test is NO and when it is added to the "delivery confirmation list" (S)₃), Check if the Ts1 timer has timed out (S)₄). This inspection (S₄) Is YES, check if the "delivery confirmation list" is generated (S)₅). This inspection (S₅When) is YES, after dividing the file data and generating a packet (S)₆), After broadcasting the "file data packet", send the "broadcast end packet" (S)₇), It will shift to the operation of the retransmission phase (* 1). S₄In the inspection of, when the Ts1 timer has not timed out NO, it is inspected whether the Ts4 timer has timed out (S).₁₀). This inspection (S₁₀When) is YES, the Ts4 timer is restarted and the "broadcast start announcement packet" is sent (S).₁₁) And and inspection (S)₁₀When) is NO, check whether the "registration packet" from the recipient is received (S)₂). S₅If the "delivery confirmation list" is not generated in the inspection of NO, the process ends (S).₉).

【0043】

FIG. 23 is a flowchart showing the operation on the receiving side of the announcement / registration / broadcast distribution phase. In the operation in this case, the operation starts (R₀) After that, check if the "broadcast start announcement packet" was received (R)₁), This inspection (R₁When) is YES, a "registration packet" from the recipient is sent (R)₂), Start the Tc3 timer (R₃), Check if the Tc3 timer has timed out (R)₄), This inspection (R₄End this phase when) is YES (R)₅). Inspection (R₄If) is NO, check if a "file data packet" has been received (R)₆), And when this check is YES, test whether the received "file data packet" is normal (R)₇), This test (R₇If) is YES, write the contents of the "file data packet" to the recording medium and restart the Tc3 timer (R)._8a). R₇If the test is NO, generate a retransmission request data list and restart the Tc3 timer (R)_8b). When the Tc3 timer is restarted in this way and inspection (R₆When) is NO, check whether the "broadcast end packet" has been received (R)₉). Inspection (R₉When) is YES, the process shifts to the retransmission phase operation (* 10) and the inspection (R) is performed.₉) Is NO, check (R)₅)Return.

【0044】

FIG. 24 is a flowchart showing the operation on the transmitting side of the retransmission phase. When the operation (* 1) of the retransmission phase in this case is started (S)₈), Start the Tc2 timer and Tc5 timer and initialize the retransmission counter (S)₁₂). Next, it is checked whether the "retransmission request packet" or "retransmission request end packet" has been received (S).₁₃). This inspection (S₁₃) Is YES, and when it is added to the "Retrans request list" (S)₁₄), And the above inspection (S)₁₃) Is NO, check if the Ts2 timer has timed out (S)₁₅)do. This inspection (S₁₅When) is YES, the "broadcast retransmission data packet" is broadcasted based on the "retransmission request list" (S).₁₆), Check if the count value of the retransmission counter exceeds the value of N2 (S)₁₇). This inspection (S₁₇When) is YES, the operation shifts to the operation of the delivery confirmation phase (* 2) (S).₂₁). Inspection (S₁₇When) is NO, the retransmission counter is counted up and the Ts5 timer is restarted (S).₁₈), And the above inspection (S)₁₅If) is NO, check if the Ts5 timer has timed out (S)₁₉). This inspection (S₁₉) Is YES, and this test (S)₁₉) Is NO, and when the Ts5 timer is restarted and a "broadcast retransmission end packet" is sent (S)₂₀), The above inspection S₁₃Return to.

【0045】

FIG. 25 is a flowchart showing the operation on the receiving side of the retransmission phase. When the operation (* 10) of the retransmission phase in this case is started (R)₁₀), Check if there is a retransmission request data list (R)₁₁), This inspection (R₁₁When) is NO, a "broadcast retransmission request end packet" is sent (R).₁₂), Shift to the operation of the delivery confirmation phase (* 20) (R₁₃). This inspection (R₁₁When) is YES, "Retransmission request packet" and "Retransmission request end packet" are transmitted (R).₁₄), Check if the "broadcast retransmission start packet" has been received (R₁₅). This inspection (R₁₅When) becomes YES, restart the Tc3 timer (R)₁₆), Check if the Tc3 timer has timed out (R)₁₇), This inspection (R₁₇When) is YES, the operation (* 10) of this retransmission phase ends (R).₁₈). R₁₅If the test is NO, check "Is the Tc3 timer timed out?" (R)₁₉), Its inspection (R₁₉), But when NO, R again₁₅And that inspection (R)₁₉When) is YES, the operation (* 10) of the retransmission phase ends (R).₁₈). R₁₇When the inspection of is NO, the inspection of whether the "broadcast retransmission data packet" has been received (R)₂₀)do. This inspection (R₂₀When) is YES, a test (R) is made to see if the received "broadcast retransmission data packet" is normal.₂₁) And this R₂₁If the test is YES, write the contents of the "broadcast retransmission data packet" to the storage medium and restart the Tc3 timer (R).₂₂). R₂₁If the check is NO, create a retransmission request data list and restart the Tc3 timer (R).₂₃). Inspection (R₂₀) Is NO, and R₂₂Or R₂₃Checks whether the "broadcast retransmission end packet" was received when the operation of₂₄). Inspection (R₂₄When) is YES, the operation of the retransmission phase (* 10) is re-executed (R).₁₀), Inspection (R₂₄) Is NO, check (R)₁₇) Return.

【0046】

FIG. 26 is a flowchart showing the operation of the transmitting side in the delivery confirmation phase. When the operation (* 12) of the delivery confirmation phase in this case is started (S)₂₁), Activates timers Ts3 and Ts6, and sends a "delivery confirmation start packet" (S)₂₂), Check that all delivery confirmations in the "Delivery Confirmation List" have been completed (S)₂₃), This inspection S₂₃When) is YES, a "delivery confirmation end packet" is sent (S).₂₄), Ends the operation of the delivery confirmation phase (S)₂₅). Inspection (S₂₃When) is NO, check if the Ts3 timer has timed out (S)₂₆), This inspection (S₂₆When) is YES, the recipient who has not confirmed the delivery in the "delivery confirmation list" is regarded as the delivery failure (S).₂₇), Send the "delivery confirmation end packet" (S₂₄), Ends the operation of the delivery confirmation phase (S)₂₅). Inspection (S₂₆When) is NO, check whether the "delivery confirmation response packet" from the recipient is received (S)₂₈) And this inspection (S)₂₈If) is YES, the delivery confirmation is completed by the recipient on the "delivery confirmation list" (S).₂₉), Check if the Ts6 timer has timed out (S)₃₀). Inspection (S₂₈Even when) is NO, check if the Ts6 timer has timed out (S)₃₀), This inspection (S₃₀If) is YES, a "delivery confirmation start packet" is sent and timer Ts6 is restarted (S).₃₁), Inspection (S₃₂) Return. Inspection (S₃₀Inspection (S) even when) is NO₂₃) Return.

【0047】

FIG. 27 is a flowchart showing the operation of the receiving side in the delivery confirmation phase. When the operation (* 20) of the delivery confirmation phase in this case is started (R)₁₃), Restarted the Tc3 timer (R₂₅After the operation of), it is inspected whether the "delivery confirmation start packet" is received (R).₂₆), This inspection (R₂₆When) becomes YES, a "delivery confirmation reply packet" is sent (R).₂₇), End this operation (* 20) (R₂₈). Inspection (R₂₆If) is NO, check if the Tc3 timer has timed out (R)₂₉), This inspection (R₂₉When) is YES, this operation (* 20) is terminated (R).₂₈). Inspection (R₂₉) Is NO, R₂₆Return to. FIG. 30 shows a specific embodiment of the present invention, in which 10 is a hub station used as a transmitting side, 11 is a host server such as a personal computer for a client, and is connected to the hub station 10 via a dedicated line 12. .. 20 is a communication satellite, 31 is a time division multiple access (TDM) communication path (for example, 2 Mega bit / sec) from hub station 10 to small earth stations 40-1, 40-2, 40-3 via communication satellite 20. ), 32, 33 are all time division multiple access (TDMA) communication paths (for example, 150 kilo bit / sec), and 41-1,41-2,41-3 are all home units (IDU), 42-1. , 42-2,42-3,42-4,42-5 are all client devices such as personal computers on the client side, and 43-1,43-2 are LANs (Local Area Network). In the two-way communication service using communication satellites shown in Fig. 30, unlike the one-way satellite service, effective use of the uplink (remote site hub station) (= shortening the retransmission request packet) is the network cost. The method of the present invention, which can shorten the "retransmission request packet", is suitable because it leads to the reduction of the number of packets and is extremely important.

【0048】

[Effect of the invention]

As described in detail above, the following effects can be obtained by the method of the present invention. In the conventional MFTP method, data errors are represented by bitmaps, so even if an error is 1 DTU, a retransmission request packet consisting of a bitmap equivalent to 1 block (usually 1 MTU (= 1500 bytes) in size) can be sent. I had to send it. On the other hand, in the multicast data file distribution method (MSAT method) of the present invention, the error is expressed by "offset position (4)" + "data length (4)" (8 bytes in total), so that it is independent. For errors and consecutive errors, a retransmission request can be made with a short number of bytes. Recently, the quality of communication lines including satellite lines has improved, and usually there are almost no errors or errors occur very rarely. In such a case, the MSAT method according to the present invention is compared with the conventional MFTP method. The "retransmission request packet" can be efficiently transmitted. Figure 29 shows the total size of the retransmission request packets generated by one receiving station with respect to the transmission file size and the line bit error rate. In reality, errors on satellite lines often occur in blocks, and in the MSAT method, when blocks are continuously incorrect, a single "offset position (4)" + "data length (4)" Since it is possible to request the retransmission of a plurality of "file data packets", the efficiency becomes even higher. In the method of the present invention, there is a concern that the number of "retransmission request packets" increases when the line quality is extremely poor, but when an error packet exceeding a certain number occurs, a retransmission request is not performed, etc. Risks can be avoided by adding restrictions.

[Simple explanation of drawings]

[Figure 1]

It is a figure which shows the protocol stack used in the method of this invention.

[Figure 2]

It is a figure which shows the sequence of the announcement / registration phase used in the method of this invention.

[Fig. 3]

It is a figure which shows the sequence of the broadcast delivery phase used in the method of this invention.

[Fig. 4]

It is a figure which shows the sequence of the broadcast retransmission phase used in the method of this invention.

[Fig. 5]

It is a figure which shows the sequence of the delivery confirmation phase used in the method of this invention.

[Fig. 6]

It is a figure which shows the basic packet format of the announcement / registration phase used in the method of this invention.

[Fig. 7]

It is a figure which shows the basic packet format of the broadcast delivery phase used in the method of this invention.

[Fig. 8]

It is a figure which shows the basic packet format of the broadcast retransmission phase used in the method of this invention.

[Fig. 9]

It is a figure which shows the basic packet format of the delivery confirmation phase used in the method of this invention.

[Fig. 10]

It is a figure which shows the header format used in the method of this invention.

[Fig. 11]

It is a figure which shows the concept of Length length used in the method of this invention.

[Fig. 12]

It is a figure which shows the broadcast distribution start announcement packet format used in the method of this invention.

[Fig. 13]

It is a figure which shows the registration packet used in the method of this invention.

[Fig. 14]

It is a figure which shows the file data packet format used in the method of this invention.

[Fig. 15]

It is a figure which shows the format of the broadcast end delivery packet and the broadcast retransmission end packet used in the method of the present invention.

[Fig. 16]

It is a figure which shows the broadcast retransmission start packet and the broadcast retransmission end packet format used in the method of this invention.

[Fig. 17]

It is a figure which shows the retransmission request packet and the retransmission request end packet used in the method of this invention.

[Fig. 18]

It is a figure which shows the delivery confirmation start packet format used in the method of this invention.

[Fig. 19]

It is a figure which shows the delivery confirmation response packet format used in the method of this invention.

[Fig. 20]

It is a figure which shows the delivery confirmation end packet used in the method of this invention.

[Fig. 21]

It is a figure which shows the data delivery packet format (a) and the retransmission request (end) packet format (b) used in the method of this invention.

[Fig. 22]

It is a transmission side flowchart of the announcement / registration / broadcast delivery phase in the method of this invention.

[Fig. 23]

It is a receiving side flowchart of the announcement / registration / broadcast delivery phase in the method of this invention.

[Fig. 24]

It is a transmission side flowchart of the retransmission phase in the method of this invention.

[Fig. 25]

It is a flowchart of the receiving side of the retransmission phase in the method of this invention.

[Fig. 26]

It is a transmission side flowchart of the delivery confirmation phase in the method of this invention.

[Fig. 27]

It is a receiving side flowchart of the delivery confirmation phase in the method of this invention.

[Fig. 28]

It is a figure which shows the data delivery packet format (a) and the retransmission request format (b) in the conventional method.

[Fig. 29]

It is a figure which compares the relationship between the transmission file size by the method of this invention and the conventional method, and the sum of the retransmission request packet size generated by one receiving station with respect to the line error rate.

[Fig. 30]

It is a system diagram which shows an example of the bidirectional communication service system using the communication satellite to which the method of this invention is applied.

[Explanation of symbols]

10 hub stations 11 Host server 12 Leased line 20 communication satellites 31 Time Division Multiplexing (TDM) Communication Path 33,34 Time Division Multiple Access (TDMA) Channel 41-1,41-2,41-3 Home unit 42-1,42-2,42-3,42-4,42-5 Client device 43-1,43-2 LAN