Systems and methods for seamless host migration

System and method for smooth host movement

The present invention generally relates to the Internet. More specifically, the present invention relates to data dissemination in the network.

This application claims the priority right of U.S. Provisional Patent Application No. 60/997,918 filed on October 5, 2007, entitled "Systems and Methods for Seamless Host Migration". The full text is incorporated herein by reference.

The application of the present invention is related to the US Patent Application No. 10/211,128 filed on July 31, 2002, entitled "Dynamic Player Management". The full text of the case is incorporated herein by reference. This application is further related to the US Patent Application No. 10/359,359 filed on February 4, 2003, entitled "Multi-User Application Program Interface". The full text of the case is incorporated by reference. Incorporated into this article.

A network can include a set of computing devices connected together by a communication system. 1. A computer in the network can communicate with other computers in the network, exchange data, and share resources. Examples of networks include a personal area network (PAN), local area network (LAN), and wide area network (WAN).

Various network configurations are known in this technology. The traditional master-slave network shown in FIG. 1A includes a host 110 connected to clients 120A-D. The host 110 establishes the network session 130, controls the network session and controls how many clients can join the network session 130 and once the clients 120A-D join the network session 130, they will each other How does it interact. Since the host 110 usually has a large amount of bandwidth and processing capabilities, the host 110 can manage and distribute data to all clients 120A-D in the network session 130 and process and distribute data from the network session 130. 120A-D data of all clients. In this type of configuration, data from a specific client (for example, client 120D) can be distributed to other clients (for example, client 120A-C) via the host 110. For example, the client 120D can send data to the host 110. When another client, such as client 120A, requests the data, the host 110 transmits the data to the client 120A.

Since a client is connected to the host, the client can only request the data it needs (via the host) so that the client does not need to process other unnecessary data. This type of configuration is common among clients that cannot effectively process all the data exchanged during a network session. These clients can request a host to process and distribute the data.

One of the disadvantages of allowing the host to process and distribute data during a network session is that data may be lost when there is a connectivity problem that affects the communication between the host and any of the session clients. In such cases, data from a specific client cannot be sent to the host. The data is also not available to other clients in the network. For example, the client 120D can suddenly disconnect from the host 110. The information that the client 120D has sent to the host 110 does not reach the host 110, and therefore the information will not be transmitted to the other clients of the network (for example, the client 120A-C). The missing information may cause the network session 130 to be interrupted, which may affect the operation of other clients. This is especially true in the case of interactive online game competitions.

Therefore, an improved system and method for network data dissemination are needed in the present technology of raising questions about the connectivity of the network session and managing the uninterrupted data exchange during one of the sessions.

The system and method provided by the present invention for maintaining the distribution of network data will allow a network session to withstand the interrupted communication between the host and the client without significant data loss. The host function is smoothly migrated to a client without major data loss. These embodiments of the present invention provide one or more clients as backup hosts for the network session. When other clients send data to the host, they can also send the data to one or more backup hosts. For example, a client that sends data to the host cannot receive the data approval within a certain period of time. The client can re-send the data to the host and send the data to the backup host.

Various embodiments of the present invention include methods for network data distribution. Such methods include: connecting a host to a number of clients; determining whether a client can act as a backup host; if so, sending confirmation information that allows the client to act as the backup host to the client. Acting as the backup host includes receiving information from other clients when they cannot communicate with the host. In some embodiments of the present invention, the method further provides for indicating that the communication between a host and a client is interrupted and for terminating the connection between the host and the specific client.

Various embodiments of the present invention include systems for network data distribution. Such systems include a host, a first client that can act as a backup host, and a second user that can transmit data to the first client when the communication between the host and the second client is interrupted end. In some embodiments of the present invention, the second client can act as a backup host. Some embodiments of the invention may include a plurality of clients, each of which is configured to act as a backup host client.

The embodiments of the present invention can also provide a host system used in a network distribution system. Such a host system may include: an approval module that recognizes client communication upon receipt; a negotiation module that negotiates whether a specific client can serve as a backup host; and delivers an application that provides host information to the user A backup application module at the end. Some embodiments of the present invention further include a host information database and a timer.

