Systems and methods for seamless host migration

This application claims the priority benefit of US Provisional Patent Application No. 60 / 997,918, entitled "Systems and Methods for Seamless Host Migration," filed October 5, 2007. This disclosure is incorporated herein by reference.

This application is related to US Patent Application No. 10 / 21,128, entitled "Dynamic Player Management," filed July 31, 2002, the disclosure of which is incorporated herein by reference. In addition, this application is related to US Patent Application No. 10 / 359,359, entitled "Multi-User Application Program Interface," filed February 4, 2003, the disclosure of which is incorporated herein by reference. ..

The present invention generally relates to networks. More specifically, the present invention relates to data distribution in a network.

A network can include a group of computing devices connected to each other by a communication system. Computers in the network can communicate with other computers in the network, exchange data, and share resources. Examples of networks include personal area networks (PANs), local area networks (LANs), and wide area networks (WANs).

Various network configurations are known in the art. The traditional client-server network shown in Figure 1A includes hosts 110 connected to clients 120A-D. Host 110 establishes network session 130, controls how many clients participate in and how they participate in network session 130, and controls how clients interact with each other after clients 120A-D join network session 130. .. Host 110 generally has wide bandwidth and high processing power, allowing host 110 to manage and distribute data with all clients 120A-D within network session 130. In such a configuration, data from a particular client (eg, client 120D) is distributed through host 110 to other clients (eg, client 120A-C). For example, client 120D sends data to host 110. When another client, such as client 120A, requests data, host 110 sends that data to client 120A.

By connecting to the host, the client can request only the data it needs (through the host), so the client does not have to manage unnecessary data. Such a configuration may be common among clients who do not have the ability to efficiently manage all the data exchanged within a network session. These clients require hosts to manage and distribute the data.

The disadvantage of letting the host manage and distribute the data within a network session is that data can be lost in the event of a connection problem that affects communication between the host and any one of the session clients. That is. In this case, the data from the specific client cannot be sent to the host. That data will also be unavailable to other clients in the network. For example, suppose client 120D is suddenly disconnected from host 110. The information that client 120D should have sent to host 110 does not reach host 110, and as a result, that information cannot be sent to the rest of the network (ie, client 120A-C). Lost information can cause confusion in network session 130, which can affect the behavior of other clients. This is especially true for interactive network games.

<p> Therefore, there is a need in the art for improved network data distribution systems and methods that solve the problems associated with network session connectivity and maintain uninterrupted data exchange within the session.</p>

<p> The systems and methods of the present invention provide the maintenance of network data distribution that allows a network session to overcome interruptions in communication between a host and a client without data loss. Host functionality migrates to clients seamlessly and without significant data loss. Embodiments of the invention include one or more clients that act as backup hosts for network sessions. When another client sends data to a host, it also sends that data to one or more backup hosts. For example, a client that sends data to a host may not receive confirmation of the data within a given time period. The client resends the data to the host and also sends the data to the backup host.</p><p> Various embodiments of the present invention include network data distribution methods. This method connects the host to the client, determines if the client can act as a backup host, and if so, sends certain information to the client that allows it to act as a backup host. Including. Acting as a backup host involves receiving information from other clients when they are unable to communicate with the host. In some embodiments of the invention, the method further comprises disrupting communication between the host and the client and suspending the connection between the host and its particular client.</p><p> Various embodiments of the present invention include a network data distribution system. The system includes a host, a first client that can act as a backup host, and a second client that can send data to the first client when communication between the host and the second client is interrupted. In some embodiments of the invention, the second client can also function as a backup host. Some embodiments of the present invention may include multiple clients, each configured to act as a backup host.</p><p> Host systems used in network distribution systems are also provided in embodiments of the present invention. This host system consists of a confirmation module that confirms client communication when receiving, a negotiation module that negotiates whether a specific client can function as a backup host, and a backup application module that distributes applications that provide host information to clients. including. Some embodiments of the present invention further include a host information database and a timer.</p><p> Some embodiments of the present invention include computer recording media and instructions for network data distribution. This instruction involves connecting the host to the client, negotiating with a client that can act as a backup host, and sending host information to the client so that the client can start acting as a backup host.</p>

The present invention includes network data distribution systems and methods. According to the embodiment of the present invention, host migration can be seamlessly generated. If communication between the host and the client is interrupted, the network session can be continued without significant data loss. The host of the network session may be connected to multiple clients. One (or more) of these clients may be able to act as a backup host. Backup feasibility is negotiated with the client and host information is sent to the client. This client can subsequently act as a backup host. The backup host may subsequently connect to other clients in the network session and receive data from the other clients. If the communication between the host and the particular client is subsequently interrupted, the particular client can send its data to the backup host, which allows the network session to continue without data loss.

