Network multicasting method using arq techniques for preventing unnecessary retransmissions

ES 2 163 011 T3

DESCRIPTION

Network multicast method that uses ARQ techniques to avoid unnecessary retransmissions.

Invention field

This invention relates to data transmission and more particularly to fast and reliable multicast transmissions of files from servers to clients.

Background of the invention

Computer networks such as Wide Area Networks (WANs) can provide unicast, multicast and broadcast services to allow communication between members of a network, such as a server node and one or more client nodes. Multicast frame retransmission is a service used to communicate on a computer network. IP multicast technology is another service used to communicate on a computer network. Broadcast frame retransmission is a service used to communicate on a satellite network. 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. Broadcasting and multicasting are capabilities offered by a network that are relatively new to WANs.

Some information providers wish to deliver information electronically by broadcasting or multicasting the information from a server node in a central location to one or more client nodes located in remote client stations, through a computer network to which the server and the computers are connected. customers. Since broadcast and multicast network services do not provide an acknowledgment of the information delivered at all, these services may not be reliable. Such unreliability is generally undesirable and unacceptable to information providers.

A common protocol package in use on computer networks is TCP / IP, which is the protocol used on the Internet. TCP is the acronym for Transmission Control Protocol and IP is the acronym for Internet Protocol. In association with TCP / IP, two protocols are available for file transmission: (i) FTP (File Transmission Protocol), which runs as an application above TCP, and (ii) TFTP (Trivial Transmission Protocol). files), which runs on top of UDP. UDP stands for User Datagram Protocol. Both TCP and UDP are transport protocols, responsible for the end-to-end delivery of information through an Internet network, that is, a network of networks.

Both FTP and TFTP only support point-to-point (ie unicast) file transmissions. FTP relies on TCP for reliable delivery, as TCP is a connection-oriented, acknowledged transport protocol. TFTP provides its own acknowledgments for reliability reasons, as it runs on top of UDP, which is a connectionless transport service that does not support acknowledgment.

Connection-oriented protocols such as TCP require the establishment and termination of virtual circuit connections. Given their relatively high overhead, TCP and similar protocols are undesirable in networks with inherently bad connections, such as CPDP (cellular digital packet data) networks. CPDP uses TCP / IP as the main protocol suite used on the network. The applications recommended for wireless networks CPDP work, only, on UDP (the transport layer without connections) and, therefore, TFTP is the file transmission protocol chosen for CPDP.