Some embodiments of the present invention include computer storage media and instructions for network data distribution. Such commands can be provided to connect a host to a plurality of clients, negotiate with a client that can act as a backup host, and send host information to the client so that it can start to act as a backup host.

The present invention includes systems and methods for network data dissemination. The embodiments of the present invention may allow host migration to occur smoothly. If the network between a host and a client is interrupted, a network session can continue without causing significant loss of data. A host in a network session can be connected to many clients. One (or more) of these clients can act as a backup host. The feasibility of backup is negotiated with a client and the host information is sent to the client, which can thus act as a backup host. The backup host can then connect with other clients during the network session and receive data from other clients. Therefore, if the communication between the host and a specific client is interrupted, the specific client can send its data to the backup host, allowing the network session to continue without any data loss.

The elements identified throughout are exemplary and may include various alternatives, equivalents, or derivatives thereof. Various combinations of hardware, software, and computer executable commands can be used. Program modules and engines can include routines, programs, objects, components, and data structures that achieve special task performance when executed by a processor, and they can be general or specific applications. The computer-executable instructions and associated data structures stored in a computer-readable medium represent examples of the steps used to execute the methods and/or the implementation of the specific system configuration programming methods disclosed herein.

In the master-slave network configuration illustrated in FIG. 1A and detailed above, each client does not need to process all data during a network session. On the contrary, each client only receives and processes the data required by the client to participate in the network session. The inability of some clients to process all the data effectively is due to, for example, lack of bandwidth or lack of processing power. However, some clients do have the ability to process all data during a web session. These specific clients can be used as backup hosts to store some or all of the data from the network session.

In contrast to the system configuration of FIG. 1A, FIG. 1B illustrates an exemplary system with a backup host (client 160A) for network data distribution. A backup host can be any client that can perform some or all of the functions of a host during a network session. When the host 140 of the network session 150 cannot or does not perform, some or all of the host's responsibilities can be migrated to a backup host. In order to be qualified as a backup host, the candidate host (client) needs to demonstrate the feasibility of backup. Demonstrating the feasibility of backup may involve meeting one or more of the following requirements, such as bandwidth, processing power, memory, hardware or software configuration, or quality of service. The feasibility of a client's backup can be determined through negotiation with the host.

After completing the negotiation about and confirming the feasibility of the backup, the host information can be transmitted between the host 140 and the client 160A via the network session 150. The host information may include the network name, Internet Protocol (IP) addresses of the clients in the network, firewall information, and specific responsibilities information on whether the client 160A needs to take over certain host responsibilities. Using the host information, the client 160A can act as a backup host in the event that one or more connections between the host 140 and other clients 160B-D are interrupted. For example, if the client 160B is not connected to the host 140, the client 160B can transmit data to the client 160A as shown in the content of FIG. 3A and FIG. 3B. By migrating the responsibility of the host from the host 140 to the client 160A, the information from the client 160B will not be completely lost to the network session 150.

In some embodiments, more than one client can act as a backup host. Figure 1C illustrates an exemplary system with multiple backup hosts (clients 190A-D) for network data distribution. If the original host 170 becomes unavailable, each client in the network session 180 of FIG. 1C can be responsible for a specific backup host. For example, the client 190A may be responsible for scoring and 190B may be responsible for state changes in the game environment. The client 190C may be responsible for the admission criteria (for example, who can participate in the game) and 190D may be responsible for the conversation functionality. Alternatively, the client 190A can be responsible for all the above-mentioned tasks and if the client 190A subsequently fails, the client 190B-D takes over these tasks.

FIG. 2 illustrates an exemplary configuration 200 of a computing device that provides smooth host migration in a network data distribution system. The host 200, which can serve as a central communication transfer center, can be a computing device, such as a server. Due to the fact that a client can become a backup host at some time, a computing device usually reserved as a client operation can also display some or all of the configuration of the host 200. The host 200 may include a network interface 210, an authorization module 220, a negotiation module 230, a host information database 240, a backup application module 250, a polling module 260, and a timer 270.