The components identified throughout are exemplary and include various alternatives, equivalents or derivatives. Various combinations of hardware, software, and computer-executable instructions are available. Program modules and engines may include routines, programs, objects, components and data structures that perform specific tasks when executed by a processor. The processor may be general purpose or application specific. Computer-executable instructions and associated data structures stored on computer-readable media are specific systems that perform the steps of the methods disclosed herein and / or are disclosed herein. It shows an example of programming means for implementing a configuration.

In the client-server network configuration shown in Figure 1A and detailed above, each client does not have to process all the data in the network session. Instead, each client receives only the data it needs to join a network session and processes it. Some clients are unable to manage all of their data efficiently, for example due to lack of bandwidth or lack of processing power. However, some clients have the ability to manage all the data in a network session. These particular clients can act as backup hosts that store some or all of the data obtained from the network session.

Compared to the system configuration of FIG. 1A, FIG. 1B shows an exemplary system for network data distribution with one backup host, client 160A. The backup host may be any client capable of performing some or all of the host's functions in a network session. When host 140 in network session 150 is infeasible or non-executable, some or all of the hosting responsibilities can be transferred to the backup host. In order to qualify as a backup host, a candidate host (client) that clearly indicates the feasibility of backup is required. Determining backup viability includes, for example, satisfying one or more requirements regarding bandwidth, processing power, memory, hardware or software configuration, or quality of service. The backup feasibility of the client may be determined through negotiations with the host.

Host information is sent between host 140 and client 160A through network session 150 after negotiations related to and confirming backup feasibility are complete. Host information can include the network name, the client's Internet Protocol (IP) address within the network, firewall information, and information about specific responsibilities if the client 160A needs to take over the host responsibilities. The host information allows the client 160A to act as a backup host if one or more connections between the host 140 and the other clients 160B-D are interrupted. For example, if client 160B is disconnected from host 140, client 160B may transfer data to client 160A, as shown in FIGS. 3A and 3B. By migrating host responsibility from host 140 to client 160A, information from client 160B is not completely lost in network session 150.

In some embodiments, two or more clients may be able to function as backup hosts. Figure 1C shows an exemplary system for network data distribution with several backup hosts, Client 190A-D. Each client in network session 180 in Figure 1C can be involved in a particular backup host responsibility if the original host 170 becomes unavailable. For example, client 190A can be responsible for recording scores, while client 190B can be responsible for changing circumstances within the gaming environment. Client 190C is responsible for participation criteria (eg, who can participate in the game) and Client 190D is responsible for the chat function. Alternatively, client 190A may be responsible for all of the above tasks, and other clients 190B-D may take over those tasks if client 190A subsequently fails.

Figure 2 shows an example 200 of a computing device configuration that provides seamless host migration in a network data distribution system. The host 200 can function as a central communication hub in the network and is a computing device such as a server. The computing device typically provided for client operation may have some or all of the host 200's configuration, which means that at some point the client may be the backup host. Because of the facts. The host 200 can include a network interface 210, a confirmation 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 referred to in the present invention, a module (or application) is a set of routines that perform various system-level functions. Modules are dynamically loaded and unloaded by hardware and device drivers as needed. The modular software components described herein may be integrated as part of a larger software platform or as part of an application-specific component.

The network interface 210 may be any of a variety of hardware and / or software components configured to allow communication between the host and other computing devices within the network. The network interface 210 may include components that communicate over wired, wireless, and / or Internet-based communication networks.

The confirmation module 220 makes it possible to confirm that the information sent by the client has been received by the host 200. When the host 200 receives information from the client through the network interface 210, the acknowledgment module 220 can send an acknowledgment (ACK) to the client that sent the information. For example, if the client sends information related to the change in game state data to the host 200, the acknowledgment module 220 can send an acknowledgment to the sending client indicating that the information has been received. .. The ACK response sent by the acknowledgment module 220 shall further include an indication of the content of the information received and the amount of that information, and / or an indication to that effect if the information is corrupted or incomplete. Can be done.

Not receiving an ACK for a particular data transmission by the sending client means that the data transmission has not been received by the host 200. The fact that host 200 is not receiving data transmission (or part of it) indicates that there is a problem with the connection between host 200 and the client that sent the data, or that there is a problem with host 200 itself. There is. If a certain number of data transmissions have not received an ACK response from host 200, the sending client may perform a migration operation, which migrates some or all of the host functionality to the backup host. ..

The negotiation module 230 negotiates the backup feasibility of the client based on various parameters. For example, a viable backup host / client candidate may need to have a certain amount of available bandwidth. The client bandwidth needs to be sufficient for the client to manage all of the data in the network session. Backup viability may require the client to comply with the quality of the various service standards associated with it. For example, ping rate, packet loss, available memory, processor speed, etc.

