Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing
Reexamination Certificate
1999-03-23
2003-09-23
Caldwell, Andrew (Department: 2157)
Electrical computers and digital processing systems: multicomput
Computer-to-computer session/connection establishing
C709S219000, C709S204000
Reexamination Certificate
active
06625652
ABSTRACT:
TECHNICAL FIELD
This invention generally relates to data transmission and to efficient and reliable multicast transmissions of files from a server to clients.
BACKGROUND INFORMATION
Computer networks, such as wide area networks (WANs) using the TCP/IP protocol suite, can provide unicast, multicast, and broadcast services to allow communication between network participants such as a server node and one or more client nodes. IP supports the sending of data to broadcast addresses, which are delivered to all hosts on the network or subnetwork at the expense of creating traffic over the total network. IP also supports multicast technology to communicate over a computer network. The term “broadcast” refers to a server node sending information to all of the client nodes connected to the network. The term “multicast” refers to a server node sending information to a subset of all of the client nodes connected to the network.
Some information providers provide information electronically by broadcasting or multicasting the information from a server node at a central location to one or more client nodes at remote customer locations via a computer network to which the server and the clients are coupled. Computer networks and systems use several different protocols to accomplish reliable data distribution. One common protocol suite in use in computer networks is TCP/IP, which is the protocol presently used with the Internet. TCP stands for Transmission Control Protocol, and IP stands for Internet Protocol.
Conventional TCP/IP reliable file transfer protocols support point-to-point (i.e., unicast) file distribution only. That is, packets are sent to each address in turn. In contrast, reliable multicast data transfer allows packets to be sent to several host recipients simultaneously, thereby saving bandwidth. A multicast group is the group of host recipients that simultaneously receive data via the reliable multicast data transfer. For example, with multicast, a data packet is sent to a participating router, and the router handles local distribution. Typical applications for reliable multicast data distribution include electronic software distribution, transmission of critical information to field offices, distribution of multimedia information to local servers, replication of web servers to the edges of networks for improved performance, and providing subscription based “push” information delivery to receivers who have signed up for a particular information service.
IP multicast groups are dynamic and can be set up and torn down in seconds. IP multicast session setup protocols that have been standardized support two basic group models for two basic multicast applications. One group model is the conferencing model, in which a host is “invited” to join a conference, and a many to many multicast group is set up. This conference can be a video conference, a data conference, or some other type of conference. A second group model is the broadcast model. This is analogous to television broadcast, where events and their times and “channels” are continuously broadcast over a particular channel, much as is done on many cable TV systems. Any receiver seeing an event may join the group and receive the information, in a manner analogous to tuning a TV receiver to the channel desired. Both of these models assume that anyone can access the groups with no restriction. There is no knowledge of group membership in the one to many group model, and there may not be knowledge in the conference model.
Neither of these group models satisfies the needs of commercial organizations that often want to restrict group membership and have central control of the group. Additionally, sessions are not always scheduled ahead of time, but a sender may want to set up a session at any time in an asynchronous manner.
SUMMARY OF THE INVENTION
Control of groups and their membership can be accomplished by establishing open and closed groups. Open groups permit anyone learning of the group to join, sometimes subject to certain limits, and closed groups define a known list of group members at the sender and direct receivers to join the group for the duration of the session. One issue is the setup and maintenance of the groups of receivers that receive information using multicast. A host list can be used to list all the group members, and this host list would accompany the information sent to the group members to direct them to join.
During setup of a group, host lists are sent to direct particular receivers to join a group. The host lists can also be sent during confirmation of group registration and during confirmation of data transmission. When groups reach sizes having thousands of members, however, the host list becomes quite large and takes more time than desirable (e.g., 15 minutes) for setup or confirmation. For example, for a group of 10,000, the host list could require 60 packets or more each time it is sent, and the host list might be sent multiple times as more registration messages are received. Consequently, this represents a significant scaling problem as groups become large. As group sizes increase, the large size of the list translates into unacceptably high network traffic required to transmit the large list and generally a waste of network capacity on an administrative task.
To make registration and confirmation of groups, and confirmation of delivery in reliable multicast data transfer sessions more scaleable, particularly for large groups, the host list is reduced at every sending according to the invention. By reducing the size of the host list, the network is not “clogged” with administrative messages, and session setup or delivery confirmation is accomplished quicker.
In one aspect, the invention features a method for managing a list of receivers, comprising (a) creating a message that includes a list of one or more receivers; (b) sending the message over a network; (c) receiving over the network one or more replies from one or more of the receivers; (d) identifying each receiver for which one of the replies was received and establishing another message that includes the list with the identified receivers; (e) sending the message established in step (d) over the network; (f) creating a modified list by removing the identified receivers from the list; and (g) if there are one or more receivers on the modified list, repeating steps (c), (d), (e), (f), and (g) using the modified list as the list.
Embodiments according to this aspect of the invention can include the following features. A confirmed list that includes all of the identified receivers can be established and data can be transferred over the network to the identified receivers on the confirmed list. Also, step (g) can be repeated until a predetermined condition occurs, such as a message limit is reached or a time limit is reached.
In another aspect, the invention provides a method of managing a list of receivers to establish a group list, comprising (a) receiving over a network one or more replies from one or more receivers; (b) identifying each receiver for which one of the replies was received in step (a); (c) adding the receivers identified in step (b) to a group list; (d) sending a message over the network, the message including a list of only the identified receivers added to the group list in step (c); and (e) repeating steps (a), (b), (c), (d), and (e) until a predetermined condition exists.
In still another aspect, the invention features a method of confirming the transfer and receipt over a network of data sent to a group of receivers, comprising (a) receiving over the network one or more confirmations from one or more receivers, each of the confirmations being an indication that one of the receivers has successfully received all of the data sent to that receiver over the network; (b) identifying each receiver of the group for which one of the confirmations was received in step (a); (c) sending a message over the network, the message including a list of only the receivers identified in step (b); and (d) repeating steps (a), (b), (c), and (d) u
McKenna Kevin
Miller C. Kenneth
White Marc
Caldwell Andrew
The Fantastic Corporation
LandOfFree
System and method for host list pruning does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for host list pruning, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for host list pruning will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3047919