Network multicasting method using arq techniques for preventing unnecessary retransmissions

<u style="single">Cross-reference to related applications</u>This application is related to US Patent Application No. 08 / 375,493 (Agent No. PSM-001), filed January 19, 1995 and pending as of the filing date of this application. The application is also related to two other US patent applications. Both of these other applications will be filed with the US Patent and Trademark Office on the same day as this application. These other applications are identified by agent numbers STR-001CP1 and STR-001CP2. Both of these two other applications and US Patent Application No. 08 / 375,493 are incorporated herein by reference.<u style="single">Field of invention</u>The present invention relates to data transmission. Specifically, the present invention relates to fast and reliable file transmission from a server to a client.<u style="single">Background of the invention</u>Computer networks such as wide area networks (WANs) provide unicast, multicast and broadcast services to allow communication between server nodes and network subscribers such as one or more client nodes. There is. Multicast Frame Relay is a service used to communicate over computer networks. Multicast IP technology is also a service used to communicate over computer networks. Broadcast Frame Relay is a service used to communicate over satellite networks. Here, the term "broadcast" refers to a server node that sends information to all client nodes connected to the network. The term "multicast" refers to a server node that sends information to a subset of all client nodes connected to the network. Broadcast and multicast are relatively new network features using the WAN. Some information providers electronically broadcast or multicast information from a server node in a central location to one or more client nodes in a remote customer location over the computer network to which the server and client are joined. There is something that wants to convey information. Broadcast and multicast networks do not provide any response confirmation for the information transmitted, so these servers may be unreliable. Such unreliability is generally undesirable and unacceptable to information providers. A set of protocols commonly used in computer networks is TCP / IP. This is the protocol used on the Internet. TCP represents a transmission control protocol, and IP represents an Internet protocol. Two file transfer protocols are available for TCP / IP To. That is, (i) the file transfer protocol (FTP) that runs the top-level application of TCP, and (ii) the simple file transfer protocol (TFTP) that runs at the top-level of UDP. UDP stands for User Datagram Protocol. Both TCP and UDP are transport protocols responsible for the end-to-end transmission of information over an internetwork (ie, the network of networks). Both FTP and TFPT support only point-to-point (ie, unicast) file transfers. FTP relies on TCP for reliable transmission. This is because TCP is a connection-oriented response-acknowledged transport protocol. TFTP provides its own response confirmation for reliability. This is because TFTP runs at the top of UDP, a connection restaurant sporting service that does not support response verification. Connection-oriented protocols like TCP require the setup and teardown of virtual circuit connections. Due to its relatively long overhead, TCP and similar protocols are undesirable in networks with inherently poor connectivity, such as cellular digital packet data (CDPD) networks. CDPD uses TCP / IP as the primary protocol suite used in the network. It is recommended that the CDPD wireless network only operate with applications above UDP (Conclusion Restaurant Sport Layer). Therefore, the file transfer protocol selected for CDPD is TFTP. TFTP breaks the file into multiple packets with 512 bytes for each data, and then sends each data packet one at a time. After each data packet is sent, TFTP will send the sending node from at least one receiving node before allowing the sending node to send the next data packet. Make the response confirmation wait. TFTP is, for example, Douglas E. Comer (<u style="single">Internetworking with TCP / IP, Volume I, Principles, Protocols and Architecture, 2nd Edition</u>, Prentice Hall, 1991, Chapter 23, pp. 377-390). Although response verification is part of TFTP, the response confirmation schemes used in TFTP are very efficient as network delays become more pronounced and / or differ between two or more in the receiving node. Becomes worse. Some currently known data transfer mechanisms, like TFTP, require packet-by-packet response confirmation. Therefore, such other mechanisms are also relatively slow for the transfer of the entire data.<u style="single">Abstract of the invention</u>An object of the present invention is to transmit a file from a server to one or more clients on a communication link at high speed and with high reliability. The file transfer is preferably a multicast transmission to multiple clients. Generally speaking, file transfers according to the invention are speedy, reliable and even during link delays, even if the delays are noticeable and / or the delays differ between two or more in the receiving client. No loss of efficiency. The present invention provides an ideal mechanism for electronically distributing computer software files. Communication links that combine servers into multiple clients and allow communication between them can be computer networks (eg, LAN, WAN, Internet, etc.) or wireless networks (eg, packet cellular data networks such as CDPD). ), A combination of these types of communication media, or other communication media, such as a network that is generally fast and has low latency, such as a satellite network. According to the present invention, the client sends only a negative response confirmation back to the server while the server is sending the data file. This communication is continuous. That is, instead of the server stopping the transmission of data and waiting for a negative response confirmation from the client, the server receives the negative response confirmation of the client while the server is transmitting data. The client's negative response confirmation tells the server in particular which packets need to be retransmitted. A packet needs to be retransmitted, for example, because it was not received by one or more clients, or it was received incorrectly. After the server sends the entire data (eg, the entire file) over the link to the client, the server makes the second round of transmission. In this second round, the server resends only certain packets that the client has instructed to request. During this second round, the client Sends only negative response confirmations (ie, instructions for packets that were not received at all or were not received correctly). The process can then continue to retransmit many more rounds if necessary for each client to receive all packets correctly. Alternatively, the retransmission round may be repeated a predetermined number of times. This number is modifiable (that is, this number is configurable). Each subsequent round typically involves sending fewer packets than the previous round. This is because only the packet containing the error immediately before is sent again. This scheme transfers data from a server to one or more clients quickly and reliably. This scheme is quick because it allows the server to stop at the boundary between packets and forward the entire file without waiting for a negative response confirmation from the client for the packet just sent. That is, data transfer is the time it takes for each data transfer round to reach a client from a server, regardless of the reception problem of a particular client and / or any link delay problem (eg, a packet from the server to a client). It is not directly linked to negative response confirmation in that it continues regardless of (the difference between the time it takes for a packet to reach another client from that server). Also, each subsequent transmission round involves only the transmission of packets that were not received or were received incorrectly during the previous round, so, in general terms, the server will send the entire same file. You will never need to send more than once. This scheme is reliable because it tries to serve every packet to each client, and generally speaking, the reception problem of a particular individual client is the reception speed and accuracy of the other client. This is because it does not adversely affect the client. Data transfer according to the present invention is accepted by any client. We do not request or expect constant response confirmation. If the negative response confirmation returns to the server and is not received, the acknowledgment confirmation is implicitly shown. Further, according to the present invention, preferably, a plurality of negative response confirmations are collected and sent back to the server as "multiple selective reject negative response confirmations". Typically, at least one such multiple selective reject negative response confirmation is sent back to the server, for example, during the first round of transmission from the server to the client. One multiple selective reject negative response confirmation can represent hundreds of individual negative response confirmations. By using these sets of negative response confirmations, traffic on the link can be significantly reduced and bandwidth on the link can be freed for data transfer from the server to the client or for other purposes. In the present invention, generally speaking, the server and the link are not blocked by a large number of individual negative response confirmations that come back at the same time or in a very short period of time. As described above, as a result of reducing the number of individual response confirmations being sent to the server on the link, the effect of improving scalability can be obtained, and a significant advantage can be obtained. That is, using multiple selective reject negative response confirmation, the number of clients that can send a single file can be increased because the response confirmation traffic returning to the server is reduced. In a preferred embodiment of the invention, the entire data to be transferred (eg, a file) is divided into blocks. Here, each block has a plurality of packets. The server completes one round when it finishes sending all blocks (for example, an entire file). After one complete block has been sent, the client sends a negative response confirmation back to the server via the return unicast communication path. Block boundaries trigger the client to send a negative response confirmation. No about block N When the constant response confirmation returns from the client to the server, the server is sending block N + 1 (ie, subsequent blocks) to the client, or the server has already finished sending all blocks. ing. According to the present invention, the following features are provided. First, the ability to set the transmission rate and define the multicast group is obtained. In addition, the capacity of a link whose capacity is unknown can be determined by using the feature of "multicast network probe", and the frame error rate of the link whose capacity is known can be determined by using the same feature. .. The feature "multicast pin" can be used to determine the connectivity between the source and the members of the multicast group. A "seed group" can be set up after determining the capacity of the link. Alternatively, if its capacity is known, the first pass ensures that the recipient connected to the source by the fastest link receives all the data, and the recipient of the slower link receives that data. It can also be set up to receive only part of. The number of recipients who can receive data from the source can be significantly increased (eg, by a factor of 1000 or more) by using the "Negative Response Confirmation Collection" scheme. This will result in "replication" A point) (preferably a router) can collect individual negative response confirmations and send them to the next level as a unit. In addition, the terms "packet", "datagram" and "frame" are used in the present specification to identify the same thing, and are terms that can be replaced with each other. That is, these terms are terms that refer to a unit of data or information that can have a source address and a destination address as part of it and is transmitted over a link. The above objectives, aspects, features and advantages of the present invention, as well as other objectives, aspects, features and advantages, will become apparent from the following description and claims.