As used in the present invention, a module (or application) is a set of routines that perform various system-level functions. A module can be dynamically loaded and unloaded by hardware and device drivers as required. The modular software components described herein can also be incorporated as part of a larger software platform or integrated as part of an application-specific component.

The network interface 210 can be any of a variety of hardware and/or software components configured to allow communication between the host and other computing devices during the network session. The network interface 210 may include components for communicating via a wired, wireless, and/or Internet-based communication network.

The authorization module 220 allows to verify the information received by the host 200 and transmitted by a client. When the host 200 receives information from a client via the network interface 210, the approval module 220 can send an acknowledgement (ACK) to the client that sent the information. For example, if a client sends information about changes in game state data to the host 200, the authorization module 220 may send an ACK response to the sending client, indicating that the information is received. The ACK response sent by the authorization module 220 may further include the following instructions: what information was received, how much of the information was received, and/or whether any of the information is corrupted or incomplete.

Failure to receive an ACK regarding a specific data transmission via the transmitting client may indicate that the host 200 has never received the data transmission. The host 200 not receiving the data transfer (or a part thereof) may indicate a connection between the host 200 and the client sending the data transfer or a problem in the host 200 or itself. If a certain number of data transfers fail to receive an ACK response from the host 200, the transfer client can invoke a migration operation, so some or all of the host functionality is migrated to a backup host.

The negotiation module 230 negotiates the backup feasibility of a client based on various parameters. For example, a feasible backup host/candidate client may be required to have a certain amount of available bandwidth. The bandwidth of the client must be sufficient to allow the client to manage all data during the network session. The feasibility of backup may require the client to comply with a variety of quality of service standards, which are related to such things as ping rate, packet loss, available memory, processor speed, and so on.

The negotiation module 230 can further determine whether the candidate client can connect to each of the other clients in the network. A viable backup host must be able to connect to each of the other clients in the network and receive information from each of the other clients in the network. The parameters used for the feasibility of backup can be determined according to the type of network session. For example, due to the number of state changes that can occur in a game environment, a certain game network session may require a certain amount of bandwidth and processor speed for backup feasibility. Less complex transactions (such as simple file transfers) may require less bandwidth and/or processing power.

The negotiation module 230 can be configured to negotiate backup feasibility with multiple clients to generate a series of backup hosts. Alternatively, the negotiation module 230 can be configured to assign backup responsibilities for special tasks among a group of clients. By providing a series of backup hosts, it is possible to smoothly migrate escrow duties from one host to a first backup host, to a second backup host, and so on when the network or host/client conditions permit. The order of backup host duties and/or specific duties may be assigned based on the order in which the clients are connected to the host. Alternatively, the order and/or responsibilities may be based on other factors, such as bandwidth or service quality.

The host information database 240 can store information about the host, the clients, or the network session. The information stored in the host information database 240 may allow a computing device to perform specific host duties, such as connecting to other clients during a network session. Such host information may include the network name, the Internet Protocol (IP) addresses of the clients in the network, and firewall information. When an event such as a client disconnected from the network or a new client joins the network occurs, the host information database 240 can be updated. For example, the IP addresses of the new clients will need to be added to the host information database 240.

The backup application module 250 works with the host information database 240 to generate an application that can be downloaded, installed, and executed on the client. This application provides a client-specific operational functionality, which can request the client so that the client can act as a backup host in addition to satisfying basic feasibility requirements. The application can configure the client to connect to other clients in the network session and exchange data with other clients in the network.

The selective polling module 260 can be configured to poll all such clients in a network session. The polling module 260 can be used to poll the connectivity of the clients. Polling connectivity can include: sending small data packets to each client during the network session, receiving replies/acknowledgements from the clients that have received the data packets, and determining that their clients have 200 connections with the host. The problem of communication.

The selective polling module 260 can automatically poll these clients at regular intervals. When certain events occur, such as when a new client joins the network session or a communication interruption (for example, a client cannot recognize the data sent by the host 200), the polling module 260 can also be used. It is configured to poll the client. The polling operation of the polling module 260 can be similar to a periodic heartbeat described in US Patent Publication No. 2003-0204566 called "Multi-User Application Program Interface". The full text is previously incorporated herein by reference.