TFTP fragments files into packets with 512 batteries of data bits (bytes) each, and then sends one packet of data at a time. After each data packet is sent, TFTP causes the sending node to wait for an acknowledgment from the receiving node (s) before the sending node is allowed to emit the next data packet. TFTP was described, for example, in a book by Douglas E. Corner (Internetworking with TCP / IP, volume I, Principles, protocols and architecture, second edition, Prentice Hall, 1991, chapter 23, pp. 377-390.

Although the acknowledgment is part of TFTP, the acknowledgment scheme used in TFTP is very inefficient as the network delay becomes significant and / or is different for two or more of the receiving nodes. Like TFTP, other known data transmission mechanisms require a packet-by-packet acknowledgment, and thus these other mechanisms are also relatively slow in transmitting the entire amount of data.

In the 3^to European Conference on Satellite Communications -ECSC- 3, Manchester, GB, 2-4 November 1993, In ISBN 0-85296-603-2, London, GB, IEE, p. 11-15, XP000457972, QUERNHEIM U et al: "A new ARQ scheme for multicast satellite communications", describes a method for transmitting data over a communications link. Summary of the invention

An object of the present invention is to provide a fast and reliable transmission of files from a server to one or more clients, over a communication link. The transmission of files to clients is preferably a multicast transmission. In general, the transmission of files according to the invention did not suffer any reduction in speed, reliability or efficiency due to link delay, even when said delay is significant and / or different for two or more of the receiving clients. The invention provides an ideal mechanism for electronically distributing computer logic files.

The communication link, which couples the server to the clients and allows communication between them, can be a computer network (for example, a LAN, a WAN, the Internet), a wireless network (for example, a cellular data network packages, such as CDPD), a combination of these types of media

ES 2 cations, or some other means of communication such as, for example, a satellite network, which is generally a high-speed network with strong delay.

According to the invention, clients send only negative acknowledgments back to the server when it is sending the data files. Communication is continuous. That is, the server does not stop sending the data to wait for negative acknowledgments from clients, but instead the server receives negative acknowledgments from clients while transmitting the data. Negative acknowledgments from clients indicate to the server which particular data packets need to be resent. It may be necessary to resend a package because, for example, it was not received or was received with errors, by one or more of the clients. Once the server has sent the full amount of data (for example, the complete file) over the link to the clients, the server performs a second round of transmissions, in which it only forwards only the particular packets that the clients have indicated that they are. must be retransmitted. During this second round, clients only send negative acknowledgments (that is, indications of packets not received at all or not received correctly). The process can then continue with as many additional rounds of retransmissions as necessary, so that all clients correctly receive all packets. Alternatively, the retransmission rounds can be repeated a predetermined number of times, the number of which can be modified (ie, the number is configurable). Each subsequent round typically involves the transmission of fewer packets than in the previous round, since only previous packets with errors are forwarded.

This scheme quickly and reliably transmits data from a server to one or more clients. It is fast because the server is allowed to transmit the entire file without stopping at packet boundaries to wait for negative acknowledgments from clients for the packet that was just sent. That is, data transmission was not directly related to negative acknowledgments because each round of data transmission continued regardless of the reception problems of any particular client and / or regardless of any issues related to link delay. (for example, the difference between the time it takes for a packet to get from the server to a certain client and the time it takes for a packet to get from the server to a different client). Likewise, each subsequent round of transmission only supposes the sending of packets that were not received or that were received with errors, during the previous round and, therefore, the server does not always need, in general, to send the complete file more at once. . It is reliable because it tries to deliver all packages to all customers, and reception problems for any individual customer generally do not affect reception accuracy or speed for other customers.

The data transmission according to the in

011 T3 4 vento does not require, or expect, positive acknowledgments from any of the clients. An implicit positive acknowledgment is considered if no negative acknowledgment is received back at the server. Furthermore, in accordance with the invention, a plurality of negative acknowledgments are gathered and sent back to the server as a "multiple selective reject negative acknowledgment". Typically, more than one of these multiple selective rejection negative acknowledgments are returned to the server during, for example, the first round of transmission from the server to the clients. A multiple selective reject negative acknowledgment can represent hundreds of individual negative acknowledgments. Using these collections of negative acknowledgments can greatly reduce link traffic and free up link bandwidth for data transmission from the server to clients and for other uses. Thanks to the invention, the server and the link are generally not throttled with individual negative acknowledgments, all of which arrive at the same time or in a short time interval. This reduction in the number of individual acknowledgments sent over the link to the server also results in the significant and beneficial advantage of improved scalability. That is, using multiple selective rejection negative acknowledgments increases the number of clients a file can be sent to, due to reduced acknowledgment traffic returning from the server.

In a preferred embodiment of the invention, the entire amount of data to be transmitted (eg, a file) is separated into a plurality of blocks, each of which includes a plurality of packets. The server completes a round when it has finished transmitting all the blocks (for example, the entire file). After a complete block has been transmitted, clients send their negative acknowledgments back to the server through a return unicast communication path. Block limits trigger the sending of negative acknowledgments from clients. When negative acknowledgments for block N are coming into the server from clients, the server is transmitting block N + 1 (or a subsequent block) to clients, or the server has finished transmitting all blocks.

In accordance with the invention, the following features are provided. There is the possibility to set the transmission speed and define multicast groups. Likewise, it is possible to determine the capacity of links of unknown capacity using a "multicast network probe" characteristic, and to determine the frame error rates of links of known capacity, using the same characteristic. A multicast “ping” feature (“multicast internet address check”) can be used to determine connectivity between a source and members of a multicast group. "Speed ​​groups" can be established after determining the link possibilities or, if they are already known, thanks to which, in the first pass, the receivers connect

ES 2 163 011 T3 two to the source by the fastest links receive all the data, while the receivers with the slowest links receive only part of the data. The number of receivers that can receive the data from the source can be greatly increased (for example, by a factor of 1000 or more) using a "negative acknowledgment collection" scheme, whereby "repeater points, preferably routers , collect individual negative acknowledgments and send them as a unit to the next level.

It should be noted that the terms "packet", "datagram" and "frame" are used interchangeably in this memory to identify the same thing, namely, a data or information unit that can have a source and a destination address as part of it, and that is sent by the link.

The foregoing and other objects, aspects, features, and advantages of the invention will become more apparent from the following description and from the claims.

Brief description of the drawings

In the drawings, like reference characters generally designate the same parts throughout the various views. Also, the drawings will not necessarily be to scale, instead the emphasis is generally placed on illustrating the principles of the invention.

Fig. 1 is a flow chart of data transmission operations in accordance with the invention.

Fig. 2 is a diagram of a physical configuration that allows a server to communicate with one or more clients.

Fig. 3 is a diagram showing the situation of an embodiment of the invention in relation to the TCP / IP protocol stack.

Fig. 4 is a "first pass" block diagram and frame transmission and acknowledgment process in accordance with the invention.

Fig. 5 is a simplified block diagram of a server into which at least part of the present invention can be incorporated.

Fig. 6 is a diagram of a heterogeneous multicast network with members of a multicast group connected by links of different capacity.

FIG. 7 is a diagram illustrating an acknowledgment collection feature in accordance with the invention, which increases scalability and enables millions of receivers to receive data quickly and reliably from a sender.

Fig. 8 is a diagram related to flow / congestion control using a variable block dimension method.

Fig. 9 is a flow / congestion control related diagram using a preferred status request method to request negative acknowledgments from clients before block limits.

Description

Referring to Figs. 1 and 2, according to the invention, a fast and reliable data transmission, from a source or server 20 to one or more receivers or clients 22₁, 22₂,....,22_N over a communication link 24, it comprises (operation 10) transmitting the data (for example, a file) that takes the form of a plurality of frames, over the link 24 to one or more of the receivers 22, until it has been transmitted by link 24 the entire file (that is, the entire plurality of frames). As frames are transmitted, negative frame acknowledgments are received from one or more of the receivers 22 (step 10). If after the entire file has been transmitted on link 24, negative acknowledgments indicate that certain frames need to be retransmitted on link 24 (step 12), only those certain frames will be retransmitted (step 14). As these particular frames are retransmitted on link 24, negative frame acknowledgments are received from one or more of the receivers 22 on link 24 (step 14). This process is then repeated as many times as necessary until no more frames need to be retransmitted, as indicated by operations 12, 14 and 16. In operation 16, the server 20 determines if "done" messages have been received. "On server 20 by all receivers 22. If a receiver is listed as" done ", this means that it has received all the frames and has sent a" done "message to server 20 to indicate so. Recipients in "done" condition continue to send "done" messages to the server until they see their name in a "fact list" that the server sends as a notification to all recipients listed as "done" (that is, to contents in the "fact list") so that they stop sending "fact" messages to the server. After a predetermined period of time, or after a predetermined event, the server 20 sends a status request to all the receivers 22 that have not responded, that is, the receivers from whom a "done" message has not been received. ”(Operation 18). The initial transmission of the entire file, and each subsequent transmission of errored frames, is generally referred to in this specification as "round" or "pass."

In the first pass, the server 20 preferably multicasts the file to a subset of all the clients 22. Typically, at least two of the clients 22 have, associated with them, a different transmission delay of frames between server and client. Data transmission according to the invention is not affected by such delay differences, even when they are significant and even when each client 22 has a different delay associated with it.

Link 24 can be a computer network (for example, a LAN or WAN or Internet), a wireless network (for example, a cellular data network), a combination of these two types of communication media, or some other medium. of communications such as, for example, a satellite network that, typically, is of high speed and strong delay. The plurality of frames transmitted on link 24 during the first round may together represent a computer data file that is transmitted from server 20 to one or more of the clients 22.

Server 20 and clients 22 can be computers, such as PCs or workstations,

ES 2 that work with any one of a variety of operating systems, including DOS. With reference to FIG. 5, the server 20, regardless of which computer it is, typically includes a central processor 50, a main memory unit 52 for storing programs and / or data, an input / output controller 54, a network interface 56 , one or more input devices 58, such as a mouse, a display device 60, a hard or fixed drive 62, a floppy drive 64, a tape unit 66 and a main transmission channel 68 that couples these components to allow communications between them. Each of the client computers 22 generally includes all or some of the components included in the server 20 of FIG. 5.

In some embodiments, one or more computer programs define the functional capabilities of server 20 and clients 22. Programs can be loaded onto server 20 and clients 22 through hard drive 62, drive 64 floppy disk and / or tape drive 66. Alternatively, the programs may reside in a permanent memory portion (eg, a ROM chip) of main memory 52. In some other embodiments, server 20 and / or clients 22 may include specially designed, dedicated hard-wired electronic circuits that perform all of the functions described herein, without the need for instructions extracted from computer programs. The invention can be used, for example, to quickly and reliably upload new levels of client logic review electronically from the server to one or more of the clients.

Referring to FIG. 3, the invention preferably operates at the application layer 30 of the TCP / IP protocol stack 32, over UDP. The invention could also function in the application layer above the connectionless transport layer of other protocol stacks such as IPX in the NetWare SPX / IPX protocol package. UdP stands for User Datagram Protocol, and is the standard TCP / IP protocol that allows an application program on one computer to send a datagram to an application program on another computer. UDP uses the Internet Protocol (IP) to deliver datagrams. UDP datagrams differ from IP datagrams in that the former include a protocol port number that allows the sender of the datagram to distinguish between multiple destinations (ie, application programs) on the receiving computer. UDP datagrams also typically include a checksum for the data that is sent.

In general, a data transmission according to the invention includes four aspects: HOLD, ANNOUNCEMENT / REGISTER, TRANSMISSION and TERMINATION. In the WAIT state, there is no activity. When a data collection (eg, a file) is selected for transmission by the server 20, the ADD / REGISTER phase is entered. During which

011 T3 8 whichever of the four phases, all files are available to an operator on the server 20. Announcement / Registration

In this phase (operation 8 in FIG. 1), the server ANNOUNCES to the clients that a file is about to be transmitted and provides the parameters associated with the file transmission. The maximum duration of this phase is expressed in minutes and is configurable. An ANNOUNCEMENT message is used to establish multicast groups and class D addresses are used in assigning multicast groups.

Clients are required to notify the server that they have received an AD message. When a customer views the AD message, they verify that it was associated with the group identified in the message. The fact that the receiver is able to handle the AD message implies that the receiver has a correct server IP address and a correct port number. Clients automatically respond to AD packet with REGISTRATION packet until they see your address on a list of registered clients in a subsequent AD packet. The REGISTRATION packet acted as a positive acknowledgment to the server of the client's participation. Once the server receives the REGISTRATION packet from the client, it adds that client to the client list on the next broadcast of the AD packet. The client list is maintained by the server. When the customer receives an AD packet with the customer ID in the customer list, the customer registration is complete. When all the expected receivers have responded to the AD message or the period dedicated to the AD has expired, whichever occurs first, the actual transmission of the file began. This record indicates that the client can participate in the group, since it has the resources to process the file that was about to be sent. To prevent unwanted participation, an exchange of encryption keys can take place when establishing the group. Once the file transmission begins, ANNOUNCEMENT packets are no longer sent and the ANNOUNCEMENT phase is terminated (operation 9 in Fig. 1).

All the characteristics of the file transmission are transmitted in the AD package. Upon receiving this AD message, the client responds by sending a unicast datagram to the server. The response indicates whether or not the receiver has the capacity to receive the file. It also indicates, in the case of an aborted transmission, if the client has sufficient context to resume the transmission (a “restart” as indicated in Fig. 1). The length of the advertisement period, in some cases, should allow an operator, at the server site, to initiate a call to the customer site indicating that the computer is not available or lacks the necessary capacity for the transfer. At the customer site, corrections can be made manually or, if configured so, under remote server control to free up resources so that you can participate in the broadcast.

ES 2 163 011 T3

At any time during the transmission, the client can respond to this packet indicating that it has aborted the transmission on its part and stating the reason for this in the message. If a transmission has been interrupted before completion, the invention is capable of resuming it later without having to resend parts of the file already sent successfully ("reset" in Fig. 1). This is an especially important and useful feature when sending very large files. To achieve this feature, a client does not discard a partially received file. Instead, clients store partially received files. If there are problems that prevent all clients (for example, all clients of a multicast group) from receiving the complete file when it is being sent for the first time (for example, the link is interrupted for any reason during the transmission of the file) , the transmission can be started again later to complete the transmission. During a reboot, the server asks all clients for a list of missing data frames, and then the server begins to complete the transmission by sending only those frames. Thus, in FIG. 1, for a restart, operation 10 comprises a transmission that begins first with the missing frames (i.e., for which negative acknowledgments have been issued) during the initial aborted transmission, instead of starting with the first one. frame of the first block of the file, as would occur in a normal start, without aborting, of a transmission.

Transmission

When entering the data transmission phase, a transmission log is kept on the server. This diary is always activated, and keeps track of all events. Each of the clients also maintains a broadcast diary. The journal kept at each of the clients will be referred to below under the heading "TERMINATION".

Since data files of 2 Gb or larger can be transmitted, keeping the entire file in memory on the server, during transmission, is generally not a realistic approach. The number of clients that have to receive the file can be 1000 or more and, therefore, interrupting the transmission to wait for the acknowledgments of each one of them before continuing with the transmission of the next block, is an unacceptable question. .

The server logically fragments each file to be transmitted and each block includes, topically, a plurality of frames and, possibly, thousands of them. Referring to Fig. 4, in one example, the server 20 has fragmented a file into four blocks, namely, Block 1, Block 2, Block 3, and Block 4, each of which includes one or more frames. Each block represents a unit to which each client participating in a transmission will acknowledge negatively (only, no positive acknowledgments) when the client determines that a block has been sent by the server. The client detects this by a change in the block number in received data packets, since each frame sent indicates its block number and its frame number within that block. Fragmentation of the file into blocks provides at least two advantages: (i) the number of negative acknowledgments required is reduced, and (ii) the memory needs on the server are reduced to determine the blocks to be transmitted in the next pass the file.

Data transmissions are not directly related to negative acknowledgments. Transmission continued regardless of missing negative acknowledgments and previously missing data packets for an individual customer. This simplifies the design and ensures that the problems of an individual customer have minimal impact on the group as a whole. Note, too, that clients are responsible for sending negative block acknowledgments based on what the server tells them.

Referring to Fig. 4, the server initiates transmission by sending the first frame of the first block (ie the first Bi frame). The server sends the frames at a configurable rate. This represents that the basic transmission speed can be throttled (that is, reduced) based on the behavior. The server continued to send the branches of the file until the entire file has been sent once over the network (that is, until they are sent from Block! To Block₄). This is defined as first pass or first round and takes a time represented in FIG. 4 as "B₄”. Some clients may receive the complete file (that is, all four blocks) correctly after the first pass, in which case they have finished receiving the file. Clients that receive one or more errored frames, or do not receive one or more frames at all, require certain “pieces” of the file (that is, frames received erroneously or missing) to be resubmitted in subsequent passes or rounds. . Each subsequent pass or round requires the transmission of fewer frames, as only frames that have been negatively acknowledged (i.e., frames not received or received with errors) in the previous round, are retransmitted in the subsequent round.

A maximum pass count or maximum time to completion can be a configurable parameter. There may be clients who have not correctly received the entire file at the time when the maximum time dedicated to a pass or a maximum time has elapsed. These clients are identified and the server can take another action to provide these clients with the rest of the information, for example by means of a unicast file transmission process. In the preferred embodiment, clients send “done messages” indicating that they have received the entire file and the server sends “fact lists” indicating which clients have told them it is “done”. If, after a predetermined event (for example, a predetermined amount of time ”) the server does not receive a“ fact message ”from certain clients and has been rendered

ES 2 163 011 T3 service to all NAKs (negative acknowledgments), the server sends a status request message to those clients and sends any missing frames to clients that need more data. The file can be sent, for example, to any client that has not yet responded, for example, in a unicast transmission directed to that client from the server, at a later time.

As the server passes the block limits (that is, B_1; B₂, B₃ and B₄ in FIG. 4), individual clients preferably send "multiple selective rejection negative" acknowledgments ("Nak") for each block. These acknowledgments from the clients for each block are received by the server long after the block limit has been passed. Positive acknowledgments are implicit. A negative multiple selective rejection acknowledgment for a particular block means that one or more frames of that particular block were received with errors or were not received by those clients indicating that the network did not deliver them for some reason. Thus, the acknowledgments sent to the server indicate which frames were received with errors or were not received.

In subsequent passes (that is, after the first pass shown in Fig. 4), clients only respond with negative acknowledgments for blocks that have also not had a correct reception. Since the server, in subsequent passes, sends pieces (frames) of the file that several clients need to all clients, many of the clients will have already received them correctly in the first pass and, therefore, ignore them.

In general, all the information that returns to the server from the clients can be transmitted by a return path separate from the path (s) that the server uses to transmit the frames to the clients. However, for the purposes of this description, it should be assumed that the communication link 24 (Fig. 2) or another path that allows the server and clients to communicate, fulfills the mission of both the server-client link and that of communication. return link from client to server.

The server maintains various information about the broadcast and those who participate in it. In the preferred embodiment, this information is maintained by the server in the form of data structures or lists. The server maintains and uses this information to record and determine the status of the file transmission.

The server also maintains a frame data structure that indicates all selective rejections of individual frames, from all clients. If multiple clients are missing the same frame, the frame data structure would only indicate that that frame is missing. That is, the frame data structure is not maintained by the server on a client-by-client basis. Generally, it is undesirable for the server to maintain a detailed list of missing frames on an individual client basis because such a scheme would use an exaggerated amount of memory, particularly when multicasting involves a large number of clients (e.g. 1000 or more). . For example, it could happen that one or mine of the clients do not receive, or receive with errors, frames twenty and twenty-five of the Block, frame one of the Block₂, certain frames of the Block₃, etc. If the state of frames maintained by the server indicates that a particular frame of a particular block needs to be retransmitted, it will be true that at least one of the clients has not acknowledged a successful completion of that particular block. After the server has sent the entire file once, it would then review the frame status information and forward only the frames that would be found in the list. This would continue, pass after pass, until all clients had sent "done messages" and the frame status list was empty (or the maximum number of rounds had been reached or the maximum time dedicated to it had expired).

Note that, for any given pass, if no negative acknowledgment reaches the server, the client will send the same rejection and transmission request messages back to the server during the next server pass. This means that if a certain client is not being served by the server, said client would have to participate for a longer time, but this will not have an appreciable impact on the rest of the receiving clients.

Another piece of information stored on the server is multicast group statistics. When a broadcast is completed, information is provided in summary form about the broadcast, which can help the operator determine system behavior problems and / or the behavior problems of a particular customer.

Multiple passes through the file

After the file has been fully processed once (i.e. after the first pass or round), the transmission process according to the invention will increment a pass counter and then scan the list of frame status from the server looking for the first block where an error occurred Upon encountering this first failed block, the server will resend the missing packets from that block. Negative acknowledgments for these missing packets will be generated, as previously described, by clients when they detect an error in a block. This is consistent with the first pass. All negative selective reject acknowledgments are status indications and are therefore not specific to one pass, as they can change with each pass. In a preferred embodiment, multiple selective rejection negative acknowledgments take the form of bitmaps in which the entire word represents a block and each bit of that word represents a different frame from the frames that make up that block.

Transmission abort

If a fault is found during the transmission that cannot be rectified, or if the operator aborts it manually, a transmission abort sequence will be initiated. This sequence involves the repeated transmission of an “Abort” message during a certain interval (for example, an in

ES 2 163 011 T3 (value specified in a transmission file). The receivers acknowledge receipt of the abort message and may take actions, for example, to save the context in view of a potential resumption (ie a restart) of transmission or to reinitialize the context to prepare for another transmission. There is a possibility that allows the user to initiate an abort operation of a transmission. A reason code can be set to suspend or initialize. In the first case, the transmission can be resumed or restarted some time later and, in the last case, the clients were asked to reinitialize their contexts.

Termination

The server detects that individual clients have completed the reception by receiving a "fact message" from a client. The client knows if it is done as soon as it has all the blocks in the file, but it must continue to send "fact messages" until the server confirms the completion. The server confirms that a client is "done" by putting that client's address on a "fact list" and sending the list to the clients. When a customer sees their address included in the "fact list," they know the transmission is complete. The client then updates his transmission journal to indicate that the transmission has been completed successfully.

The possibility of aborting a transmission from the server or from the client is included. An abort packet provides the server and client with the ability to prematurely abort a transmission. If the client sends an abort command, the server removes the client from the group. If the server aborts, the transmission can be restarted without sending the entire file in the first pass.

State requests

If, after the first pass, the server has not received a FACT or a NAK from a client, a question is sent directly to those clients whose status is unknown. Responses take the form of a standard response message. Responses will include a bitmap describing the errors, if there are any to report.

Congestion / flow control

As the large "internet" are enabled for multicast, it will be increasingly common to find multicast groups that want the information to have different transmission links for the members of that group. These different links can have different capabilities, which can differ greatly from each other. For example, one member of the group may have a link capacity of more than 1 Mbps, while another may have only 56 Kbps. In general, the sender of the transmission (for example, the server) was unaware of these link capabilities. Thus, it is desirable to be able to determine link capabilities on the fly, and to provide a flow control mechanism to prevent network overload / congestion, while not inhibiting the efficiency of the data transmission protocol.

The data transmission protocol described in this specification includes the concept of blocks, each of which can contain hundreds or thousands of frames. Clients (receivers) are required to send a multiple selective rejection NAK at block boundaries if any frame is missing or if there are errors in that block. For flow control purposes, it is desirable to have knowledge, as soon as is practical, of missing or errored (i.e. lost) frames, so that decisions about flow control can be made. To achieve this with the data transmission protocol of the invention, it consists of using variable or changing block sizes, This involves starting with a relatively small block and increasing the block size during file transmission, to maintain current scalability by reducing customer acknowledgments. Another preferred way to achieve this using the data transmission protocol of the invention is to keep the block sizes the same (homogeneous block size) but let the server send status requests before a block limit is presented, so clients to respond with a NAK before the block boundary. This last technique is the most flexible, since the NAKs can be requested at any time, unlike the first technique, in which they are requested precisely at the block limits. With either of these two techniques, NAKs are requested early in the transmission.

In the "variable block size" method (the first technique mentioned in the previous paragraph), the first block can be relatively small, for example 100 frames. Subsequent blocks increase, each time, by a factor of two. Block sizes are increasingly doubled until the maximum block size is reached or until the end of the file is reached.

In the "request status" method (the second technique mentioned previously), the server requests responses from NAK at the points it wants, which are not the block limits. With this preferred embodiment of congestion or flow control, status requests are sent at increasing intervals.

With both methods, the transmission or transfer rate is set as described herein. However, instead of a fixed baud rate, the adjustable speed represents an upper limit for baud rate. After the first block has been received (with the variable block size method) or when a status request has been received (in the case of the request status method), clients that have lost frames send NAKs to the server, and this supposes an indication of congestion on the part of those clients for the server.

If NAKs exist, the fact that they are directly related to the instantaneous capacity of the particular link can be taken advantage of to determine the link capacity for all congested connections, based on the following equation:

ES 2 ((number of frames sent - number of frames with NAK) / number of frames sent) * transmission speed = link capacity

In the heterogeneous multiplex network of FIG. 6, the link speeds range from 64 Kbps to 1024 Kbps, which makes a big difference between the connection capacities. Assuming that there is no other trophic, if the baud rate were set to 150 Kbps, the block NAK for block 1 from client A (in the variable block size method) would indicate the loss of 58 frames for the block. first block. Using the above equation, it is calculated that the instantaneous speed of the link is 63 Kbps. The block NAK from client B for block 1 (in the variable-size method of blocks) would indicate the loss of about 15 frames for the first block. Using, again, the equation, it is calculated that the instantaneous speed of the link with B is 127.5 Kbps. When another trophic is present, the number of lost frames will be higher, with the result of lower calculated connection speeds.

The user can set a group threshold parameter. The group threshold is the limit, expressed as a percentage of lost frames, for a particular client, below which they are allowed to continue participating in the multi-broadcast group. If the group threshold is set to 25%, this means that which clients of the group who have a percentage of frame losses greater than 25% will have to take measures so that the rest of the group is not adversely affected. In the example in Fig. 6, client A, with 58% lost frames, should take action. Clients will have enough information to make a decision, since the parameters of transmission speed and group threshold are transmitted to clients in the advertisement message. Clients that detect that their frame loss rate exceeds the threshold should take one of the following actions:

1. Leave the group and ask the server to host them in a group with a lower speed, based on the specific speed of the group on the measurement performed for that client;

two. Leave the group without requesting more deliveries, which means that this customer was missing this transmission; Y

3. Suppress the NAKs until a status request message is received from the server, allowing the rest of the group to terminate without being delayed by excessive retransmissions due to a client losing a large number of frames (the transmission rate for retransmissions to this Client set could be lower, to reflect your lower chances).

In the example of Fig. 6, the next highest percentage of frame losses comes from customer B, with 15% being below the group threshold. This number

011 T3 16 represents a factor to which the entire group can adjust without undue degradation of performance. The server transmission speed for the group is reduced, then, by 15% or a higher or slightly higher percentage, to adapt to client B.

The timing of the variable block size method is given in Fig. 8. As soon as the information of a client indicates that his loss of frames exceeds the group threshold, the client must adopt one of the three alternative actions listed above, so that transmission to the group is not adversely affected. The group baud rate setting is performed after the second block has been sent, starting with the beginning of block 3. Baud rate changes are made at the lock limits to provide accurate data, on a lock basis, from the lock NAKs. The transmission of the file then continued with the transmission of block 3, which has been set twice as large as block 2, even as block 2 is twice as large as block 1. This is followed by block 4, which is twice as large as block 3, and so on until the maximum block size is reached or the file reaches its end, whichever comes first. However, if the NAKs of the group, after block 3, indicate that the client with the worst characteristics exceeds a parameter (configurable) of speed threshold, then the speed is set again for the transmission of block 5. The speed threshold is the percentage of loss of frames for which the transmission speed settings are made for the group. For example, a maximum percentage of losses of 1% by customers, would not deserve an adjustment, so that the speed threshold would be set, topically, in a figure higher than 1%.

In the state request method, the locks are of a uniform size and the server sends state requests to request NAKs before the Lock Thresholds are reached. Referring to Fig. 9, it represents a scenario equivalent to the one just described for the variable-size block method, except that now (in Fig. 9), the size of the blocks is homogeneous. In one example, the first status request is sent after 100 frames have been transmitted, the second after 200 more frames have been transmitted, etc. Clients' NAKs are sent back to the server at exactly the same times as in the case of the variable-size lock method. However, with the status request method you have the increased flexibility of being able to send status requests at any time you want, instead of having to wait for a block limit to receive NAK, as is the case with the method. of blocks of variable size.

Either with the variable block size method or the status request method, it is generally not desirable to simply suppress group members and leave them hanging. Members of suppressed groups may reco

ES 2 163 011 T3 gerse in another group, which operates with a lower transmission speed. This lower transmission speed can be determined by calculating the capacity of the links of the clients leaving the group. This group can then be established with a matching baud rate and a new transmission can be started.

Both variable block size and status request methods of the flow control procedure can be executed automatically.

Multicast

Multicast can take two forms: multicast in AL (application layer), when the network still delivers data to the entire broadcast group, and multicast IP, when the network directs traffic based on multicast routers, and clients are It satisfies the RFC112 Internet specification.

In both cases, multicast groups are established at the behest of the server. The server sends notifications on a unicast basis to clients to inform them of their integration into a particular multicast group. These multicast groups can be quickly established and dismantled, allowing for dynamic configuration of multicast groups. For example, a multicast group may be established solely for the transmission of a particular file, after which the group is dismantled.

With multicast in AL the network continues to deliver traffic on a broadcast basis, but clients that do not belong to the group discard data not intended for them. When the group is established, security keys must also be disseminated so that clients that do not belong to the group cannot read the data, even when it happens that the data was not discarded in that node (note that this could also be prepared with the Multicast IP). Also, with multicast in AL, the IP address remains a global or network-based broadcast address. As with multicast, this address is translated into a broadcast address in the link layer protocol, for example a SMDS broadcast address. A header is selected for the group, which becomes the differentiator for this.

With multicast IP, the network becomes a network of routers in which the routers support multicast IP addresses, class D and multicast routing. Clients support RFC1112, “Core Extensions for Multicast IP”. RFC1112 allows the host computer to notify the nearest multicast router of its presence in order to update the router tables.

In the following, a functional description of the above-described invention is given.

Referring back to Fig. 2, which can generally represent any network based on IP multicast routers or unicast routers, one purpose of the invention is to allow the simultaneous transmission of small or large data files (for example, files with a size of up to 2 Gb or greater) by a server 20, up to 5000 or more receiving nodes 22, by a WAN (wide area network) connection 24. The invention is also capable of working over local area networks and other types of communication links, as previously described. The transmission medium 24 can be of any type that supports the TCP / IP protocol stack in the preferred embodiment. Other protocol stacks could also serve as the communications environment for the invention.

Multicast can be supported in two ways: multicast in AL and IP multicast, as mentioned above.

Files to be transmitted to clients can be uploaded to server 20 by tape (for example, tape drive 66 in Fig. 5) or, if the files are small enough, by floppy disk (for example, drive disk of Fig. 5). Likewise, the files to be transmitted can be uploaded to the server 20 through FTP (file transmission protocol) or by some other unicast transmission mechanism, from the source of the file over a LAN or other network, for example. The files can generally have any format. The data file is then read from tape or diskette to a file system on the transmitting server 20. Note that the server 20 must have enough space to read an uncompressed copy of the data file. For both services, the data file can also be encrypted, so that unselected recipients cannot receive and use the data file. Each transmission file preferably has a unique identification. Preferably, there is an indication as to its content and the time for its generation. The input files for the process can be larger than 2 Gb and the system can also handle files much larger than 2 Gb.

The file can then be stored on server 20 and ready for transmission. Data from previous transmissions will have to be readily available on the server 20 for a period of time, should it be necessary to retransmit it. A mechanism is provided to access the data, such that the data can be easily queued for retransmission.

For efficiency, the file is transmitted in blocks. The size of a block is derived from the largest packet (or the user can select the block size) that can be transmitted over the communication path 24. Its deduction is based on the fact that clients have to indicate to the server which of the packets of a block they have stopped receiving. One way, which is generally the simplest, to achieve this is to send a bitmap that indicates by a bit that adjusts positionally, which packets were not received. Thus, the block size is roughly equal to the number of packets that can be acknowledged in a bitmap that, in turn, can be contained in a packet. For example, if the packet size were 256 bytes (bit batteries), then the maximum number of bytes

ES 2 (bit batteries) that a packet could hold would be 256 (bytes / packet) * 8 (bits / byte) = 2048 (bits / packet), which means that the largest allowable block size would be one block with 2048 packages.

Although the receiving nodes 22 can be interconnected to a 10 Mbps Ethernet LAN, the WAN links are often much slower than that number. Thus, an explicit data transmission rate is adjustable / configurable.

Each of the receiving nodes may experience resource problems, either before or during a transmission. The receiving nodes are able to ask their resources before a transmission and to determine if they have the capacity to receive the data. If not, they must reinitialize space dedicated to the transmission or they must indicate that they cannot participate in the transmission, and a corrective measure can be taken through different channels. The possibility could be envisaged that the server may force the availability of space on remote disks to allow the file transmission to take place.

The receivers 22 must also be aware of what they hear. When a datagram is received on a dedicated channel, node 22 must determine if it is being addressed. A question may arise when this request is being used by more than one streaming server. There must be a way to ensure that the receiving node 22 participates in exactly one transmission at any given time. By dedicating a UDP port to a server 20 and also relating an encryption key to that server, it is ensured that a receiving node that makes use of it indiscriminately on the network 24 would not be able to interpret the transmitted data.

Some reference information is maintained at the transmission server 20. Preferably, there is a list of all potential receiver nodes on the network. Preferably, enough reference information is available to allow the information provider to manage customers in the event of service failures, problems, etc. Preferably, there would be a transmission database in which a compressed and encrypted data file is kept ready for transmission. The transmission database contains the prepared data together with descriptive information of up to, for example, 70 bytes, identifying the content of the files.

Each transmission preferably has a finished status indicator log and a journal of all errors found during the transmission. Preferably, there is also an event file with a list of all the nodes for which the transmission failed, who to call and why it failed.

At any time during the transmission, an operator can ask about the status of the transmission, addressing the server 20 and each of the receiving nodes 22. Alerts are generated if there are problems in communication with certain clients or otherwise.

011 T3 20

If any intervention is indicated, the operator can initiate corrective action.

For management and maintenance during service operation, the operator is allowed to maintain the list of receivers, transmission groups, transmission file descriptors, transmission parameters, and transmission database. A background process will maintain the environment and the aging of the data, deleting them according to verification parameters, if enabled by a warned operator.

Data transmission according to the invention has been described above. Hereinafter, other aspects of the invention would be described. These other aspects include: Adjustable Transmission Speed; Multicast Groups; Verification of Internet Addresses (PING) Multicast; Multicast Network Probe, Speed ​​Groups, and Collection of Negative Acknowledgments.

Adjustable Transmission Speed

As mentioned previously, it is possible to set the data transmission speed. The example given above illustrated when an adjustable speed is useful. In that example, the receiver nodes 22 are interconnected to an Ethernet LAN that has a bandwidth of 10 Mbps and the WAN links that connect the LAN to other networks have speeds much lower than 10 Mbps. In such a case, the data transmission rate would be adjusted, according to the invention, to match, for example, the speed of the slower WAN link.

According to the invention, for any given file transmission session, the data transmission rate can be set in advance. More specifically, the maximum transmission speed at which data is transmitted during the session is adjustable. In a preferred embodiment, it is adjusted by setting a parameter to an integer value representing the speed in kilobits per second (Kbps). For example, if this speed parameter has a value of 56, it corresponds to a maximum transmission speed of 56 Kbps. The speed parameter can be set to any value that corresponds to the available bandwidth on the link connecting the source. to the destination or to a value representative of a speed lower than the available bandwidth. That is, if the available bandwidth is 1 Mbps, the speed parameter can be set to any value between zero and one thousand, where 1000 Kbps is equal to 1 Mbps. This possibility of explicitly setting the transmission speed allows the Long file transmissions (in time) coexist with other applications on the network without occupying all or substantially all of the network bandwidth.

Multicast Groups "Multicast" has been defined above as the case where the server 20 sends data (for example, a file) to a subgroup of all client nodes 22 connected to the network.

24. Previously, it has also been described that multicast transmission can take two forms: “application layer multicast

ES 2 163 011 T3 (AL) ”and“ IP multicast ”. Multicast in AL is used when the network does not support the RFC1112 Internet specification, but does support broadcast. If the network supports IP multicast in accordance with RFC1112 and IP multicast routing, we recommend this instead of multicast in AL. Multicast IP is used when group members must support multicast and their network routers must also support some kind of multicast routing protocol (eg, DVMRP, MOSPF, or PIM). Unlike multicast in LA, IP multicast is a true multicast protocol, in which only the members of the multicast group receive the transmitted data.

For each file transmission, a multicast group may be defined during the ADVERTISEMENT / REGISTER aspect of the data transmission, as described above. As has been established, the server maintains diverse information about the transmission of files and the participants or the group involved in the transmission. In the preferred embodiment, this information is maintained by the server in the form of data structures or lists. The server maintains and uses this information to record and determine the status of the file transmission during the DATA TRANSMITTING stage. The client status structure includes a list of the status of the multicast group participants based on data from the announcement records received by the server.

Multicast group management is the process of assigning clients to multicast groups. In principle, the task of organizing and manipulating the list of clients of each group is the responsibility of the application program that initiates the transmission of files. This application program generally provides easy-to-use features, such as associating a name with a client IP address, assigning a name to a group, etc. Group management is only required at the dispatch station, for example, on the server. A multicast group is specified when a dispatch station wants to transmit a file. The group is identified by a list of client IP addresses, with an address corresponding to each client in the multicast group.

There are two options for multicast groups: dynamic and static. In the case of dynaomic multicast groups, when transmission is complete, the group dissolves. Dynamic multicast groups are formed with AD messages using multicast group class D addresses. In contrast to dynamic multicast groups, in the case of static multicast groups, all members of the group remain so when transmission is complete. Staotic multicast groups are formed by the server on a unicast basis and / or using a common class D address to configure settings.

Internet Address Verification (PING) Multicast

The utility of "ping" in TCP / IP is extremely useful to determine the connectivity between two points of a TCP / IP network (that is, to determine if two points are really connected). In TCP / IP a packet is sent " ping ”to the desired endpoint, which reverses the addresses and sends it back to the sender. The time delay in the round trip is also measured, this being a measure of the time it takes for the "ping" packet to travel from the sender to the desired end point and then to return to the sender.

It is also desired to provide a multicast "ping" utility, when all members of a multicast group respond to the "ping" packet or to the "ping" request. Clients or PBXs that support IP multicast (RFC1112) will respond to a “ping” request with a class D IP address as the destination address. However, in known multicast practical implementations, the sender of the "ping" request only presents the first response it receives to its "ping" request. That is, known multicast "ping" techniques do not perform a measurement of network connectivity.

A "multicast ping" feature of the invention presents all multicast responses to a "ping" request, thus providing network connectivity information from source to group receivers, and information about time delay. roundtrip for each multicast group receiver. In a preferred embodiment, this feature makes use of standard ICMP "ping" messages.

Following an improvement in accordance with the invention, it is also possible to use the Announcement / Registration capability described above as another form of the "multicast ping" feature. Thanks to this improvement, the Announcement / Registration “ping” messages determine the connectivity to the application layer of the receivers of the group and back to the sender and the information about the time delay in the round trip for each receiver of the group. group.

The “multicast ping” feature thus allows the sender to determine network connectivity and round-trip delays for members of a multicast group. Multicast Network Probe

Multicast data networks (sending one to many, but not all) are only beginning to be incorporated into practice. IP multicast, in particular, is new among router networks and can provide the mechanisms to create multicast groups over networks of all kinds, eg, frame relay, SMDS, LAN, satellite or wireless. The Internet also has the main multicast segment ("Mbone"), which is a part of the Internet that supports multicast IP.

The "Mbone" started in early 1992 and has grown so that, by early 1995, there were more than 1,500 multicast-enabled Internet subgroups. Until now, the "Mbone" has been used as an experimental network by Internet researchers, who have

ES 2 tested video conferencing and multicast white board applications, as well as Internet “radio” and other experimental applications. IP multicast routing on the "Mbone" was initially implemented in workstations that use the DVMRP multicast routing protocol; however, parts of the "Mbone" have had their routers updated so that they are multicast-enabled. It is anticipated that within 5 or 6 years, the Internet will be fully multicast enabled thanks to the use of Internet routers.

As the Internet becomes multicast-enabled, it will be used for mainstream multicast applications rather than as an experimental search tool. When this happens, tools will be necessary to facilitate its use.

A big difference between the Internet and a private network is that the former is a very heterogeneous network. It is a network of networks and there are great differences in the different parts of the network, operated by different organizations. In contrast to this, many private networks are established in such a way that they are relatively homogeneous, with great control on the part of the private network operator regarding the architecture of the same.

As it is very likely that the endpoints of the multicast network are connected at different speeds with different networks and the network congestion will be different in different parts of the network, it is desirable to be able to know the capacity of the connected links of the multicast group, and check behavior with that ability. A "multicast network probe" feature of the invention is designed to be able to poll the "Mbone" and other large heterogeneous multicast networks from the source of the traffic and measure the capacity of individual links quickly from that source of traffic.

Referring to Fig. 6, a heterogeneous multicast network (for example the "Mbone" part of the Internet) has a multicast group with five members, A to E, each of which was connected by a link of different capacity. , that is, a link at a different speed. Group member A was connected to the network using a 64 Kbps (kilobits per second) link, B through a 128 Kbps link, C with a 256 Kbps link, D with a 512 Kbps link, and E through a link. At 1024 Kbps, the nature of these link connections is unknown to the server (ie the source of traffic) because Internet connections can be made through many links at different speeds.

It is desirable that the traffic source knows the characteristics of the links with the destinations, so that it can determine, in an optimal way, how to carry out the multicast transmission of information to the destinations. If the application is a videoconference, it can be determined that the quality for A, at 64 Kbps, may be unacceptable, but the rest could participate at 128 Kbps. Similarly, if the application is the transmission of files, groups D and E could constitute

011 T3 24 a group that operated at a transmission speed of 512 Kbps, while groups A, B and C could operate at 64 Kbps without exceeding the capacity of the network.

According to the invention, the mechanism for polling the network in order to determine the capacity of remote connections, consists of the system and the protocol described in this specification. Next, to use an Announcement / Registration for a multicast group consisting of members A to E, as a means of determining connectivity (that is, determining which members are actually connected to the server) according to, for example, the characteristic The "multicast ping" method of the invention, described in the preceding section, sends a test set of small files, in sequence, at different rates, to the group members. For example, a 400-frame test file can be sent first at 64 Kbps, then 128 Kbps, then 256 Kbps, then 512 Kbps, and finally 1024 Kbps. Negative acknowledgments of the Clients will be received and stored on the server as shown in Table 1 below, assuming there is no more traffic on the links.

TABLE 1

Test results with 400-frame test file

<td>Velocity</td><td>No.</td><td colspan="4">NUmde NUmde NUmde NUmde</td>

<td>from</td><td>by NAK</td><td>NAK</td><td>NAK</td><td>NAK</td><td>NAK</td>

<td>Shipping</td><td>for to</td><td>for B</td><td>for C</td><td>for D</td><td>for E</td>

<td>64 Kbps</td><td> 0</td><td> 0</td><td> 0</td><td> 0</td><td> 0</td>

<td>128 Kbps</td><td> 200</td><td> 0</td><td> 0</td><td> 0</td><td> 0</td>

<td>256 Kbps</td><td> 300</td><td> 200</td><td> 0</td><td> 0</td><td> 0</td>

<td>512 Kbps</td><td> 350</td><td> 300</td><td> 200</td><td> 0</td><td> 0</td>

<td>1024 Kbps</td><td> 375</td><td> 350</td><td> 300</td><td> 200</td><td> 0</td>

Referring to Table 1, the first pass at a speed of 64 Kbps resulted in the non-appearance of negative acknowledgments (that is, NAK or Nak) in any of the group members, since all the links support, as iioniiiio, 64 Kbps.

The second pass is at 128 Kbps, twice the first. In this second pass, client A presents 200 NAKs, which means that half of the frames were lost.This means that client A's speed is 64 Kbps (that is, ((400-200) / 400) * 128 Kbps = 64 Kbps). Clients B to E do not show frame losses in the second pass and, therefore, the speed of each of these clients of at least 128 Kbps.

In the third pass, the transmission speed is 256 Kbps and clients A and B have 300 and 500 lost frames, respectively. Thus, from this third pass it can be deduced that the speed of client A is 64 Kbps (that is, ((400300) / 400) * 256 Kbps = 64 Kbps), which confirms the measurement of the second pass. Also, in the third pass, the speed of client B is 128 Kbps (that is, ((400-200) / 400)^*256 Kbps = 128 Kbps). Clients C to E are error-free in this third pass, and therefore each is running at least 256 Kbps.

ES 2 163 011 T3

In the fourth pass, the transmission speed is 512 Kbps. Client A presents 350 lost frames, so that for him ((400-350) / 400) * 512 Kbps or 64 Kbps is measured, which agrees with the previous measurements. Client B presents 300 lost frames, its measurement being ((400-300) / 400) * 512 Kbps or 128 Kbps, which also agrees with the previous passes. Client C has 200 lost frames, its measurement being ((400-200) / 400) * 512 Kbps or 256 Kbps.

In the fifth pass, the transmission speed is 1024 Kbps. Client A presents 375 lost frames, its measurement being ((400375) / 400) * 1024 or 64 Kbps, as before. The measurement for client C is ((400-350) / 400) * 1024 or 128 Kbps, and the measurement for client C is ((400300) / 400) * 1024 or 256 Kbps. The measurement for client D is ((400-200) / 400) * 1024 or 512 Kbps. Client E is lossless, which means that its speed is at least 1024 Kbps.

Thus, for each of the five passes, the capacity of a given link is provided by the following equation:

((no. of frames sent - no. of nak) / min. of frames sent) * baud rate = link capacity

This testing technique will also take into account link traffic. For example, if a physical link operates at 256 Kbps and has 128 Kbps traffic when the test is run, the measurement will result in a capacity of 128 Kbps, which is the remaining capacity when traffic is considered.

The programming logic to put these tests into practice can also be used to check the quality of the links, assuming that the source knows the speeds of the links with each client. For example, in FIG. 6 the speeds of the links can be known and it is desired to check them with relatively long test patterns, to determine the framing error rates. For example, a test file of 100,000 frames, at 64 Kbps, could be sent to the group comprised of members A to E. The transmission speed and NAKs are stored at the source, and the number of NAKs from each client gives a a measure of the quality (that is, the framing error rate) of each link. It would be expected that A had the worst quality, since it is the link that supports the greatest load and that E was the best, since it is less loaded. However, other factors could lead to other results. Similarly, speeds can be increased and overloaded links can be removed from the group, to force higher speed links more.

Thus, using the "multicast network probe" feature the server can quickly measure the capacity of individual links, if the capabilities of individual links are unknown. Also, if the server knows the speeds of the links, this feature of the invention can be used to determine the quality of each link (ie, to determine the frame error rate of each link).

In accordance with this feature of the invention, the connectivity of the members of the multicast group is first determined by executing an ADD / REGISTER phase described above. That is, the initial operation consists of determining which members of the group are connected to the server. Once it is known which members are, the transmission of a test file can be started to determine the speed of the links or their quality, the server sending a test file to each member and recording the results (that is, the number of links). negative acknowledgments from each group member).

Speed ​​Groups

Knowing the capacity, speed or bandwidth of each of the various links that interconnect the server with the clients (which can be achieved, for example, thanks to the "multicast network probe" feature described in the preceding section ), the server can store a list with these speeds. The list can be used to generate or define a plurality of customer groups based on the speed of the links. For example, there may be two speed groups, one of which includes a client connected to the server by a link (or effective link) with a maximum possible speed of 64 Kbps and the other of which includes a client connected to the server by a link (or effective link) with a maximum possible speed of 1024 Kbps. The second group, therefore, is much faster than the first. Whether a particular receiver belongs to one speed group or another affects the transmission of data to that receiver. During the initial data transmission pass according to the invention, the server will send all the frames to each of the receivers of the second group, of higher speed, and to each of the receivers of the first group, slower, only I will send every 1/16 of every frame sent to the second group. This means that, after the first pass, the server has sent all the frames to the receivers of the second group, but only one sixteenth of the total number of frames has been sent to the first group. The remaining part of the frames not yet sent to the first group (ie 15/16 of the frames) are then sent to the receivers of the first group in subsequent passes. The fact is that, once the server knows the capacity of each member of a group, it can tailor the data transmission to take advantage of the higher capacity links and not slow down the data transmission to them. Collection of Negative Receipts

As previously mentioned, the number of clients that can receive a file according to the invention can be of the order of several thousand. Thus, the number of entries in the client status list maintained by the server can also amount to several thousand. The transmission of files according to the invention can be made more scalable. For example, it can be scaled to send a file to millions of receivers / clients, instead of thousands of receivers / clients. In a preferred embodiment, these clients or receivers are members of a multicast client group.

ES 2

The scalability feature helps avoid a potential problem when large numbers of clients return negative acknowledgments to the file sender (for example, the server) and effectively throttle the file sender with more negative acknowledgments than it can deal with. a reasonable period of time. This causes the sender's behavior to deteriorate as the sender needs to spend a significant amount of time receiving and handling negative acknowledgments and cannot attend to other tasks. This also clogs the line back to the sender, which is jammed with traffic from these negative acknowledgments.

The solution to the problem lies in the “collection of negative receipts” which, in turn, allows to dramatically increase the number of receiving clients, which goes from thousands to millions, without clogging the file sender / server 20. With this feature In the collection, certain clients or other network nodes acted as "repeater points" and collected negative acknowledgments to blocks, from other clients. In a preferred embodiment, these repeat points (RPs) are routers. Referring to Fig. 7, five RPs are illustrated in the US and the lines leading from each RP are representative of one or more of the clients connected to that RP. For example, RP 100 has 1200 customers below it, RP 102 has 900 customers, RP 104 has 100 customers, RP 106 has 800 customers, and

011 T3 28 RP 108 has 500 clients. The server or source 20 is located elsewhere in the US The RP 100 collects all negative acknowledgments to blocks from (eg 1200) associated or connected clients. The other RP 102, 104, 106, 108 do the same with their associated clients. Each RP, once it has collected all the negative block acknowledgments from all its associated clients, sends to the server 20, or to another RP in the chain leading to the server 20, only an acknowledgment message. That single message includes all negative acknowledgments from all clients associated with that RP. When the server 20 eventually receives these negative acknowledgment messages to collected blocks from the RPs, it sends back, in the next pass, all the frames for which a negative acknowledgment has been issued. RPs are responsible for receiving those subsequent pass frames and forwarding them to the appropriate clients or another RP in the chain which then forwarded them to the appropriate clients or another RP in the chain, etc.

Variations, modifications, and other practical executions, in addition to those described in this specification, will occur to those of ordinary skill in the art, without thereby departing from the scope of the invention, as claimed. Accordingly, the invention is not to be defined by the foregoing illustrative description, but by the following claims.