Brief Description of Drawings In drawings, the same reference number refers broadly to the same part throughout all drawings. In addition, these drawings do not necessarily correspond to the actual scale, and some of them are emphasized in order to explain the principle of the present invention. FIG. 1 is a flowchart of a data transmission operation according to the present invention. FIG. 2 is a diagram of the physical configuration that allows the server to communicate with one or more clients. FIG. 3 is a diagram showing the location of one embodiment of the present invention with respect to the TCP / IP protocol stack. FIG. 4 is a diagram of a "first pass" block and frame transmission and response confirmation process according to the present invention. FIG. 5 is a simplified block diagram of a server in which at least a portion of the present invention can be implemented. Figure 6 is a diagram of a hybrid multicast network in which members of a multicast group are connected by links of different capacities. FIG. 7 illustrates a feature of response confirmation collection according to the invention that improves scalability and allows millions of recipients to receive data from senders quickly and reliably. FIG. 8 is a diagram related to congestion / flow control using the variable block size method. FIG. 9 is a diagram related to congestion / flow control using a preferred status request method of requesting a negative response confirmation from a client before the block boundary.<u style="single">Explanation</u>Referring to FIGS. 1 and 2, according to the present invention, the source or server 20 to one or more receivers or receivers or clients 22 on the communication link 24.₁、22₂、...、22_NFast and reliable data transmission to multiple frames of data (eg, a file), the entire file (ie, all of those multiple frames) is transmitted over link 24. Includes sending to one or more recipients 22 on link 24 (step 10). While these frames are being transmitted, frame negative response confirmations from one or more recipients 22 are received over link 24 (step 10). If the negative response confirmation indicates that some frames need to be retransmitted on link 24 after the entire file has been transmitted on link 24 (step 12), then only these few frames Is retransmitted (step 14). While some of these frames are being retransmitted on link 24, frame negative response confirmations from one or more recipients 22 are received over link 24 (step 14). This process is then repeated as many times as necessary until there are no more requests for frame retransmission as indicated by steps 12, 14 and 16. In step 16, server 20 determines if a "done" message by all recipients 22 has been received by server 20. If the recipient "dans", then the recipient has already received all the frames and has already sent a "dan" message to the server 20 to indicate that. Recipients who are "Dan" continue to send "Dan" messages to the server until they see their name on the "Danlist". This "Danlist" is a server as a notification instructing all "Dan" recipients (that is, recipients on the "Danlist") to stop sending "Dan" messages to the server. Is what you send. After a predetermined amount of time, or after a predetermined event, the server 20 sends a status request to all non-responding recipients 22 (ie, recipients for whom the server has not received a "Dan" message) (step). 18). First of the whole file A single transmission of a period transfer and a subsequent error frame will be broadly referred to herein as a "round" or "pass". In the first path, server 20 preferably multicasts the file to one subset of all clients 22. Typically, at least two of these clients 22 have different server-client frame transmission delays associated with each. The data transmission according to the present invention is not affected by such a difference in delay, even if the difference in delay is remarkable, and even if all clients 22 have different delays. The link 24 can be a computer network (eg, LAN, WAN, Internet, etc.), a wireless network (eg, cellular data network), a combination of these two types of communication media, or typically a fast delay. Other communication media, such as satellite networks, may be used. Multiple frames transmitted on link 24 during the first round, together, can represent a single computer data file being transferred from server 20 to one or more clients 22. The server 20 and client 22 can be computers such as PCs or workstations that run any one of a wide variety of operating systems, including DOS. Referring to FIG. 5, the server 20, regardless of what type of computer it is, typically has a central processor 50, a main memory unit 52 for storing programs and / or data, and an input / output controller. 54, network interface 56, one or more input devices 58 such as keyboards and mice, display devices 60, fixed drive units, namely hard disk drive units 62, floppy disk drive units 64, tape drive units 66, Use these devices to allow communication between them It has a data bus 68 to be combined. Each of the client computers 22 generally includes all or part of the equipment included in the server 20 of FIG. In one embodiment, one or more computer programs define the computing power of server 20 and client 22. These programs can be loaded on server 20 and client 22 via hard drive 62, floppy drive 64 and / or tape drive 66. Alternatively, these programs may reside in a permanent storage portion (for example, a ROM chip) of the main memory 52. In other embodiments, the server 20 and / or the client 22 is specially designed, dedicated, and wired to perform all the functions described herein without the need to receive instructions from a computer program. It may be provided with an electronic circuit. The present invention can be used, for example, to load new revision levels of client software electronically, quickly and reliably from a server to one or more clients. With reference to FIG. 3, the present invention preferably operates at application layer 30 above UDP for TCP / IP protocol stack 32. The present invention can also operate in an application layer above the Connection Restaurant Sport layer that resides in other protocol stacks such as IPX in the NetWare SPX / IPX protocol suite. UDP stands for User Datagram Protocol, and it is the TCP / IP standard protocol that allows an application program on one computer to send datagrams to an application program on another computer. is there. UDP uses the Internet Protocol (IP) to carry datagrams. UDP datagrams differ from IP datagrams in that the sender of the diagram has a number of destinations (ie, a) on the receiving computer. The UDP datagram contains a protocol port number that allows it to be identified from the application program). UDP datagrams also typically contain checksums for the data being sent. Broadly speaking, data transmission according to the present invention includes four aspects: "idle", "announcement / registration", "transfer" and "completion". No activity is performed in the "idle" state. When a collection of data (eg, a file) is selected for transmission by server 20, it enters the "announcement / registration" phase. All files are available to the operator on server 20 during any of these four phases.<u style="single">Announcement / Registration</u>In this phase (step 8 in Figure 1), the server "announces" to the client that a file is about to be transferred and provides the parameters associated with the transfer of that file. The maximum duration of this phase is expressed in minutes and is configurable. The "announcement" message is used to set up the multicast group, and class D addresses are used to assign the multicast group. The client is forced to register with the server that it has received an "announcement" message. When the client sees this "announcement" message, it confirms that it is associated with the group identified in the message. The fact that the receiver has the correct server IP address and the correct port number is implicitly indicated to the receiver that can handle the "announcement" message. The client automatically responds to the "announcement" packet with the "registration" packet until it sees its address in the registered client list in the subsequent "announcement" packet. The "registration" packet acts as an acknowledgment to the server regarding the client's subscription. Once the server receives the client's "registration" packet, the server adds the client to the client list in the next broadcast of the "announcement" packet. The client list is maintained by the server. Registration of the client is complete when the client receives an "announcement" packet that contains the client's ID in the client list. When all the expected receivers respond to the "announce" message, or when the "announce" timeout expires, whichever of these happens first, the actual transfer of the file begins at that point. That the client has the resources to work with the file that is about to be sent, so this client can join that group. Registration is shown. Cryptographic key exchange can be performed during group setup to prevent unwanted subscriptions. Once the file transfer begins, the "announcement" packet is no longer sent and the "announcement" phase ends (step 9 in Figure 1). All characteristics of file transmission are transmitted in "announcement" packets. Upon receiving this "announcement" message, the client responds to the server with a unicast datagram. This response indicates whether the receiver has equipment to receive the file. The response also indicates whether, in the case of transmit abort, the client has sufficient context to continue transmission (resume as shown in Figure 1). The duration of the announcement period in some cases is long enough to allow the server site operator to initiate a call to the client site and indicate that the computer is not available or has no forwarding equipment. Should be. At the client site, corrections may be made manually or, when configured so, under remote control from a server that releases resources so that the client can participate in the transfer. At any point during the entire transmission period, the client can respond to this packet to indicate that it has aborted transmissions from its end and indicate the reason in the message. If the transfer was interrupted before it was completed, the present invention allows the file to continue later (resume in Figure 1) without having to re-send the already successfully transmitted portion of the file. This is a particularly important and useful feature when sending very large files. To achieve this feature, the client does not partially discard the received file. Instead, the client stores the partially received file. If the file is first sent, all clients (eg all clients in one multicast group) If there is a problem that prevents the entire file from being received (for example, if the link is broken for some reason while sending the file), the transmission will be resumed later and the transfer can be completed. Upon resumption, the server queries all clients for a list of unreceived data frames, and then the server begins to complete the transfer by sending only those frames. So, in Figure 1, upon resuming, step 10 was first aborted, rather than starting at the first frame of the first block of the file, as it would at a normal start if the transfer was not aborted. It involves a transmission that starts first from a frame that was not received (that is, a negative response was confirmed) during the transmission.<u style="single">transfer</u>When entering the data transfer phase, the transmission log is maintained on the server. This log is always on so you don't lose track of all the events. Each client also maintains outbound logs. The logs maintained by each client will be referred to later in the "Done" section. When a file with more than 2 gigabytes of data can be transferred, it is generally impractical to keep the entire file in server memory for the entire duration of the transfer. The number of clients that will receive the file can be 1000 or more, so suspend the transmission and wait for a response confirmation from each of those clients before moving on to the next block transfer. Is unacceptable. The server logically decomposes each transferred file into blocks of frames. Each block typically has multiple frames and can have thousands of frames. Referring to FIG. 4, in one example, server 20 decomposes a file into four blocks: block 1, block 2, block 3, and block 4. Here, each block has one or more frames. Each block represents a unit in which a negative response is confirmed (but not an acknowledgment) by any client participating in the transfer when the client determines that one block has been sent by the server. The client detects this by changing the block number in the received data packet. This is because each frame sent indicates its block number and the frame number within that block. Breaking a file into multiple blocks gives you at least two benefits. That is, (i) the number of negative response confirmations required can be reduced, and (ii) the request to memory on the server for determining the transfer block of the next file path can be reduced. Data transfer is not directly linked to negative response confirmation .. The transfer continues no matter what individual client fails to receive the negative response confirmation, or which client previously misses the data packet. This simplifies the design and ensures that individual client issues have minimal impact on the entire group. It should also be noted that the client is responsible for sending a block negative response confirmation based on the content received from the server. With reference to Figure 4, the server first blocks the first frame of the first block (that is, the block).₁The transfer is started by sending the first frame of). The server sends these frames at a configurable rate. This means that the basic transfer rate can be slowed down (that is, lowered) depending on the performance. The server once the complete file is sent to the network (that is, blocked)₁~ Block₄Continues to send frames of the file until (is sent). This is defined as the first pass or the first round, and in Figure 4, "B₄It takes as much time as it is expressed as. Some clients have successfully received the complete file (that is, all four blocks) after the first pass. In such a case, those clients have finished receiving the file. A client that has received a frame containing one or more errors, or has not received one or more frames at all, has some "parts" of the file (that is, frames received incorrectly, or missed). Requests that the begging frame) be sent again in a subsequent pass or round. Each subsequent pass or round requires the transmission of fewer frames than last time. This is because the frames that were negatively confirmed in the previous round (that is, the frames that were not received or were received incorrectly) are retransmitted in subsequent rounds. The maximum pass count or maximum time to complete can be a configurable parameter. There may be multiple clients that did not receive the entire file correctly by the maximum pass time, or maximum duration. These clients are identified by the server. The server can also take further action, for example, via a unicast file transfer process, to allow these clients to obtain the remaining information. In a preferred embodiment, the client indicates that it has received the entire file by sending a "Dan" message, while the server says that it is "Dan" by sending a "Danlist". Is shown. If, after a given event (eg, a given amount of time has passed), the server has not received "dan messages" from some clients and all NAKs are being serviced, then the server has theirs. Send a status request message to the client and all missing frames to the client in need of more data. Which still does not respond A file can then be sent from the server to such a client, for example by unicast transfer. The server is a block boundary (ie B in Figure 4)₁, B₂, B₃And B₄), Each client preferably sends a "multiple selective reject denial" response confirmation ("Nak") for each block. These response confirmations sent from the client for each block are received by the server shortly after passing the boundary of the block. Acknowledgment is implicitly shown. Multiple Selective Reject NAK confirmation for a particular block means that one or more frames in that particular block were either incorrectly received by these clients or not received at all. It indicates that the network did not propagate those frames for some reason. Therefore, the response confirmation sent to the server indicates which frame was received incorrectly or was not received at all. On subsequent paths (ie, paths following the first path shown in Figure 4), the client responds only with a negative response confirmation for the block that was not received correctly again. The server sends the portion of the file (frame) requested by the various clients on subsequent paths to all clients, so it is possible that many of the clients have already received it correctly on the first path. .. Therefore, those clients will ignore it. In general, all information returned from the client to the server can be sent on a return path separate from the (one or more) paths that the server uses to forward those frames to the client. However, here, for the sake of explanation, the communication link 24 (Figure 2), or any other path that allows the server to communicate with the client, broadens both the server-to-client link and the client-to-client return link. Please interpret what it means. The server maintains a variety of information about the transfer and its subscribers. In a preferred embodiment, this information is maintained by the server in the form of data structures or lists. The server maintains this information And by using it, record and determine the status of the file transfer. The server also maintains a frame data structure that shows all of the selective rejects for individual frames from all clients. If many clients fail to receive the same frame, the frame data structure only indicates that the frame was not received. That is, the frame data structure is not maintained by the server on a client-by-client basis. In general, it is not desirable for the server to maintain a detailed list of unreceived frames on a per-client basis. This is because such a scheme would use an exorbitant amount of memory, especially when a large number of clients (eg, 1000 or more) are participating in the multicast. For example, one or more clients block₁Frames 24 and 25, blocks₂Frame 1, block₉It is assumed that some frames of ... were not received at all or were received by mistake. If the frame status maintained by the server indicates that a particular frame in a particular block needs to be retransmitted, then at least one of the clients has successfully completed that particular block. It is a fact that we have not confirmed the response. Once the server has sent the entire file, the server passes this frame status information and only retransmits the frames listed there. This operation continues on a pass-by-pass basis until all clients have sent a "dumb message" and the frame status list is empty (ie, the maximum number of rounds or the maximum time is reached). Note that for any given path, if no negative response confirmation is returned to the server, the client will send back the same reject and resend request messages during the next pass by the server. Caution must be taken. This means that if a particular client has not been received by the server, that client will have to join for a longer period of time, but that client will have a significant impact on the rest of the receiving clients. Means that there is no. Another part of the information stored on the server is statistics about multicast groups. When the transmission is complete, the transmission data is populated with summary information that helps the operator determine system performance issues and / or performance issues for a particular client. Numerous paths through files: Once the file has been completely processed once (ie, at the end of the first pass or first round), the transmission process according to the invention increments the pass counter and the server for the first block in error. Scan the frame status list at. As soon as it finds this first error block, the server resends the unreceived packets in that block. Negative response confirmation for these unreceived packets is generated by the client when it detects an error in the block, as described above. This is also consistent with the first pass. Selective reject negative response confirmations are all state indications and are not unique to a path. However, those negative response confirmations may change in each path. In a preferred embodiment, in multiple selective reject negative response confirmation, the entire word represents a block, and each bit in the word is a different one of the multiple frames that make up the block. It takes the form of a bitmap that represents. Send Abort: If an uncorrectable flaw is encountered during a send or the operator manually aborts, the send abort sequence is initiated. This sequence inevitably involves repeatedly sending abort messages over a period of time (eg, at intervals specified in the send file). The receiver may respond to this abort message and take action, for example, to save the context for a potential continuation (ie, resume) of the transfer, or to reinitialize the context in preparation for another transmission. it can. There is equipment that allows the user to initialize the transmit abort. The reason code can be set either for suspension or for initialization. In the former case, transmission can be continued or resumed at some time thereafter. On the other hand, in the latter case, the client is requested to reinitialize the context. If, during transmission, an uncorrectable defect is encountered or the operator manually aborts, the transmit abort sequence is initiated. This sequence inevitably involves repeatedly sending abort messages over a period of time (eg, at intervals specified in the send file). The receiver may respond to this abort message and take action, for example, to save the context for a potential continuation (ie, resume) of the transfer, or to reinitialize the context in preparation for another transmission. it can. There is equipment that allows the user to initialize the transmit abort. The reason code can be set either for suspension or for initialization. In the former case, transmission can be continued or resumed at some time thereafter. On the other hand, in the latter case, the client is requested to reinitialize the context.<u style="single">Done</u>The server detects the completion of an individual client by receiving a "dumb message" from the client. The client knows it's finished as soon as it gets all the blocks in the file, but it has to keep sending "dumb messages" until the server confirms it's done. The server confirms that a client is "Dan" by putting the client's address in a "Dan list" and sending the list to multiple clients. The client sees his address listed in the "danlist" and knows that the transfer is complete. The client then updates its transmission log to indicate that the transfer has been successfully completed. It also provides the ability to abort transfers from servers or clients. Abort packets give servers and clients the ability to abort forwarding faster. If the client sends an abort, the server removes the client from the group. If the server aborts, the transfer can be resumed without having to send the entire file in the first pass. Status request: If, after the first pass, the server did not receive a DONE or NAK from the client, the query is sent directly to the client whose status is unknown. These responses take the form of standard response messages. Also, these responses may include bitmaps that describe those errors, if any. Congestion / Flow Control As the large "Internet" becomes multicast-capable, multicast groups will become even more common, where information wants to have different outbound links to the members of the group. Each of these different links can have a different capacity. These capacities may be widely dispersed from each other. For example, one member in a group may have a link capacity of more than 1 Mbps, while another member may have only 56 Kbps. In general, knowledge of these link capacities will not be known to the sender of the transmitted wave (eg, the server). Therefore, it is desirable to be able to prevent network overload / congestion and not control the efficiency of the data transfer protocol by instantly determining the link capacity and providing a flow control mechanism. The data transfer protocol described here includes the concept of blocks. Each of these blocks can contain hundreds or thousands of frames. The client (receiver) is forced to send a multiple selective reject NAK at the boundary of the block if any frame is missing or incorrect in the block. For flow control purposes, be able to make flow control decisions as soon as possible, as soon as it is practical, to gain knowledge about unreceived / error-containing (ie, missing) frames. Is desirable. To achieve this using the data transfer protocol according to the invention, it is necessary to use a mutable or variable block size. This is one method. This inevitably entails maintaining current scalability by starting with relatively small blocks and increasing the size of the blocks during the file transfer to reduce client response confirmation. Another preferred way to achieve this using the data transfer protocol according to the invention is to make all blocks the same size (uniform block size), but the client responds with a NAK before the block boundary. There is a way to delay the status request to the server before the block boundary occurs so that it can be done. This latter technique is more flexible. This is because NAKs can be charged at any time, not just block boundaries (the former technology corresponds to this case). With both of these two technologies, NAKs are billed early in the transfer. In the "variable block size" method (first technique mentioned in the previous paragraph), the first block may be relatively small (eg, 100 frames). Subsequent blocks are doubled each time. The block size is doubled one after another until the maximum block size is reached or the file reaches its end. In the "status request" method (the second technique mentioned in the previous paragraph), the server requests a NAK request at any time it desires. Those points in time are not block boundaries. In a preferred embodiment for congestion or flow control, status requests are sent at longer intervals each time. For both methods, the transmission rate or transfer rate is set as described herein. However, the settable transfer rate, which is not a fixed transfer rate, represents the upper limit of the transfer rate. After the first block (for the variable block size method) or after a status request is received (for the status request method), a NAK is sent to the server by the client with the dropped frames. Also, this is for these clients It also indicates congestion to the server. If there are NAKs, the fact that they are related to the instantaneous capacity of a particular link can be used to determine the link capacity for all congested links based on the following equation. ((Number of frames sent-Number of frames confirmed with negative response)) × Transfer rate = Link capacity In the heterogeneous multicast network shown in Fig. 6, the link speed ranges from 64Kbps to 1024Kbps, and there is a large difference in link capacity. is there. Assuming no other traffic, if the transfer rate is set to 150 Kbps, the block NAK for block 1 from client A will be about 58 frames for the first block (in the variable block size method). Will indicate that is missing. Using the above equation, the instantaneous link speed is calculated to be 63 Kbps. A block NAK for block 1 from client B would indicate that about 15 frames are missing for the first block (in the variable block size method). Using this equation again, the instantaneous link velocity of the link to B is 127. Calculated as 5Kbps. In the presence of other traffic, the number of frames dropped will be higher, resulting in a lower calculated link speed. Group threshold parameters can be set by the user. The group threshold is the limit (represented by the percentage of missing frames) by a particular client that is allowed to continue to join the multicast group. If the group threshold is set to 25%, any client in the group with a frame dropout percentage higher than 25% must take action to ensure that the rest of the group is not adversely affected. Means. In the example in Figure 6, client A, with 58% of the frames missing, would need to take action. The client will have enough information to make the decision. This is because the transfer rate and group threshold parameters are sent to the client in the form of an announcement message. A client that detects that its frame drop rate exceeds the threshold takes one of the following actions: 1. Request from the server to leave the group and join the slower group. Here, the group is speeded based on the measurements made at the client. 2. Leave the group without requesting further communication. This means that this client will miss this transmission. 3. Suppress NAK until a status request message is received from the server. This allows the rest of the group to exit from clients with high frame loss without stagnation due to excessive retransmissions (the transfer rate for retransmissions for this set of clients is small in their capacity). Can be lowered to reflect that). In the example in Figure 6, the second highest frame drop percentage is 15% for Client B. This value is lower than the group threshold. This number represents a factor that the entire group can match without unduely degrading performance. To match Client B, the server transfer rate for this group would drop by a percentage of 15%, or higher, or slightly higher. The timing of the variable block size method is shown in FIG. As soon as the information on the client indicates that the frame drop has exceeded the group threshold, the client has one of the three selectable actions listed above so that the group's transmission is not adversely affected. You have to choose one. The adjustment of the transfer rate of the group is performed after the second block is sent and starts from the beginning of block 3. The transfer rate change is carried out at the boundary of blocks, and accurate data is supplied from the block NAK on a block-by-block basis. The file transfer then proceeds to block 3 transfer. Block 3 is set to be twice as large as block 2, just as block 2 is twice as large as block 1. This is followed by block 4. Block 4 is twice as large as block 3. The same is true until the maximum block size is reached or the file reaches its end (whichever happens first). However, if the NAK from the group after block 3 indicates that even the worst client exceeds the rate threshold parameter (configurable), then the rate is , Further tuned for block 5 transmission. This rate threshold is the minimum frame dropout percentage at which transfer rate adjustments are made to the group. For example, if the maximum frame dropout percentage from the client is 1%, then adjustments that typically set the rate threshold above 1% are not guaranteed. In the status request method, the blocks are of uniform size, and the status request is sent by the server to request a NAK before reaching the block boundaries. With reference to FIG. 9, a scenario equivalent to the scenario just described for the variable size block method is illustrated. However, here (Fig. 9), the block size is uniform. In one example, the first status request is sent after forwarding 100 frames and the second status request is sent after 200 frames have been sent. The same applies to the following. The client NAK is sent back to the server at exactly the same time as the variable block size method. However, the status request method is more flexible in that it does not have to wait for the block boundary to receive the NAK as it does in the variable block size method, and the status request is sent at the desired time at any time. Neither the variable block size method nor the status request method, it is generally desirable to simply remove members of a group and leave them hanging. Deleted group members can be grouped into another group that operates at a lower transfer rate. This slower transfer rate can be determined by the calculation of link capacity performed by the client leaving the group. The group can then be set up at the appropriate transfer rate. Then a new transfer can be initiated. Both the variable block size method and the status request method of the flow control process can be automated. Multicast: Multicast can take two forms. That is, application layer (AL) multicast, where the network is still transmitting data throughout the broadcast group, and multicast, where the network is routing traffic based on the multicast router and the Internet specification RFC1112 is performed on the client. There are two IPs. In either case, the multicast group is set up under the start of the server. The server notifies the client of the membership of a specific multicast group by sending a notification to the client on a unicast basis. These multicast groups can be set up and disassembled quickly, allowing the multicast groups to be dynamically configured. For example, a multicast group can be set up just to send a particular file. This group can then be dismantled. With AL multicast, the network still propagates traffic on a broadcast-by-broadcast basis, but clients that do not belong to the group discard non-dedicated data. Once a group is set up, security keys can also be distributed to prevent clients outside the group from reading the data, even if the data is not destroyed on that node. (Note that this can also be expanded with multicast IP). Also, with AL multicast, the IP address remains a global or network-based broadcast address. As with broadcasts, this address maps to a broadcast address in the link layer protocol (eg, a broadcast SMDS address). The multicast header is selected for this group and becomes the group's identifier. For multicast IP, the network has a router with a class D multicast IP address and A router network that supports multicast routing. The client supports RFC1112, or "host extension for IP multicasting". RFC1112 allows the host to notify the nearest multicast router of its presence for the purpose of updating the router table. The functions of the present invention described above will be described below. See Figure 2 again. Figure 2 can broadly represent any broadcast or multicast IP router-based network. An object of the present invention is to send small or large data files (files up to 2 gigabytes in size or larger) to more than 5000 receiving nodes 22 by server 20 over a wide area network (WAN) connection 24. It is possible to transmit at the same time. The present invention can also operate on local area networks or other types of communication links, as described above. The transmission medium 24 may be of any type as long as it can support the TCP / IP protocol stack in the preferred embodiment. Other protocol stacks could also serve as a communication environment for the present invention. Multicast can be supported in two ways. That is, as described above, there are two types: AL multicast and multicast IP. The files transferred to the client can be loaded on server 20 via tape (eg, via tape drive 66 in Figure 5), and if those files are small enough, a floppy (eg, floppy in Figure 5). Can also be loaded by drive). The transferred file may also be loaded from the source of the file, for example on a LAN or other network, to the server 20 via FTP (File Transfer Protocol) or other unicast transfer mechanism. These files can generally be in any format. Then the data file comes from tape or floppy , Read into the file system of the sending server 20. Note that the server 20 must have enough space to read the uncompressed copy of the data file. For both services, the datafiles may be encrypted so that ineligible receivers cannot receive and use the datafiles. Each transmitted file is preferably uniquely identified. There are preferably instructions regarding the content and the time of occurrence. The input file to the process may be larger than 2 gigabytes in size. The system can also work with files that are much larger than 2 gigabytes. The file is then stored on server 20 and ready for transmission. Data from previous transmissions should be available on Server 20 for some time if they need to be retransmitted. A mechanism for accessing this data is provided so that the data can be queued and retransmitted at any time. For efficiency, the files are sent in blocks. The block size is derived from the largest packet that can be forwarded on the communication link 24 (or the block size may be chosen by the user). The derivation is based on the fact that the client needs to show the server which packets in a block missed it. One way to do this (and generally the easiest way) is to send a bitmap and position the bit settings to indicate which packets were not received. Therefore, the size of the block itself is almost equal to the number of packets that can be confirmed as a response in the form of a bitmap contained in one packet. For example, if the packet size is 256 bytes, the maximum number of bits a packet can contain is 256 (bytes / packet) x 8 (bits / bytes) = 2048 (bits). To / packet). This means that the maximum block size allowed is a block with 2048 packets. It is possible to interface the receiving node 22 to an Ethernet LAN at 10 Mbps, but WAN links are often much slower. Therefore, the explicit transmission data rate can be set / set. Receiving nodes may experience resource issues before or during transmission, respectively. The receiving node is enabled to query its resources prior to transmission to determine if it has the equipment to receive the data. If this is not the case, these nodes should indicate that the send-only space should be reinitialized or that they cannot participate in the send. That way, corrections can be undertaken through different channels. Equipment that enables file transfer may be provided by forcing the server to create available disk space by remote control. Receiver 22 must be aware of what it is currently listening to. When a datagram is received on a dedicated channel, node 22 must determine if it is addressing itself. Problems arise when this application is being used by more than one sending server 20. There must be a way to ensure that the receiving node 22 is participating in exactly one transmission at a given time. By dedicating the UDP port to the server 20 and associating the encryption key with that server, the receiving node using the random mode tap on the network 24 has the ability to interpret the transmitted data. You can definitely avoid it. Some reference information is maintained on the transmission server 20. Preferably, there is a list of all possible receiving nodes in the network. Ten to allow information providers to manage their clients in the event of service failures, problems, etc. It is preferable if sufficient reference information is available. It is also preferable to have a transmission database that is maintained so that encrypted and compressed data files can be transmitted at any time. This transmission database contains, along with the prepared data, descriptive information that identifies the contents of the file, eg, 70 bytes or less. Each transmission preferably has a completion status indicator record and a log of all errors encountered during the transmission. It is also preferable to have an event file containing all the nodes to which the transmission has failed and the reason for the failure. At any point during the transmission, the operator can also query the status of the transmission applied to the server 20 and each receiving node 22. If there is a communication problem with some clients, or any other problem, a warning will be issued. If any intervention is indicated, the operator is allowed to initiate a corrective action. For ongoing maintenance and management of the service, operators are allowed to maintain a list of receivers, send groups, send file descriptors, send parameters, and send databases. The background process maintains both the environment and age data, and if allowed by the alerted operator, the housekeeping parameters will remove it. The data transmission according to the present invention has been described above. Hereinafter, other aspects of the present invention will be described. Other aspects include "settable transmission rate", "multicast group", "multicast pin", "multicast network probe", "speed group" and "negative response confirmation collection". For example, it contains 70 bytes or less of descriptive information. Each transmission preferably has a completion status indicator record and a log of all errors encountered during the transmission. It is also preferable to have an event file containing all the nodes to which the transmission has failed and the reason for the failure. At any point during the transmission, the operator can also query the status of the transmission applied to the server 20 and each receiving node 22. If there is a communication problem with some clients, or any other problem, a warning will be issued. If any intervention is indicated, the operator is allowed to initiate a corrective action. For ongoing maintenance and management of the service, operators are allowed to maintain a list of receivers, send groups, send file descriptors, send parameters, and send databases. The background process maintains both the environment and age data, and if allowed by the alerted operator, the housekeeping parameters will remove it. The data transmission according to the present invention has been described above. Hereinafter, other aspects of the present invention will be described. Other aspects include "settable transmission rate", "multicast group", "multicast pin", "multicast network probe", "speed group" and "negative response confirmation collection". For example, it contains 70 bytes or less of descriptive information. Each transmission preferably has a completion status indicator record and a log of all errors encountered during the transmission. It is also preferable to have an event file containing all the nodes to which the transmission has failed and the reason for the failure. At any point during the transmission, the operator can also query the status of the transmission applied to the server 20 and each receiving node 22. If there is a communication problem with some clients, or any other problem, a warning will be issued. If any intervention is indicated, the operator is allowed to initiate a corrective action. For ongoing maintenance and management of the service, operators are allowed to maintain a list of receivers, send groups, send file descriptors, send parameters, and send databases. The background process maintains both the environment and age data, and if allowed by the alerted operator, the housekeeping parameters will remove it. The data transmission according to the present invention has been described above. Hereinafter, other aspects of the present invention will be described. Other aspects include "settable transmission rate", "multicast group", "multicast pin", "multicast network probe", "speed group" and "negative response confirmation collection". A warning will be issued if any other problems occur. If any intervention is indicated, the operator is allowed to initiate a corrective action. For ongoing maintenance and management of the service, operators are allowed to maintain a list of receivers, send groups, send file descriptors, send parameters, and send databases. The background process maintains both the environment and age data, and if allowed by the alerted operator, the housekeeping parameters will remove it. The data transmission according to the present invention has been described above. Hereinafter, other aspects of the present invention will be described. Other aspects include "settable transmission rate", "multicast group", "multicast pin", "multicast network probe", "speed group" and "negative response confirmation collection". A warning will be issued if any other problems occur. If any intervention is indicated, the operator is allowed to initiate a corrective action. For ongoing maintenance and management of the service, operators are allowed to maintain a list of receivers, send groups, send file descriptors, send parameters, and send databases. The background process maintains both the environment and age data, and if allowed by the alerted operator, the housekeeping parameters will remove it. The data transmission according to the present invention has been described above. Hereinafter, other aspects of the present invention will be described. Other aspects include "settable transmission rate", "multicast group", "multicast pin", "multicast network probe", "speed group" and "negative response confirmation collection".<u style="single">Settable transmission rate</u>As mentioned above, it is possible to set the data transmission rate. The previous example described when a settable rate would be useful. In that example, the receiving node 22 is interfaced with an Ethernet LAN with an available bandwidth of 10 Mbps and a WAN link that connects the LAN to other networks at speeds well below 10 Mbps. In such a case, according to the present invention, the data transmission rate will be set to match, for example, the speed of the slowest WAN link. According to the present invention, the data transmission rate can be preset no matter what file transfer session is given. More specifically, the maximum bit rate at which data is transmitted during the session is configurable. In a preferred embodiment, the maximum bit rate is set by setting a parameter to an integer value representing the bit rate in kilobits per second (Kbps). For example, if this rate parameter has a value of 56, then this parameter corresponds to the maximum bit rate of 56 Kbps. This rate parameter can be set to any value that corresponds to the available bandwidth of the link that connects the source to the destination, or to a value that represents a rate below the available bandwidth. That is, if the available bandwidth is 1 Mbps, the rate parameter may be set to any value between 0 and 1000. Here, 1000Kbps is equal to 1Mbps. The ability to explicitly set the transfer rate allows other applications on the network to co-exist with long file transfers (in time) without occupying the entire network bandwidth or virtually all bandwidth. To enable.<u style="single">Multicast group</u>In the above description, "multicast" is defined as the case where the server node 20 sends data (for example, a file) to one subset of all the client nodes 22 connected to the network 24. The above description also discloses that multicast transmission can take two forms. That is, there are two types: "application layer (AL) multicast" and "multicast IP". AL multicast is used when the network does not support the Internet specification RFC1112, but broadcasts. Multicast IP is preferred over AL multicast if multicast IP is supported by the network according to RFC1112 and multicast IP routing. Multicast IP is used when members of a group must support multicast, and routers in router networks must also support certain multicast routing protocols (eg, DVMRP, MOSPF, or PIM). Unlike AL multicast, multicast IP is a true multicast protocol in which only members of a multicast group receive transmitted data. For each file transfer, a multicast group can be defined during the "announcement / registration" phase of data transmission, as described above. As mentioned earlier, the server maintains a variety of information about file transfers and the subscribers or groups participating in those transfers. In a preferred embodiment, this information is maintained by the server in the form of data structures or lists. By maintaining and using this information, the server records and determines the status of file transfers during the "data transfer" phase. The client status structure contains a list of multicast group subscriber status based on data from announcement registrations received by the server. .. Multicast group management is the process of assigning clients to a multicast group. The task of creating and manipulating the client list for each group is the responsibility of the application program to initiate the file transfer in the first case. Application programs generally provide easy-to-use features such as associating names with client IP addresses and assigning names to groups. Group management is required only at the transmitting station (eg, server). Multicast groups are specified when the sending station wants to send a file. This group is identified by the client's IP address list. Here, one address corresponds to each client in the multicast group. There are two options for multicast groups. That is, dynamic and static. In the case of a dynamic multicast group, the group is disassembled when the transfer is completed. A dynamic multicast group is formed by an "announcement" message that uses the class D address of the multicast group. In a static multicast group, as opposed to a dynamic multicast group, all members of the group remain members of the group when the transfer is complete. Static multicast groups are formed by the server on a unicast basis and / or using regular class D addresses to set up the configuration. Provide features that can be used. Group management is required only at the transmitting station (eg, server). Multicast groups are specified when the sending station wants to send a file. This group is identified by the client's IP address list. Here, one address corresponds to each client in the multicast group. There are two options for multicast groups. That is, dynamic and static. In the case of a dynamic multicast group, the group is disassembled when the transfer is completed. A dynamic multicast group is formed by an "announcement" message that uses the class D address of the multicast group. In a static multicast group, as opposed to a dynamic multicast group, all members of the group remain members of the group when the transfer is complete. Static multicast groups are formed by the server on a unicast basis and / or using regular class D addresses to set up the configuration. Provide features that can be used. Group management is required only at the transmitting station (eg, server). Multicast groups are specified when the sending station wants to send a file. This group is identified by the client's IP address list. Here, one address corresponds to each client in the multicast group. There are two options for multicast groups. That is, dynamic and static. In the case of a dynamic multicast group, the group is disassembled when the transfer is completed. A dynamic multicast group is formed by an "announcement" message that uses the class D address of the multicast group. In a static multicast group, as opposed to a dynamic multicast group, all members of the group remain members of the group when the transfer is complete. Static multicast groups are formed by the server on a unicast basis and / or using regular class D addresses to set up the configuration. Remains a member of the group. Static multicast groups are formed by the server on a unicast basis and / or using regular class D addresses to set up the configuration. Remains a member of the group. Static multicast groups are formed by the server on a unicast basis and / or using regular class D addresses to set up the configuration.<u style="single">Multicast pin</u>The "pin" utility in TCP / IP is very useful in determining connectivity between two points in a TCP / IP network (ie, determining if two pointers are actually connected). is there. In TCP / IP, when a pin packet is sent to the desired endpoint, that endpoint inverts the address and sends it back to the sender. The lap time delay is also measured. This is a measurement of the time it takes for a pin packet to move from the sender to the desired endpoint and then return to the sender. It is also desirable to provide a multicast pin utility in which all members of a multicast group respond to pin packets or pin requests. A client or host that supports multicast IP (RFC1112) responds to pin requests with a class D IP address as the destination address. However, in the currently known multicast implementation, the sender of a pin request only displays the first response received for that pin request. That is, the currently known multicast pin technology does not measure network connectivity. According to the feature of "multicast pin" according to the present invention, network connectivity information is provided from the source to the recipients in the group by displaying all the multicast responses to the pin request, and for each receiver in the multicast group. Provides lap time delay information. In a preferred embodiment, this feature uses standard pin ICMP messages. Further, as one improvement item according to the present invention, the above-mentioned announcement / registration function can be used as another form of the feature of "multicast pin". By making this improvement, the announcement / registration pin message will determine the connectivity to the recipient's application layer within the group and the connectivity to the sender's return, and guru. Determine the lap time delay information for each recipient in the loop. Therefore, this "multicast pin" feature allows the sender to determine network connectivity and lap delay for members of a multicast group.<u style="single">Multicast network probe</u>Multicast (sending one thing to many, not everyone) data networks are about to move to that stage. In particular, multicast IP is new in router networks and can provide a mechanism for creating multicast groups on all types of networks (eg, Frame Relay, SMDS, LAN, satellite, wireless, etc.). The Internet also has a "Mbone" (multicast backbone), a part of the Internet that supports multicast IP. Mbone started in early 1992 and continued to grow, allowing more than 1500 subnets across the Internet to be multicast in early 1995. To date, Mbone has been used as an experimental network by Internet researchers who have tested PC and workstation-based video conferencing and whiteboard multicast applications, along with Internet "radio" and other experimental applications. I came. Multicast IP routing on the Mbone was initially performed on workstations using the multicast routing protocol DVMRP. However, some of the Mbones had already upgraded their routers, so they are now multicast-capable. In the next five to six years, the Internet is expected to be fully multicast-capable by using routers within the Internet. As the number of multicast-enabled parts of the Internet grows, Mbone will be used for mainstream multicast applications, not just as experimental research tools. Once this is achieved, the tool will be required to simplify its usage. One of the major differences between the Internet and private networks is that the Internet is a very heterogeneous network. There is one thing. The Internet is a network of networks, and there are significant differences between different parts of a network operated by different organizations. In contrast, many private networks are set up to be relatively homogeneous, with private network operators giving great control over the architecture of the network. Within a multicast group, many endpoints within a multicast network are likely to be linked at different rates using different networks, and congestion within the network will be different for different parts of the network. It is desirable to be able to gain knowledge about the capacity of the subscription link and test its performance at that capacity. The feature of the "multicast network probe" according to the present invention is that Mbone or other large heterogeneous multicast networks can be investigated (probed) from the traffic source and the capacity of individual links can be quickly measured from the traffic source. It is designed. Referring to FIG. 6, a heterogeneous multicast network (eg, the Mbone portion of the Internet) has a multicast group with five members A through E. Here, each member of the group is connected by links of different capacities (ie, links of different rates). Group member A is connected to the network by a 64Kbps (kilobit / sec) link, B by a 128Kbps link, C by a 256Kbps link, D by a 512Kbps link, and E by a 1024Kbps link. It is tied. The nature of these link connections is unknown to the server (ie, the traffic source). This is because the connection to the Internet can be made through links of many different speeds. How to Multicast Information to Destination It is desirable for the traffic source to know the characteristics of each link leading to the destination so that it can be optimally determined. If the application is video conferencing, the quality to A at 64Kbps is unacceptable, but the rest can be determined to be able to participate at 128Kbps. Similarly, if the application is file transfer, groups D and E can form groups operating at a transfer rate of 512 Kbps, while groups consisting of A, B and C do not exceed the capacity of the network. , Can operate at 64Kbps. According to the present invention, the mechanism for determining remote link capacitance by probing a network is the system and protocol described herein. Announcement / registration to a multicast group consisting of members A to E determines connectivity based on, for example, the "multicast pin" feature of the invention described in the previous section (which member is actually connected to the server). After being used as a means to determine if it is), a series of small test files are sequentially sent to individual members of the group at different speeds. For example, a 400-frame test file can be sent first at 64Kbps, then at 128Kbps, then at 256Kbps, then at 512Kbps, and finally at 1024Kbps. The client's negative response confirmation is received and stored by the server, as shown in Table 1 below, assuming there are no other traffic on the link. You can configure a group that operates at a transfer rate of 2Kbps, but a group of A, B and C can operate at 64Kbps without exceeding the capacity of the network. According to the present invention, the mechanism for determining remote link capacitance by probing a network is the system and protocol described herein. Announcement / registration to a multicast group consisting of members A to E determines connectivity based on, for example, the "multicast pin" feature of the invention described in the previous section (which member is actually connected to the server). After being used as a means to determine if it is), a series of small test files are sequentially sent to individual members of the group at different speeds. For example, a 400-frame test file can be sent first at 64Kbps, then at 128Kbps, then at 256Kbps, then at 512Kbps, and finally at 1024Kbps. The client's negative response confirmation is received and stored by the server, as shown in Table 1 below, assuming there are no other traffic on the link. You can configure a group that operates at a transfer rate of 2Kbps, but a group of A, B and C can operate at 64Kbps without exceeding the capacity of the network. According to the present invention, the mechanism for determining remote link capacitance by probing a network is the system and protocol described herein. Announcement / registration to a multicast group consisting of members A to E determines connectivity based on, for example, the "multicast pin" feature of the invention described in the previous section (which member is actually connected to the server). After being used as a means to determine if it is), a series of small test files are sequentially sent to individual members of the group at different speeds. For example, a 400-frame test file can be sent first at 64Kbps, then at 128Kbps, then at 256Kbps, then at 512Kbps, and finally at 1024Kbps. The client's negative response confirmation is received and stored by the server, as shown in Table 1 below, assuming there are no other traffic on the link. It can be sent at 64Kbps, then at 128Kbps, then at 256Kbps, then at 512Kbps, and finally at 1024Kbps. The client's negative response confirmation is received and stored by the server, as shown in Table 1 below, assuming there are no other traffic on the link. It can be sent at 64Kbps, then at 128Kbps, then at 256Kbps, then at 512Kbps, and finally at 1024Kbps. The client's negative response confirmation is received and stored by the server, as shown in Table 1 below, assuming there are no other traffic on the link.<img file="JP3690809B2_D0001.tif" />See Table 1, the first run at a speed of 64 Kbps results in zero negative response confirmations (ie NAKs or Naks) to any member of the group. That's because all links support over 64Kbps. The second run is 128 Kbps, which is twice that of the first run. In this second run, Client A has 200 NAKs. This means that half of all frames have been lost. This means that the speed of Client A is 64Kbps (ie, ((400-200) / 400) x 128Kbps = 64Kbps). Clients B ~ E show that no frames were lost in the second run. Therefore, the speed of each of these clients is at least 128 Kbps. In the third run, the transfer rate was 256 Kbps, indicating that clients A and B lost 300 and 50 frames, respectively. Therefore, from this third run, it can be seen that the speed of Client A is 64Kbps (that is, ((400-300) / 400) × 256Kbps = 64Kbps). This confirms the measurement result of the second run. Also, in the third run, the speed of client B is 128Kbps (ie, ((400-200) / 400) x 256Kbps = 128Kbps). Clients C to E indicate that there were no errors in the third run. Therefore, each of these clients is operating at a speed of at least 256 Kbps. In the fourth run, the transfer rate is 512 Kbps. Client A indicates that he has lost 350 frames. Therefore, it is measured as ((400-350) / 400) × 512Kbps, that is, 64Kbps, and this result is consistent with the previous measurements. Client B shows that it has lost 300 frames. Therefore, ((400-300) / 400) × 512Kbps, that is, 128Kbps This result is also consistent with previous runs. Client C shows that it has lost 200 frames. Therefore, it is measured as ((400-200) / 400) × 512Kbps, that is, 256Kbps. In the fifth run, the transfer rate is 1024Kbps. Client A shows that it has lost 375 frames. Therefore, it is measured as ((400-375) / 400) × 1024Kbps, that is, 64Kbps as before. Client B is measured as ((400-350) / 400) x 1024Kbps or 128Kbps, and Client C is measured as ((400-300) / 400) x 1024Kbps or 256Kbps. Client D is measured as ((400-200) / 400) x 1024Kbps or 512Kbps. Client E has no dropouts. This means that the speed is at least 1024Kbps. Therefore, for each of these five runs, the capacity of a given link is calculated by the following equation. ((Number of frames sent-Number of negative response confirmations) / Number of frames sent) x Transmission speed = Link capacity This test technique will also take into account traffic on the link. For example, if the physical link is 256Kbps and there is 128Kbps traffic on the link during the test, the measurement result will be the capacity of 128Kbps, the remaining capacity when traffic is considered. .. The software for performing these tests can also be used to test the quality of links, given that the source knows the link speed for each client. For example, in FIG. 6, since the link speed can be known, it is desirable to test the link using a relatively long test pattern in order to obtain the frame error rate. For example, 100, A 000 frame test file can be sent to a group of members A to E at 64Kbps. The transmission rate and NAK are stored in the source, and the number of NAKs from each client makes it possible to measure the quality of each link (ie, the frame error rate). It can be predicted that A will be the worst quality link because it is the heaviest loaded link and E will be the best because it is the least loaded link. However, other factors may have other consequences. Similarly, in order to put a heavier load on the faster links, the speed may be increased and the overloaded links may be removed from the group. Therefore, using the feature of the "multicast network probe" according to the present invention, even if the capacity of each link is increased.Even if it is unknown, the capacity of individual links can be measured quickly. Also, if the link speed is known to the server, this feature of the invention can be used to determine the quality of each link (ie, determine the frame error rate of each link). According to this feature of the present invention, the connectivity of members of a multicast group is first determined by going through the "announcement / registration" phase described above. That is, the first step is to determine which members in the group are connected to the server. Once the connected members are known, the server initiates a test file transfer, sends the test file to each member, and records the result (ie, the number of negative response confirmations for each group member). Link speed or quality can be determined.<u style="single">Speed group</u>If you know the capacity, speed, or bandwidth of each of the wide variety of links that interface the server to multiple clients (eg, made available by the "multicast network probe" feature mentioned in the previous section), then these speeds The list can be stored by the server. This list can then be used to generate or specify multiple client groups based on link speed. For example, there are two speed groups, one containing clients connected to the server on a link with a maximum possible speed of 64Kbps (ie, an effective link), and the other having a maximum possible speed. It may contain clients connected to the server on a link that is 1024Kbps (ie an effective link). Therefore, the second group is much faster than the first group. Which speed group a particular recipient belongs to affects the transfer of data to that recipient. During the first data transfer path according to the invention, the server sends all of the multiple frames to each receiver in the second, faster group, but each in the first, slower group. Only one (1/16) of the 16 frames sent to the second group is sent to the recipient. This means that after the first pass, the server is sending all frames to the recipients of the second group, but to the first group only one-sixteenth of the total number of those frames. It means that you have not sent it. The remaining frames that have not yet been sent to the first group (ie, 15/16 of all frames) are then sent to the recipients of the first group on subsequent passes. The point is, once the server knows the capacity of each member of the group, the server can take advantage of larger links and slow down the transfer of data to that group by coordinating the transfer of data. There is no point.<u style="single">Negative response confirmation collection</u>As mentioned above, the number of clients that can receive files according to the present invention can be in the thousands. Therefore, the number of entries in the client status list maintained by the server can be thousands. The number of file transfers according to the present invention can be further increased. For example, it can be scaled to send files to millions of recipients / clients instead of thousands of recipients / clients. In a preferred embodiment, these clients or recipients are members of a multicast group consisting of a plurality of clients. This scaling feature helps avoid problems that can occur when the number of clients in a group grows too large. The problem is that many clients send negative response confirmations back to the file sender (eg, server), and the number of negative response confirmations that the sender exceeds the processing limit in a reasonable amount of time. , Occurs when the sender is effectively blocked. This reduces the sender's performance. This is because the sender must spend an enormous amount of time receiving and processing the negative response confirmation and cannot engage in other obligations. This stagnates the link back to the sender and is congested by the traffic of these negative response confirmations. The solution to this problem is "collecting negative response confirmations". This makes it possible to dramatically increase the number of clients / receivers from thousands to millions without causing congestion on the file sender / server 20. According to this collection feature, some clients or other network nodes act as "replication points" to collect block negative response confirmations from other clients. In a preferred embodiment, these replication points (RPs) are routers. With reference to Figure 7, five RPs are shown across the United States. Also, the lines emanating from each RP will refer to one or more clients connected to that RP. Represents. For example, the RP100 has 1200 clients under its umbrella, the RP102 has 900 clients under its umbrella, the RP104 has 100 clients under its umbrella, and the RP106 has 800 clients under its umbrella. The RP108 has 500 clients under its umbrella. The server, or source 20, is located elsewhere in the United States. The RP100 collects all block negative response confirmations from clients that are subscribed to or connected to it (eg 1200). The other RPs 102, 104, 106 and 108 do the same for the clients that subscribe to them. For each RP, after collecting all block negative response confirmations from all the clients that subscribe to it, only one response confirmation message to server 20 or another RP in the chain to server 20. To send. That one message contains all of the block negative response confirmations from all clients subscribed to that RP. When server 20 finally receives these collected block negative response confirmation messages from multiple RPs, the server sends back all of the negative response confirmed frames on the next path. These RPs are responsible for receiving these trailing path frames and sending them out to the appropriate clients or other RPs in the chain. Those clients or RPs then send their frames to the appropriate clients or other RPs in the chain. Hereinafter, this operation is repeated. Modifications, modifications and other embodiments relating to those described herein will be conceivable to those skilled in the art without departing from the claimed spirit and scope of the invention. Therefore, the present invention should be defined by the following claims, not by the above exemplary description. P102 has 900 clients under its umbrella, RP104 has 100 clients under its umbrella, RP106 has 800 clients under its umbrella, and RP108 has 500 clients under its umbrella. There is. The server, or source 20, is located elsewhere in the United States. The RP100 collects all block negative response confirmations from clients that are subscribed to or connected to it (eg 1200). The other RPs 102, 104, 106 and 108 do the same for the clients that subscribe to them. For each RP, after collecting all block negative response confirmations from all the clients that subscribe to it, only one response confirmation message to server 20 or another RP in the chain to server 20. To send. That one message contains all of the block negative response confirmations from all clients subscribed to that RP. When server 20 finally receives these collected block negative response confirmation messages from multiple RPs, the server sends back all of the negative response confirmed frames on the next path. These RPs are responsible for receiving these trailing path frames and sending them out to the appropriate clients or other RPs in the chain. Those clients or RPs then send their frames to the appropriate clients or other RPs in the chain. Hereinafter, this operation is repeated. Modifications, modifications and other embodiments relating to those described herein will be conceivable to those skilled in the art without departing from the claimed spirit and scope of the invention. Therefore, the present invention should be defined by the following claims, not by the above exemplary description. P102 has 900 clients under its umbrella, RP104 has 100 clients under its umbrella, RP106 has 800 clients under its umbrella, and RP108 has 500 clients under its umbrella. There is. The server, or source 20, is located elsewhere in the United States. The RP100 collects all block negative response confirmations from clients that are subscribed to or connected to it (eg 1200). The other RPs 102, 104, 106 and 108 do the same for the clients that subscribe to them. For each RP, after collecting all block negative response confirmations from all the clients that subscribe to it, only one response confirmation message to server 20 or another RP in the chain to server 20. To send. That one message contains all of the block negative response confirmations from all clients subscribed to that RP. When server 20 finally receives these collected block negative response confirmation messages from multiple RPs, the server sends back all of the negative response confirmed frames on the next path. These RPs are responsible for receiving these trailing path frames and sending them out to the appropriate clients or other RPs in the chain. Those clients or RPs then send their frames to the appropriate clients or other RPs in the chain. Hereinafter, this operation is repeated. Modifications, modifications and other embodiments relating to those described herein will be conceivable to those skilled in the art without departing from the claimed spirit and scope of the invention. Therefore, the present invention should be defined by the following claims, not by the above exemplary description. The RP108 has 500 clients under its umbrella. The server, or source 20, is located elsewhere in the United States. The RP100 collects all block negative response confirmations from clients that are subscribed to or connected to it (eg 1200). The other RPs 102, 104, 106 and 108 do the same for the clients that subscribe to them. For each RP, after collecting all block negative response confirmations from all the clients that subscribe to it, only one response confirmation message to server 20 or another RP in the chain to server 20. To send. That one message contains all of the block negative response confirmations from all clients subscribed to that RP. When server 20 finally receives these collected block negative response confirmation messages from multiple RPs, the server sends back all of the negative response confirmed frames on the next path. These RPs are responsible for receiving these trailing path frames and sending them out to the appropriate clients or other RPs in the chain. Those clients or RPs then send their frames to the appropriate clients or other RPs in the chain. Hereinafter, this operation is repeated. Modifications, modifications and other embodiments relating to those described herein will be conceivable to those skilled in the art without departing from the claimed spirit and scope of the invention. Therefore, the present invention should be defined by the following claims, not by the above exemplary description. The RP108 has 500 clients under its umbrella. The server, or source 20, is located elsewhere in the United States. The RP100 collects all block negative response confirmations from clients that are subscribed to or connected to it (eg 1200). The other RPs 102, 104, 106 and 108 do the same for the clients that subscribe to them. For each RP, after collecting all block negative response confirmations from all the clients that subscribe to it, only one response confirmation message to server 20 or another RP in the chain to server 20. To send. That one message contains all of the block negative response confirmations from all clients subscribed to that RP. When server 20 finally receives these collected block negative response confirmation messages from multiple RPs, the server sends back all of the negative response confirmed frames on the next path. These RPs are responsible for receiving these trailing path frames and sending them out to the appropriate clients or other RPs in the chain. Those clients or RPs then send their frames to the appropriate clients or other RPs in the chain. Hereinafter, this operation is repeated. Modifications, modifications and other embodiments relating to those described herein will be conceivable to those skilled in the art without departing from the claimed spirit and scope of the invention. Therefore, the present invention should be defined by the following claims, not by the above exemplary description. Do the same for your subscribed clients. For each RP, after collecting all block negative response confirmations from all the clients that subscribe to it, only one response confirmation message to server 20 or another RP in the chain to server 20. To send. That one message contains all of the block negative response confirmations from all clients subscribed to that RP. When server 20 finally receives these collected block negative response confirmation messages from multiple RPs, the server sends back all of the negative response confirmed frames on the next path. These RPs are responsible for receiving these trailing path frames and sending them out to the appropriate clients or other RPs in the chain. Those clients or RPs then send their frames to the appropriate clients or other RPs in the chain. Hereinafter, this operation is repeated. Modifications, modifications and other embodiments relating to those described herein will be conceivable to those skilled in the art without departing from the claimed spirit and scope of the invention. Therefore, the present invention should be defined by the following claims, not by the above exemplary description. Do the same for your subscribed clients. For each RP, after collecting all block negative response confirmations from all the clients that subscribe to it, only one response confirmation message to server 20 or another RP in the chain to server 20. To send. That one message contains all of the block negative response confirmations from all clients subscribed to that RP. When server 20 finally receives these collected block negative response confirmation messages from multiple RPs, the server sends back all of the negative response confirmed frames on the next path. These RPs are responsible for receiving these trailing path frames and sending them out to the appropriate clients or other RPs in the chain. Those clients or RPs then send their frames to the appropriate clients or other RPs in the chain. Hereinafter, this operation is repeated. Modifications, modifications and other embodiments relating to those described herein will be conceivable to those skilled in the art without departing from the claimed spirit and scope of the invention. Therefore, the present invention should be defined by the following claims, not by the above exemplary description. Responsible for sending to a desperate client or other RP. Those clients or RPs then send their frames to the appropriate clients or other RPs in the chain. Hereinafter, this operation is repeated. Modifications, modifications and other embodiments relating to those described herein will be conceivable to those skilled in the art without departing from the claimed spirit and scope of the invention. Therefore, the present invention should be defined by the following claims, not by the above exemplary description. Responsible for sending to a desperate client or other RP. Those clients or RPs then send their frames to the appropriate clients or other RPs in the chain. Hereinafter, this operation is repeated. Modifications, modifications and other embodiments relating to those described herein will be conceivable to those skilled in the art without departing from the claimed spirit and scope of the invention. Therefore, the present invention should be defined by the following claims, not by the above exemplary description.