The host 200 can also include a timer 270. The timer 270 can be configured to measure how much time has elapsed after an event. The host 200 can use the timer 270 to determine the time between the data transmission generated by the polling module 260 and the approval of the data transmission. Such information can be used to determine whether to terminate the connection with a particular client. If the host 200 fails to receive an approval or polling response from a specific client after a period of time as measured by the timer 270, the host 200 can terminate the connection with the client.

The application program generated by the backup application program module 250 may further include a certain functionality similar to the functionality of the polling module 260 and the timer 270. Unlike the host 200 that can seek to determine whether to evict a specific client from the network session, this "heartbeat" functionality can be used by a client that has been designated as a backup host to determine when the host 200 is no longer able to Or it has been unable to complete certain host duties in succession. The inability or inability of a host 200 to perform certain duties can be indicated by the continuous lack of receiving an ACK or heartbeat generated by the authorization module 220.

FIG. 3A illustrates an implementation of an exemplary system 300 for network data distribution. The host 200 is connected to a plurality of client terminals 310A-D. The client 310A has successfully negotiated the feasibility of backup with the host 200 and received host information via the connection 300. Using the host information, the client 310A connects to other clients in the network, that is, the clients 310B-D. The connection 330 allows the client 310B-D to directly (ie, not via the host 200) communicate with the client 310A. If it is difficult for each client to transmit the data to the host 200, the client 310B-D can use the connection 330 to exchange data with the client 310A. The client 310B-D can also automatically send data to the client 310A, regardless of the difficulty of sending any data to the host 200.

Figure 3B illustrates an alternative implementation of an exemplary system for network data distribution. In particular, FIG. 3B illustrates an exemplary system for network data distribution in which the communication between a host 200 and a client 310D is interrupted. In particular, the icon data transmission 340 between the host 200 and the client 310D is shown to be unsuccessful. Although the client 310D attempts to send a data transmission 340 to the host 200, a faulty connection prevents the host 200 from receiving the transmission.

Since the client 310A is a backup host for the web session, the client 310D can directly send the same data intended to the host 200 to the client 310A via a backup data transfer 350 (ie, not via the host 200). The client 310A can then use a data transmission 360 to send the data to the host 200. In this particular embodiment, the client 310A acts as a proxy server between the client 310D and the host 200 due to the faulty connection between the separate client 310D and the host 200. Although received by the client 310A, the host 200 can thus distribute the data from the client 310D to the client 310B and 310C. Alternatively, it is different from the connection between the client 310D and the host 200 that is only defective. For example, if the host 200 cannot maintain the responsibility of the host, the client 310A can send the data to the client 310B or 310C.

Since the communication between the host 200 and the client 310D has been interrupted, the client 310D must obtain the session information through the client 310A. Compared with the host 200 and the client 310D, the client 310A not only represents any computing device requesting data, but also serves as a medium for both receiving and transmitting data.

FIG. 4 is a flowchart depicting an exemplary method 400 for network data distribution. The steps (and their order) identified in FIG. 4 are exemplary and may include various alternatives, equivalents, or derivatives thereof (including but not limited to their execution order). The steps of the process in Figure 4 (and its various alternatives) can be recorded in a machine-readable or computer-readable storage medium (for example, an optical disc, a memory card, or a hard disk) with instructions executed by a processor. Disk) in the hardware or software.

In step 410, a host (for example, the host 200) establishes a network session. The host can set certain parameters for various aspects of who can join the network session and how the network session will continue. A host can create a private network session that only specific clients or invited clients can join. Alternatively, the host can establish a network session open to the public and any client can join.

In step 420, multiple clients join the network session by connecting to the host. If the host has set certain parameters about who can join the network session, the clients must meet these parameters before being allowed to connect with the host or participate in the network session.

In step 430, the feasibility of the backup is negotiated through the negotiation module 220 in FIG. 2. One or more clients may be viable backup hosts with the capacity and resources to act as a backup host. The feasibility of backup can be negotiated as soon as a client joins the network session. Various aspects of backup feasibility (including bandwidth and service quality) can be evaluated to determine whether a specific client can act as a backup host. Depending on the requirements of the negotiation module 220, there may be one, more than one, or no viable backup host among the clients during the network session. You can also assign backup responsibilities.