Negotiation module 230 may determine if a potential client can connect to each of the other clients in the network. The executable backup host must be able to connect to and receive information from each of the other clients in the network. Backup viability parameters may be determined by the type of network session. For example, a particular game network session may require a certain amount of bandwidth and processor speed to be able to perform backups, as many state changes can occur within the gaming environment. Less complex transactions, such as simple file transfers, require less bandwidth and / or processing power.

The negotiation module 230 may be configured to negotiate backup feasibility with multiple clients. This gives rise to a series of backup hosts. Alternatively, the negotiation module 230 may be configured to assign backup responsibilities for specific tasks between groups of clients. By providing a set of backup hosts, seamlessly shift hosting obligations from host to first backup host, second backup host, and so on, when network or host / client conditions guarantee. Can be done. The order of backup host responsibilities and / or specific responsibilities may be assigned based on the order in which clients are connected to the host. Alternatively, the order and / or responsibilities may be determined based on other factors such as bandwidth and quality of service.

The host information database 240 can store information related to a host, client, or network session. The information stored in the hosting information database 240 allows computing devices to fulfill certain hosting obligations, such as connecting to other clients within a network session. Such host information may include network names, Internet Protocol (IP) addresses of clients in the network, and firewall information. The host information database 240 may be updated in the event of an event such as a client disconnecting from the network or a new client joining the network. For example, the IP address of the new client needs to be added to the host information database 240.

Working with the host information database 240, the backup application module 250 creates an application that can be downloaded, installed, and run by the client. In addition to satisfying the basic executable requirements, this application provides the client with the specific functionality it needs to act as a backup host. The application can tune the client so that it can connect and exchange data with other clients in the network session.

The optional polling module 260 is configured to poll all clients in a network session. You can poll the connecting clients using the polling module 260. Polling for connections has problems sending small data packets to each client in a network session, receiving replies / confirmations from clients that receive the data packets, and communicating with host 200. It can include determining the client.

The polling module 260 can automatically poll clients at periodic intervals. The polling module 260 provides when an event occurs, such as a new client joining a network session or a connection interruption (for example, the client is not seeing the data sent by host 200). It can also be configured to poll the client. The polling behavior of the polling module 260 may resemble a periodic beating as described in US Patent Publication No. 2003-0204566, "Multi-User Application Interface." This disclosure has already been incorporated by reference.

Host 200 may include timer 270. The timer 270 is configured to measure the time elapsed after the event. The host 200 can use the timer 270 to determine the time between the data transmission as generated by the polling module 260 and the confirmation of the data transmission. This type of information can be used to determine whether to terminate the connection to a particular client. When measured by timer 270, if host 200 has not received confirmation or polling response from a particular client for a period of time, host 200 may drop the connection with that client. ..

The application created by the backup application module 250 may further include certain features similar to those of the polling module 260 and the timer 270. Unlike Host 200, which attempts to determine whether to remove a particular client from a network session, this "beat" feature is used by the client designated as the backup host, which prevents Host 200 from performing certain host obligations. , Or determine the number of consecutive failed executions of the host obligation. The inability or failure of host 200 to perform a particular obligation can be represented by the lack of continuous reception of the ACK or heartbeat generated by the acknowledgment module 220.

Figure 3A shows an implementation of an exemplary system 300 for network data distribution. Host 200 is connected to multiple clients 310A-D. Client 310A has successfully negotiated backup feasibility with host 200 and is receiving host information through connection 320. Using the host information, client 310A connects with other clients in the network, namely client 310B-D. The connection 330 allows client 310B-D to communicate directly with client 310A (ie, without going through host 200). The client 310B-D can exchange data with the client 310A using the connection 330 when it becomes difficult to transmit data from each client to the host 200. Client 310B-D can also automatically send data to client 310A regardless of problems in sending data to host 200.

Figure 3B shows another implementation of an exemplary system for network data distribution. In particular, FIG. 3B illustrates an exemplary system for network data distribution when communication between host 200 and client 310D is interrupted. Specifically, it shows how the data transmission 340 between the host 200 and the client 310D failed. While Client 310D is attempting to perform a data transmission 340 to Host 200, a failed connection is preventing Host 200 from receiving the transmission.

Since client 310A is the backup host for network sessions, client 310D sends the same data destined for host 200 directly (ie, not through host 200) to client 310A on backup data transmission 350. Can be done. Subsequently, the client 310A sends the data to the host 200 by the data transmission 360. In this particular embodiment, client 310A acts as a proxy between client 310D and host 200 for faulty communication that separates client 310D and host 200. Subsequently, the host 200 distributes the data from the client 310D to the clients 310B and 310C, although it is received via the client 310A. Alternatively, client 310A may send data to client 310B or 310C if host 200 fails to maintain host obligations for the connection between client 310D and host 200.