In step 440, the backup responsibilities are assigned. Since multiple clients are viable backup hosts, backup responsibilities must be assigned among these clients in terms of sequence and/or specific responsibilities. During the network session, these clients can send their data via broadcast or other communications to the first viable backup host or the first deemed backup host that can be identified by the host, as in US Patent Publication No. 2003-0217135 The number is named "Dynamic Player Management (Dynamic Player Management)" as an example, the full text of the case has previously been incorporated into this article by reference. If the first viable backup host cannot or becomes unable to act as a backup host, other clients can send their data to the second viable backup host to join the network session. The need to communicate with an auxiliary backup host can be indicated using the "Dynamic Player Management" application as disclosed in this article and/or the aforementioned.

In step 450, it is determined whether a specific client can connect to each of the other clients in the network session. A backup host needs to be able to connect to every and all other clients during the session. If a first client cannot connect with a second client, the first client cannot act as a backup host for the network session. For example, the first client may have a firewall problem that prevents the first client from establishing certain types of connections. If a potential backup host cannot connect to another client for any reason, the method can return to step 440 and re-assign backup responsibilities.

Once it has been determined that a client is a viable backup host and can be connected to all other clients in the network session, the method proceeds to step 460. In step 460, the backup information is downloaded to a feasible backup host. By providing the backup information to a backup host, the host can exit the network, and the backup host can provide any information required by other clients during the network session. The backup information can be provided as part of the download and installation of an application that promotes smooth host transition as discussed in the content of the backup application module 250 of FIG. 2.

In step 470, network data distribution can be started. As shown in Figure 3A, the data transfer can occur between a host and a client. As further illustrated in Figure 3B, data transfer can also occur between two clients, from a client with host connectivity issues to a client that can act as a backup host. In addition, the backup host can forward the data to the host or directly to other clients as required. Regardless of the connection via which the data must be delivered in a split process, the data is provided to the computing devices that need the data.

Although the present invention has been described with reference to exemplary embodiments, those skilled in the art should understand that various changes can be made and equivalents can be substituted for its elements without departing from the true spirit and scope of the present invention. In addition, various modifications can be made without departing from the basic teachings of the present invention. Various alternatives can be used to implement the various methodologies described herein and various methods can be used to achieve certain results in the aforementioned system.

<p>110. . . Host</p><p>120A. . . user terminal</p><p>120B. . . user terminal</p><p>120C. . . user terminal</p><p>120D. . . user terminal</p><p>130. . . Web session</p><p>140. . . Host</p><p>150. . . Web session</p><p>160A. . . user terminal</p><p>160B. . . user terminal</p><p>160C. . . user terminal</p><p>160D. . . user terminal</p><p>170. . . Host</p><p>180. . . Web session</p><p>190A. . . user terminal</p><p>190B. . . user terminal</p><p>190C. . . user terminal</p><p>190D. . . user terminal</p><p>200. . . Host</p><p>210. . . Network interface</p><p>220. . . Approved Module</p><p>230. . . Negotiation module</p><p>240. . . Host information database</p><p>250. . . Backup application module</p><p>260. . . Polling module</p><p>270. . . Timer</p><p>300. . . Illustrative system</p><p>310A. . . user terminal</p><p>310B. . . user terminal</p><p>310C. . . user terminal</p><p>310D. . . user terminal</p><p>320. . . connect</p><p>330. . . connect</p><p>340. . . Data transfer</p><p>350. . . Backup data transfer</p><p>360. . . connect</p>

Figure 1A illustrates a master-slave network configuration that is well known in the art.

Figure 1B illustrates an exemplary system with a backup host for network data distribution.

Figure 1C illustrates an exemplary system with multiple backup hosts for network data distribution.

Figure 2 illustrates an exemplary configuration for a computing device that provides smooth host migration in a network data distribution system.

Figure 3A illustrates an implementation of an exemplary system for network data distribution.

Figure 3B illustrates an alternative implementation of an exemplary system for network data distribution.

Figure 4 depicts an exemplary method for network data distribution.