Since the communication between the host 200 and the client 310D is interrupted, the client 310D needs to acquire the session data via the client 310A. In addition to requesting data on behalf of any computing device, client 310A can act as an intermediate medium for sending and receiving data to and from host 200 and client 310D.

FIG. 4 is a flowchart showing an exemplary method 400 for network data distribution. The steps (and their order) identified in FIG. 4 are exemplary and can include various alternatives, equivalents or derivatives, and are not limited to the order of their execution. The steps in the process of Figure 4 (and their various alternatives) include hardware or hardware, including machine-readable or computer-readable recording media (eg, optical disks, memory cards, or hard drives) that contain instructions that can be executed by the processor. It can be realized by software.

At step 410, the host (eg, host 200) establishes a network session. The host may set specific parameters for who can participate in the network session, in addition to the various aspects in which the network session proceeds. The host can establish a private network session in which only specific clients or invited clients can participate. Alternatively, the host can establish a network session that is open to the public and open to any client.

At step 420, multiple clients join the network session by connecting to the host. If the host has set certain parameters for who can join the network session, the client must meet those parameters before being allowed to connect to or join the network session. is there.

At step 430, backup feasibility is negotiated via the negotiation module 230 in Figure 2. One or more clients can be a viable backup host with the capacity and resources to act as a backup host. Various aspects of backup feasibility, including bandwidth and quality of service, are evaluated to determine if a particular client can function as a backup host. Depending on the requirements of negotiation module 230, there may be one or more executable backup hosts, or no backup hosts, among the clients in a network session.

At step 440, backup responsibility is assigned. If you have multiple clients that are executable backup hosts, you need to assign backup responsibilities among those clients with respect to order and / or specific responsibilities. Clients in a network session can send their data to a first executable backup host. The first viable backup host is the one identified by the host or first considered a backup by broadcast or other communication. The latter is illustrated in US Patent Publication No. 2003-0217135, "Dynamic Player Management," which disclosure has already been incorporated by reference. If the first executable backup host becomes inoperable or inoperable as a backup host, other clients send their data to the second executable backup host. You can join the network session. The means disclosed herein and / or disclosed in the "Dynamic Player Management" application described above can be used to indicate the need to communicate with a second backup host.

At step 450, it is determined whether a particular client can connect to each of the other clients in the network session. The backup host must be able to connect to each client in the session and any other client. If the first client cannot connect to the second client, the first client cannot act as a backup host for network sessions. For example, the first client may have a firewall issue that prevents it from making certain types of connections. If the potential backup host cannot connect to another client for any reason, the method returns to step 440 and reassigns backup responsibility.

If it is determined that one client is a viable backup host and can connect to all other clients in the network session, the method proceeds to step 460. At step 460, the backup information is downloaded to an executable backup host. Providing backup information to the backup host allows the host to leave the network and the backup host to provide any information requested by other clients in the network session. As mentioned in the context of Backup Application Module 250 in Figure 2, backup information can be provided as part of the application download and installation that facilitates seamless host migration.

At step 470, network data distribution is initiated. As shown in Figure 3A, data transmission occurs between the host and the client. As further shown in Figure 3B, data is sent between two clients, that is, from a client with host connectivity issues to a client that can act as a backup host. In addition, the backup host can send data to the host or, upon request, directly to other clients. Data is provided to the computing device that requests it through any connection that must relay the data.

Although the present invention has been described with reference to exemplary embodiments, those skilled in the art can make various modifications without departing from the true spirit and scope of the invention, and the elements of the equivalent. You will understand that replacement is possible. In addition, modifications can be made without departing from the essential teachings of the present invention. Various alternative systems can be utilized to implement the various methods described herein, and various methods can be used to achieve the particular results resulting from the systems described above.

<figref num="1A">It is a figure which shows the client-server network configuration which is known in the art.</figref><figref num="1B">An exemplary system for network data distribution with one backup host is shown.</figref><figref num="1C">An exemplary system for network data distribution with several backup hosts is shown.</figref><figref num="2">FIG. 5 illustrates an exemplary configuration of a computing device that provides seamless host migration in a network data distribution system.</figref><figref num="3A">It is a figure which shows the implementation of the exemplary system for network data distribution.</figref><figref num="3B">FIG. 5 illustrates another implementation of an exemplary system for network data distribution.</figref><figref num="4">It is a figure which shows an exemplary method of network data distribution.</figref>