WO2009117946A1

WO2009117946A1 - Main-spare realizing method for dispatch servers and dispatch server

Info

Publication number: WO2009117946A1
Application number: PCT/CN2009/070973
Authority: WO
Inventors: 兑继英; 曹彦东; 李耀辉
Original assignee: 华为技术有限公司
Priority date: 2008-03-28
Filing date: 2009-03-24
Publication date: 2009-10-01
Also published as: CN101262369A; CN101262369B

Abstract

A main-spare realizing method for dispatch servers, a dispatch server, a dispatch server system and a method for providing dispatch service by dispatch server, the main-spare realizing method for dispatch servers includes the following steps. A spare dispatch server determines whether a main dispatch server can provide the dispatch service for a client, if the main dispatch server cannot provide the dispatch service for the client, the spare dispatch server provides the dispatch service for the client using a new P2P topological relation under the condition of needing not obtain the P2P topological relation data maintained by the main dispatch server.

Description

Master and standby implementation method of scheduling server and scheduling server

The present application claims priority to Chinese Patent Application No. 200810088808.4, entitled "Scheduled Server Active and Standby Implementation Method and Scheduling Server", filed on March 28, 2008, the entire contents of which are incorporated by reference. In this application.

Technical field

The present invention relates to communication technologies, and in particular, to a master-slave implementation technology of a scheduling server and a scheduling service technology.

Background technique

The traditional client/server (C/S, client/server) architecture is shown in Figure 1. Each client receives data directly from the application server.

However, for applications such as downloads, video on demand, live broadcasts, etc., the application server needs to transfer a large amount of data to the client. In order to alleviate the burden of transmitting a large amount of data to the application server and the bearer network, those skilled in the art have developed a peer-to-peer (P2P) technology. As shown in FIG. 2, in the P2P technology, the client can not only obtain data from the application server, but after other clients obtain the same data, the client can also obtain data from the other client, so that the client can alleviate the data. The pressure of application servers and hosting networks.

Using P2P technology requires establishing a P2P topology relationship between clients, that is, establishing a data transmission relationship between clients. In general, P2P topology management can be divided into centralized topology management and distributed topology management. For centralized topology management, the scheduling server specifies the data transmission relationship between the clients; for distributed topology management, the scheduling server provides a client with a set of candidate clients, and the client and the client Negotiate to establish a data transmission relationship.

In the centralized topology management technology, the scheduling server needs to save the data transmission relationship between the clients. It can be said that the scheduling server plays an extremely important role in the centralized topology management technology. If the scheduling server fails, it will The client cannot join the P2P topology relationship. Clients that have joined the P2P topology relationship cannot adjust the topology relationship when needed. In order to avoid the negative consequences of the scheduling server due to failures, the scheduling server needs to use the redundant backup mechanism, that is, deploy two or more scheduling servers. When one of the scheduling servers fails, the other scheduling servers also You can continue to provide services to clients.

The traditional redundant backup mechanism includes the following three implementation methods: 1. Redundant backup of shared storage

In this implementation, the P2P topology relationship data is saved to a persistent storage device, and each scheduling server can obtain P2P topology relationship data from the persistent storage device when needed. For example, when the primary scheduling server fails, other scheduling servers can obtain P2P topology relationship data from the persistent storage device as the primary scheduling server, and continue to maintain the P2P topology relationship based on the original P2P topology relationship.

Although the above implementation can implement the active/standby switchover of the dispatch server, the inventors have carefully analyzed and found that: accessing the permanent storage device is much lower than the performance of accessing the memory; in addition, each change of the P2P topology relationship is written permanently. In a storage device, this will seriously affect the performance of the dispatch server; in addition, the use of permanent storage increases the cost, and the permanent storage itself is also at risk of failure.

2. Real-time fully synchronized redundant backup

In this implementation manner, the primary scheduling server transmits the P2P topology relationship data to all the standby scheduling servers in real time. After the active/standby switchover, the standby scheduling server bases on the original P2P topology relationship based on the data obtained by the real-time synchronization. Maintain P2P topology relationships.

Although the above implementation manner can also implement the active/standby switchover of the scheduling server, the inventors have carefully analyzed and found that: Due to the large amount of data of the P2P topology relationship, the network transmission overhead is also large, to support 100,000 online clients, Each client uses 10 bytes as an example. In order to transmit P2P topology data, a transmission space of 1 Mbyte is required. In addition, in order to ensure the consistency of P2P topology data, in the synchronization process, the main scheduling server You cannot modify the topology. You must wait for the synchronization to complete before you can continue to provide scheduling functions for the client. This seriously affects the performance of the scheduling server.

3. Redundant backup of real-time incremental synchronization

In this implementation manner, the primary scheduling server sends only the modified part of the P2P topology relationship data to the standby scheduling server each time the P2P topology relationship is modified.

Although the above implementation can still implement the active/standby switchover of the scheduling server, the inventors have carefully analyzed and found that: This method is very complicated to implement, and will increase the probability of software errors. Since the P2P topology data is interrelated, one If the local error occurs, the entire P2P topology relationship may be unavailable. Secondly, in some cases, the P2P topology relationship data needs to be completely synchronized. For example, in the case of a failure of the standby scheduling server, the primary scheduling server needs to be prepared. After the scheduling server is restored, the P2P topology relationship data is synchronized to the standby scheduling server at one time; sometimes, the primary scheduling server You can also save all the modified data. After the standby server is restored, all the modified data is synchronized to the standby scheduling server. However, if the standby scheduling server recovers too long, the accumulated modified data may exceed the one-time. The amount of data being synchronized is even greater than the maximum space available to the primary dispatch server.

It can be seen that the above several redundant backup mechanisms have defects in performance, cost or reliability. Summary of the invention

The technical problem to be solved by the embodiments of the present invention is to provide a master/slave implementation method of a scheduling server, a standby scheduling server, a scheduling server system, a method for providing a scheduling service, and a scheduling server, which are used to achieve the purpose of redundancy backup of the scheduling server. To solve the defects of the above several redundant backup mechanisms.

To solve the above technical problem, an embodiment of the present invention provides a method for implementing a master/slave of a scheduling server, including: the standby scheduling server determines whether the primary scheduling server can provide a scheduling service for the client; if the primary scheduling server cannot provide a scheduling service for the client The standby scheduling server provides the scheduling service for the client by using the new P2P topology relationship without obtaining the P2P topology relationship data maintained by the primary scheduling server.

The embodiment of the present invention further provides a scheduling server, including: a first detecting unit, configured to detect whether the primary scheduling server can provide a scheduling service for the client; and a scheduling service providing unit, configured to: if the first detecting unit determines the primary scheduling server If the scheduling service cannot be provided for the client, the scheduling service is provided to the client by using the new P2P topology relationship without obtaining the P2P topology relationship data maintained by the primary scheduling server.

The embodiment of the present invention further provides a scheduling server system, including: a primary scheduling server, configured to provide a scheduling service for a client; at least one standby scheduling server, when the primary scheduling server cannot provide a scheduling service for the client, where A standby scheduling server provides scheduling services for clients by using a new P2P topology relationship without obtaining P2P topology data maintained by the primary scheduling server.

The embodiment of the present invention further provides a method for a scheduling server to provide a scheduling service, including: when the scheduling server is re-working, determining whether the P2P topology relationship data originally maintained by the scheduling server can be obtained; if not, the scheduling server Provide scheduling services for clients using new P2P topology relationships. The embodiment of the present invention further provides a scheduling server, including: a determining unit, configured to determine whether the originally maintained P2P topology relationship data can be obtained when the scheduling server is re-working; and a scheduling service providing unit, configured to After the determining unit determines that the originally maintained P2P topology relationship data cannot be obtained, the new P2P topology relationship is used to provide a scheduling service for the client.

The embodiment of the present invention further provides a method for a scheduling server to provide a scheduling service, including: the scheduling server performs message interaction with a client; if the client needs to join a P2P topology relationship currently maintained by the scheduling server, The dispatch server provides information for identifying the client to the client.

The embodiment of the present invention further provides a scheduling server, including: a message interaction unit, configured to perform message interaction with a client; and an information providing unit, configured to: if the client needs to join a P2P topology relationship currently maintained by the scheduling server And providing, by the scheduling server, information for identifying the client to the client.

In the active/standby implementation of the scheduling server of the present invention, if the active/standby scheduling server is switched, the standby calling server does not need to obtain the P2P topology relationship data maintained by the primary scheduling server. Of course, the standby calling server does not need to store the primary scheduling server. Maintain P2P topology relationship data. In this way, although the standby server cannot maintain the P2P topology relationship maintained by the primary scheduling server, it can still ensure that the upper and lower nodes in the P2P topology relationship transmit data normally, and one of the nodes needs to join the P2P maintained by the standby calling server. In the topology relationship, you only need to add this node to the P2P topology relationship maintained by the standby server. Therefore, the embodiment of the present invention does not require the storage server to store the P2P topology relationship data, which saves the cost. The embodiment of the present invention does not need the primary scheduling server to synchronize the P2P topology relationship data with the standby scheduling server, thereby improving the The reliability of point-to-point data transmission.

In an embodiment in which the scheduling server of the present invention provides the scheduling service, if the scheduling server is re-working, even if the originally maintained P2P topology relationship data cannot be obtained, the scheduling service can be provided to the client by using the new P2P topology relationship. Therefore, the problem that the scheduling service cannot be provided once the scheduling server cannot obtain the originally maintained P2P topology relationship data is solved.

In another embodiment in which the scheduling server of the present invention provides a scheduling service, as long as the client needs to join the P2P topology relationship maintained by the scheduling server, the information used by the scheduling server to identify the client is provided to the Client, this will ensure that the scheduling server provides scheduling for the client When the service is serviced, it can be determined whether the client is already in the P2P topology relationship maintained by the client, thereby providing a corresponding scheduling service.

DRAWINGS

Figure 1 is a schematic diagram of an existing client/server architecture;

2 is a schematic diagram of existing P2P data transmission;

3 is a flowchart of a method for implementing active/standby of a scheduling server according to an embodiment of the present invention;

4 is a schematic structural diagram of a scheduling service system according to an embodiment of the present invention;

FIG. 5 is a flowchart of processing when a P2P terminal joins a P2P topology relationship according to an embodiment of the present invention. detailed description

First, the active/standby implementation method of the scheduling server in the embodiment of the present invention will be described. As shown in FIG. 3, the method includes: Step S301: determining whether the primary scheduling server can provide a scheduling service for the client; Step S302: If the primary scheduling server cannot provide the scheduling service for the client, the primary scheduling server maintenance is not required. Under the condition of P2P topology relationship data, the standby scheduling server uses the new P2P topology relationship to provide scheduling services for the client. The new P2P topology relationship is relative to the P2P topology relationship maintained by the primary scheduling server. The new P2P topology relationship used by the standby scheduling server can be used to refer to the P2P topology relationship maintained by the scheduling server. When the standby scheduling server starts working but has not yet communicated with any client, only the content server is maintained in the P2P topology relationship. As more clients join the P2P topology maintained by the standby scheduling server, The number of nodes in the P2P topology relationship increases.

The standby scheduling server determines whether the primary scheduling server can provide scheduling services for clients can be implemented in a variety of ways. For example, it can be detected whether the primary scheduling server is faulty or overloaded, and if so, it is determined that the primary scheduling server cannot provide scheduling services for the client. For another example, it may be determined whether a message that the primary scheduling server or other network entity issues a failure or overload of the primary scheduling server is received, and if so, it is determined that the primary scheduling server cannot provide a scheduling service for the client.

The standby scheduling server uses the new P2P topology relationship to provide scheduling services for clients, which can be implemented in a variety of ways. For example, if the client needs to join a new P2P topology relationship, the client is added to the new P2P topology relationship.

Before the new master scheduling server determines that the client needs to join the new P2P topology relationship, you need to determine whether the client needs to join the new P2P topology relationship. E.g, Obtain the information reported by the client, and determine whether the client needs to join the new P2P topology relationship according to the information. Specifically, the new primary scheduling server may first determine whether the client is in a new P2P topology relationship, and if not, determine whether the client needs to join a new P2P topology relationship. Determining whether the client is in a new P2P topology relationship can also be implemented in a variety of ways. For example, the new primary scheduling server determines whether the P2P topology version information reported by the client for identifying a new P2P topology relationship and/or the client information used to identify the client is related to the current P2P topology version information and / or the client information assigned to the client is consistent, and if so, the client is determined to be in a new P2P topology relationship, otherwise, the client is determined not to be in a new P2P topology relationship. For another example, the new primary scheduling server provides P2P topology version information for identifying a new P2P topology relationship and/or client information for identifying the client to the client with which the message is exchanged, and is checked by the client. Whether it is in a new P2P topology relationship; if the information of the client reported by the client in the new P2P topology relationship is obtained, it is determined that the client is in a new P2P topology relationship; If the information reported by the client that the client is not in the new P2P topology relationship is obtained, it is determined that the client is not in the new P2P topology relationship.

The information reported by the client may include information that needs to be added to the P2P topology relationship, information that the upper node is abnormal, request information for replacing the superior node, or information about itself. The self information is, for example, load information of itself, information on whether or not it is in the P2P topology relationship, or information in which P2P topology relationship itself. The following is an example. Assume that the client in the P2P topology relationship maintained by the original primary scheduling server reports the information in the P2P topology relationship maintained by the original primary scheduling server but has a heavy load on its own, so the new primary scheduling server can report it according to its The information determines that the client should be added to the new P2P topology relationship to reduce the load of the client. Of course, since the new primary scheduling server does not obtain the P2P topology relationship maintained by the original primary scheduling server before, Data, so the new master dispatch server treats the client as a new client.

The information reported by the client may also include P2P topology version information for identifying a new P2P topology relationship and/or client information for identifying the client. The P2P topology version information may be an identifier, which is called a P2P topology. The version number, the client information can also be an identifier, called the client identifier. Among all the scheduling servers, the new primary scheduling server can identify the client using P2P topology version information and/or client information. In this case, if the client reports the P2P topology version information and/or the client information, the new primary scheduling server can be based on the P2P topology version information and/or the client. End information, determine whether the client is in a new P2P topology relationship, and if not, determine whether the client needs to join a new P2P topology relationship.

After the new primary scheduling server determines that the client needs to join the new P2P topology relationship, it can specify the superior node for the client. In this way, the client can obtain P2P data from the superior node.

The P2P topology version information for identifying the P2P topology relationship maintained by the new primary scheduling server and/or the client information for identifying the client may also be provided to the client at the same time as or after the client is designated with the upper node. It should be noted that the P2P topology version information and the client information can be integrated into one type of information, that is, when the P2P topology version information and the client information are provided to the client, only one type of information can be provided. The information includes both the content of the P2P topology version information and the content of the client information. After the client is added to the new P2P topology relationship, the interactive message can carry P2P topology version information and/or client information each time it interacts with the client. It should be noted that the client information can also be reported by the client without the need for a new primary dispatch server to provide client information. For example, if the client needs to join the new P2P topology relationship, it can record the client information generated and reported by the client to identify the client.

In addition, if the client needs to join the new P2P topology relationship, the client information can be recorded. The information of the client here is not limited to the client information used to identify the client, but also refers to other types of client-related information.

Another implementation manner in which the standby scheduling server uses the new P2P topology relationship to provide the scheduling service for the client is that if the client in the P2P topology relationship maintained by the original primary scheduling server does not need to join the new P2P topology relationship, The client in the P2P topology relationship maintained by the original primary scheduling server still obtains P2P data in the P2P topology relationship maintained by the original primary scheduling server.

Before determining whether the client in the P2P topology relationship maintained by the original primary scheduling server does not need to join the new P2P topology relationship, you need to determine whether the client in the P2P topology relationship maintained by the original primary scheduling server needs to join the new P2P topology relationship. In particular, it can be implemented in a variety of ways. One of the methods is: obtaining information reported by the client in the P2P topology relationship maintained by the original primary scheduling server; determining, according to the information, whether the client in the P2P topology relationship maintained by the original primary scheduling server needs to join a new one. P2P topology relationship. Another implementation manner in which the standby scheduling server uses the new P2P topology relationship to provide the scheduling service for the client is that if the client that is originally in a P2P topology relationship needs to be added to the new P2P topology relationship, the indication may be indicated. The client quits after the specified time arrives The original P2P topology relationship. For example, the client can be instructed to quit the original P2P topology relationship after 30 seconds. After 30 seconds, the client exits the original P2P topology relationship and joins the P2P topology relationship maintained by the new primary scheduling server.

The foregoing method may be implemented by multiple forms of devices, where the scheduling server includes: a first detecting unit, configured to detect whether the primary scheduling server can provide a scheduling service for the client; and a scheduling service providing unit, if the first The detecting unit determines that the primary scheduling server cannot provide the scheduling service for the client, and provides the scheduling service for the client by using the new P2P topology relationship without obtaining the P2P topology relationship data maintained by the primary scheduling server.

The scheduling service providing unit includes: a second detecting unit, configured to detect whether the client needs to join a new P2P topology relationship; and a P2P topology relationship processing unit, configured to: if the second detecting unit detects that the client needs to join the new P2P In the topology relationship, the client is added to the new P2P topology relationship. The second detecting unit may include: an information obtaining unit, configured to obtain information reported by the client; and a determining unit, configured to determine, according to the information, whether the client needs to join a new P2P topology relationship.

The scheduling server may further include: an information recording unit, configured to record the information of the client if the second detecting unit detects that the client needs to join the new P2P topology relationship.

In addition to providing the above method and scheduling server, the present invention further provides a scheduling server system, including: a primary scheduling server, configured to provide a scheduling service for a client; at least one standby scheduling server, when the primary scheduling server cannot be a client When the scheduling service is provided, one of the standby scheduling servers provides the scheduling service for the client by using the new P2P topology relationship without obtaining the P2P topology relationship data maintained by the primary scheduling server.

The scheduling server system may further include a message forwarding device, configured to forward a message between the client and a scheduling server capable of providing a scheduling service for the client, where the primary scheduling server cannot provide a scheduling service for the client, one of the When the standby scheduling server provides the scheduling service for the client, the message forwarding device forwards the message between the standby scheduling server and the client that provides the scheduling service for the client. The message forwarding device may be a device such as a switch or a separate device independent of the switch.

It should be noted that the standby scheduling server mentioned above may refer not only to the standby scheduling server of the primary scheduling server, but also to the scheduling server that is maintaining other P2P topology relationships, or the scheduling relationship of the scheduling server. They are all relative. The embodiment of the present invention further provides a method for the scheduling server to provide the scheduling service, including: determining whether the original maintained P2P topology relationship data can be obtained when re-working; if not, using the new P2P topology relationship as the client Provide scheduling services. Re-work can mean that the scheduling server has already provided the scheduling service for the client, but the scheduling server has an abnormal phenomenon such as a crash or shutdown due to some or some reasons, so that the scheduling server can no longer provide the scheduling service, and the scheduling server restarts. After the exception is handled in an equal manner, the scheduling service is restarted. There is a wide variety of reasons for not being able to obtain the P2P topology data that was originally maintained. For example, the scheduling server does not save the P2P topology relationship data until the scheduling server cannot continue to provide the scheduling service. Thus, when the scheduling server is restarted, the original cannot be obtained. Maintain P2P topology relationship data. The new P2P topology relationship is relative to the P2P topology relationship originally maintained by the dispatch server. When the scheduling server restarts working but has not yet interacted with any client, only the content server is maintained in the new P2P topology relationship, as more clients join the new P2P topology maintained by the scheduling server. When there is a relationship, the number of nodes in the new P2P topology relationship increases.

Using the new P2P topology to provide scheduling services to clients can be implemented in a variety of ways. For example, if the client needs to join a new P2P topology relationship, the client can be added to the new P2P topology relationship.

Before determining that a client needs to join a new P2P topology, you can determine if the client needs to join the new P2P topology. Determining whether a client needs to join a new P2P topology relationship can also be implemented in a variety of ways. For example, obtaining information reported by the client; determining, according to the information, whether the client needs to join a new P2P topology relationship.

Before determining, according to the information, whether the client needs to join the P2P topology relationship maintained by the new primary scheduling server, whether the client is in a new P2P topology relationship, and if not, determining the Whether the client needs to join the new P2P topology relationship.

Determining whether the client is in a new P2P topology relationship can also be implemented in a variety of ways. For example, determining whether the P2P topology version information used to identify the new P2P topology relationship on the client and/or the client information used to identify the client is related to the current P2P topology version information and/or allocation. The client information to the client is consistent, and if so, the client is determined to be in a new P2P topology relationship, otherwise, the client is determined not to be in a new P2P topology relationship. For another example, a client that performs message interaction with the dispatch server provides a P2P extension for identifying a new primary dispatch server maintenance. P2P topology version information of the Pu relationship and/or client information for identifying the client, the client checking whether it is in a new P2P topology relationship; if obtaining the client reported by the client The information in the new P2P topology relationship is determined to be in the new P2P topology relationship; if the information reported by the client is not in the new P2P topology relationship, It is determined that the client is not in a new P2P topology relationship.

Another way to use the new P2P topology relationship to provide scheduling services for clients is to maintain the P2P topology if the clients in the original P2P topology relationship do not need to join the new P2P topology relationship. The client in the relationship still obtains P2P data in the originally maintained P2P topology relationship.

Before determining whether the client in the original P2P topology relationship does not need to join the new P2P topology relationship, you can determine whether the client in the original maintained P2P topology needs to join the new P2P topology relationship. A method for determining whether a client in the P2P topology relationship that is to be maintained needs to be added to a new P2P topology relationship is obtained by obtaining information reported by the client in the originally maintained P2P topology relationship; Whether the client in the original maintained P2P topology needs to join the new P2P topology relationship.

The foregoing method embodiment may be implemented by multiple forms of devices, and one of the scheduling servers includes: a determining unit, configured to determine whether the originally maintained P2P topology relationship data can be obtained when re-working; the scheduling service providing unit, After the determining unit determines that the originally maintained P2P topology relationship data cannot be obtained, the new P2P topology relationship is used to provide a scheduling service for the client.

The scheduling service providing unit may include: a detecting unit, configured to detect whether the client needs to join a new P2P topology relationship; and a P2P topology relationship processing unit, configured to: if the detecting unit detects that the client needs to join a new P2P extension In the Park relationship, the client is added to the new P2P topology relationship.

The detecting unit may include: an information obtaining unit, configured to obtain information reported by the client; and a determining unit, configured to determine, according to the information, whether the client needs to join a new P2P topology relationship.

The embodiment of the present invention further provides a method for a scheduling server to provide a scheduling service, including: performing message interaction with a client; if the client needs to join a P2P topology relationship currently maintained by the scheduling server, the scheduling is performed. Information for the server to identify the client is provided to the client. After the information that the scheduling server uses to identify the client is provided to the client, all or part of the messages sent by the client may be carried by the scheduling server to identify the information of the client.

After the scheduling server is configured to identify that the information of the client is provided to the client, if the message interaction with the client is performed again, the scheduling server may be used again to identify the information provided by the client. To the client, the client checks whether it is in a new P2P topology relationship; if the client reports the information in the new P2P topology relationship, The client is in the new P2P topology relationship; if the information reported by the client is not in the new P2P topology relationship, it is determined that the client is not in the new P2P topology relationship.

After the scheduling server is configured to identify that the information of the client is provided to the client, if the message is exchanged with the client again, the scheduling server is used according to the message carried in the message reported by the client. Identifying the information of the client to determine whether the client is in a new P2P topology relationship.

The information for identifying the client includes P2P topology version information of the P2P topology relationship currently maintained by the scheduling server and/or client information for identifying the client is provided to the client.

The foregoing method may be implemented by multiple forms of devices, and one of the scheduling servers may include: a message interaction unit, configured to perform message interaction with the client; and an information providing unit, configured to perform current maintenance if the client needs to join the scheduling server In the P2P topology relationship, the information used by the scheduling server to identify the client is provided to the client.

The embodiments of the present invention are described in detail below.

As shown in FIG. 4, the scheduling server 1, the scheduling server 2, and the message forwarding device form a scheduling server system, and interact with the P2P terminal (ie, the client mentioned above). At the same time, only one of the dispatching server 1 and the dispatching server 2 receives and processes the request of the P2P terminal, and the standby dispatching server needs to monitor whether the primary dispatching server is invalid. If the standby scheduling server finds that the primary scheduling server is invalid, the standby scheduling server needs to act as the primary scheduling server to interact with the P2P terminal. After the original primary scheduling server is restored, it can serve as the standby scheduling server. For the P2P terminal, it interacts with the scheduling server device instead of the scheduling server 1 and the scheduling server 2. Each scheduling server includes a terminal request processor, a service side terminal topology manager, a terminal topology unit, a terminal topology version number manager, and a monitoring unit. The terminal request processor is responsible for receiving and processing the request of the P2P terminal, and the service side terminal topology manager is responsible for querying and updating the topology of the P2P terminal, and the terminal topology unit is responsible for saving the topology of the P2P terminal, and managing the terminal topology version number. The device is responsible for maintaining the current topology version number of the P2P terminal (that is, the P2P topology version information mentioned above). The monitoring unit is responsible for detecting whether the peer end is invalid, triggering the active/standby switchover, and performing data synchronization between the active and standby dispatch servers. The synchronized data refers to a small amount of data such as configuration parameters, and does not include P2P topology data of a large amount of data.

The P2P terminal includes a terminal side topology manager, a terminal identification unit, and a terminal topology version number manager. The terminal side topology manager is responsible for interacting with the scheduling server device to update the superior node information. Each P2P terminal has a unique terminal identifier (i.e., the client information mentioned above for identifying the client), and the terminal identification unit is responsible for saving the terminal identifier. When the P2P terminal joins the P2P topology relationship for the first time, it obtains a terminal topology version number from the scheduling server device, and the terminal topology version number unit is responsible for saving the terminal topology version number.

When each scheduling server is started, the terminal topology version number manager needs to update the terminal topology version number to identify the newly created P2P topology relationship after the startup. Each time a new topology version number is generated, it must be ensured that the new topology version number does not overlap with all the topology version numbers used by the active and standby scheduling servers for a period of time. A simple implementation is that The time (which can be accurate to the second) is combined with the server's NIC address as the topology version number.

When a P2P terminal joins a P2P topology relationship, the processing flow is as shown in Figure 5:

Step S501: The P2P terminal sends a request for joining the P2P topology relationship to the scheduling server device, where the request includes information of the P2P terminal, for example, information such as an IP address, a network card address, and an uplink and downlink bandwidth of the P2P terminal.

Step S502: After receiving the request, the message forwarding device in the scheduling server device forwards the request to the main scheduling server.

Step S503: After receiving the request, the terminal of the primary scheduling server allocates a unique terminal identifier to the P2P terminal.

Step S504: The terminal requests the processor to invoke the service side terminal topology manager, and adds the P2P terminal to the P2P topology relationship. Step S505: The service side terminal topology manager records the information of the P2P terminal, and specifies the upper node for the P2P terminal according to the topology management policy.

Step S506: The terminal requesting processor returns the topology information returned by the service side terminal topology manager and the topology version number assigned to the P2P terminal to the P2P terminal.

Step S507: After the P2P terminal receives the information returned by the scheduling server device, the terminal side topology manager parses the information, saves the terminal identifier in the information in the terminal identification unit, and saves the terminal topology version number in the information in the terminal. The topology version number unit, after which, follow the instructions in the message to connect to the superior node and obtain data from the superior node.

After the terminal-side topology manager is connected to the upper-level node, the topology update request may be sent to the scheduling server device. For details, refer to steps S508-S510 of FIG.

Step S508: The terminal side topology manager sends a topology update request to the scheduling server device. Step S509: After receiving the topology update request, the terminal requesting processor of the main scheduling server invokes the service side terminal topology manager to update the topology.

Step S510: The service side terminal topology manager records the updated topology into the terminal topology component.

After a P2P terminal joins a P2P topology relationship, it may need to interact with the scheduling server again for various reasons. For example, the P2P terminal finds that the upper node fails and needs to connect to the new upper node; the P2P terminal needs to provide its own load condition to the scheduling server, so that the scheduling server decides whether to use the P2P terminal as the upper node of the other P2P terminal. After the P2P terminal joins the P2P topology relationship, each time the message is sent to the scheduling server, the message can carry the terminal topology version number.

When the primary scheduling server fails, the standby scheduling server is started, and the new primary scheduling server provides scheduling services for the P2P terminal. When the new primary scheduling server is started, the new terminal topology version number is used as the current terminal topology version number. The original P2P topology relationship can continue to exist, that is, the P2P topology relationship does not need to be completely adjusted, only when P2P is used. When the terminal needs to join the P2P topology relationship maintained by the new primary scheduling server, the P2P terminal is added to the P2P topology relationship maintained by the new primary scheduling server. For example, if the P2P terminal in the P2P topology relationship maintained by the original primary scheduling server cannot be used to obtain data due to the original P2P topology relationship due to the exit of the upper-level node, etc., the original P2P topology relationship is exited, and a new P2P topology is added. relationship. Specifically, the new primary scheduling server may use the current terminal topology version number and the terminal topology carried in the message sent by the P2P terminal. The version number is compared to determine whether the P2P topology relationship of the P2P terminal is the P2P topology relationship currently maintained by the new primary scheduling server. If yes, the P2P terminal is added to the P2P topology relationship maintained by the new primary scheduling server. Otherwise, According to the content of the request and other factors, the following different treatments can be performed:

1. If the P2P terminal reports its own information (such as the current uplink and downlink bandwidth), the new primary scheduling server can ignore the request, and the P2P terminal can continue to rely on the original P2P topology relationship to obtain data.

2. If the P2P terminal reports that its superior node is abnormal and/or adjusts the upper node by itself, the P2P terminal may have replaced the upper node by itself, and the new primary scheduling server may also ignore the request, so that the P2P terminal maintains the P2P extension itself. Park relationship;

3. If the P2P terminal needs to exit the P2P topology relationship, the new primary scheduling server can ignore the request;

4. If the P2P terminal needs to join the P2P topology relationship again, the new primary scheduling server adds the P2P terminal to a P2P topology relationship maintained by the new primary scheduling server, and returns a new terminal topology version number to the P2P terminal. The P2P terminal updates the saved terminal topology version number;

5. If the P2P terminal needs to adjust the upper node because its upper node is faulty, the new primary scheduling server can return the terminal topology version number error message to the P2P terminal. After receiving the error message, the P2P terminal disconnects all the other terminals. Connect, re-request to join the new P2P topology relationship. Since the exit of one P2P terminal may cause its lower-level terminal to exit, and the exit of its lower-level terminal may cause more P2P terminal to exit, this chain-locking reaction may cause the new primary dispatching server to be overloaded for a period of time. run. In order to avoid this kind of chain reaction, the P2P terminal can wait for a period of time before exiting the original P2P topology relationship, then exit the original P2P topology relationship, and then add a new P2P topology relationship, thus avoiding a large number of The P2P terminal centrally sends a request to the new primary dispatch server in a short time, reducing the burden on the new primary dispatch server.

In practical applications, the terminal topology version number and the terminal identifier may not be mutually independent identifiers, but may be integrated into one identifier. For example, the terminal topology version number may be part of the terminal identifier, and the new master scheduling server is a P2P terminal. When the terminal identifier is assigned, the provided terminal identifier includes the terminal topology version number. In addition, the terminal identifier may be specified by the scheduling server, or the P2P terminal may itself identify a terminal identifier that can uniquely identify itself, such as a network card address of the P2P terminal.

In practical applications, the new primary dispatch server only needs to discover the P2P terminal in any case. The P2P topology relationship is not the P2P topology relationship maintained by the new primary scheduling server, and the P2P terminal may be required to rejoin the P2P topology relationship.

In a practical application, the new primary scheduling server may identify whether the P2P terminal is in the P2P topology relationship maintained by the new primary scheduling server; and the scheduling server actively sends the message carrying the current terminal topology version number to the P2P terminal. In this case, it is also possible for the P2P terminal to check whether it is in the P2P topology relationship maintained by the new primary dispatch server.

In a practical application, if it is determined that the terminal topology version number may not be checked in some scenarios (for example, the P2P terminal reports the current uplink and downlink bandwidth), the message sent by the P2P terminal to the new primary scheduling server may not carry the terminal. Topology version number.

In the active and standby implementations of the scheduling server, the standby scheduling server can refer to a scheduling server that does not maintain any P2P topology relationship, that is, a dedicated standby scheduling server that is the primary scheduling server, or that is maintaining other P2P extensions. The scheduling server of the Park relationship, that is, the dedicated scheduling server that is not the primary scheduling server, but the primary scheduling server that maintains other P2P topology relationships. When the active/standby switchover is required, the scheduling server that maintains other P2P topology relationships is maintained. It is equivalent to the new primary scheduling server, which provides scheduling services for P2P terminals in the P2P topology relationship maintained by the original primary scheduling server.

Finally, it should be noted that embodiments of the scheduling server providing scheduling services can be applied to a wide variety of scenarios. For example, when the primary dispatch server fails and the standby dispatch server starts, the standby dispatch server can use this embodiment. For example, when a scheduling server needs to re-establish a P2P topology relationship due to the loss of the originally maintained P2P topology, etc., such an embodiment can also be used.

A person skilled in the art can understand that all or part of the process of implementing the above embodiment method can be completed by a computer program to instruct related hardware, and the program can be stored in a computer readable storage medium, the program When executed, the flow of an embodiment of the methods as described above may be included. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

The above description is only a preferred embodiment of the present invention, and it should be noted that those skilled in the art can also make several improvements and retouchings without departing from the principles of the present invention. It is considered as the scope of protection of the present invention.

Claims

Rights request

An active/standby implementation method of a scheduling server, comprising:

The standby scheduling server determines whether the primary scheduling server can provide a scheduling service for the client; if the primary scheduling server cannot provide the scheduling service for the client, the standby scheduling server does not need to obtain the P2P topology relationship data maintained by the primary scheduling server. Use the new P2P topology to provide scheduling services for clients.

The active/standby implementation method of the scheduling server according to claim 1, wherein the standby scheduling server determines whether the primary scheduling server can provide a scheduling service for the client, where the standby scheduling server detects the primary scheduling server. Whether a fault has occurred or is overloaded, and if so, it is determined that the primary dispatch server cannot provide a scheduling service for the client.

The master/slave implementation method of the scheduling server according to claim 1, wherein the standby scheduling server determines whether the client needs to join a new P2P topology relationship, and the standby scheduling server determines according to the following manner. Whether the client needs to join the new P2P topology relationship:

The standby scheduling server obtains information reported by the client;

The standby scheduling server determines, according to the information, whether the client needs to join a new P2P topology relationship.

The active/standby implementation method of the scheduling server according to claim 1, wherein the information includes P2P topology version information for identifying a new P2P topology relationship and/or a client for identifying a client. information.

The master/slave implementation method of the scheduling server according to claim 4, wherein the standby scheduling server determines whether the client is in a new P2P topology relationship according to the following manner:

The standby scheduling server determines whether the P2P topology version information used by the client to identify a new P2P topology relationship and/or the client information used to identify the client is related to the current P2P topology version information and/or The client information assigned to the client is consistent;

If yes, the standby scheduling server determines that the client is in a new P2P topology relationship, otherwise, determines that the client is not in a new P2P topology relationship.

The standby scheduling server provides a client for performing message interaction with it to identify a new P2P The P2P topology version information of the topology relationship and/or the client information used to identify the client, and the client checks whether it is in a new P2P topology relationship;

If the standby scheduling server obtains information about the client in the new P2P topology relationship reported by the client, the standby scheduling server determines that the client is in a new P2P topology relationship, if When the scheduling server obtains the information that the client is not in the new P2P topology relationship, the standby scheduling server determines that the client is not in the new P2P topology relationship.

The active/standby implementation method of the scheduling server according to claim 1, wherein the standby scheduling server uses the new P2P topology relationship to provide scheduling services for the client, including: if the primary scheduling server maintains the P2P extension The client in the P2P relationship does not need to be added to the new P2P topology relationship. The client in the P2P topology relationship maintained by the main scheduling server still obtains P2P data in the P2P topology relationship maintained by the main scheduling server.

The master/slave implementation method of the scheduling server according to claim 7, wherein the standby scheduling server determines whether the client in the P2P topology relationship maintained by the primary scheduling server needs to join a new P2P topology relationship. The standby scheduling server determines whether the client in the P2P topology relationship maintained by the primary scheduling server needs to join the new P2P topology relationship according to the following manner:

The standby scheduling server obtains information reported by the client in the P2P topology relationship maintained by the primary scheduling server;

The standby scheduling server determines, according to the information, whether the client in the P2P topology relationship maintained by the primary scheduling server needs to join a new P2P topology relationship.

The master/slave implementation method of the scheduling server according to claim 1, wherein the standby scheduling server uses the new P2P topology relationship to provide a scheduling service for the client, specifically: if needed, the original P2P extension is required. When the client in the relationship is added to the new P2P topology relationship, the standby scheduling server instructs the client to exit the original P2P topology relationship after the specified time arrives.

10. A scheduling server, comprising:

a first detecting unit, configured to detect whether the primary scheduling server can provide a scheduling service for the client, and a scheduling service providing unit, configured to: if the first detecting unit determines that the primary scheduling server cannot provide the scheduling service for the client, The scheduling service is provided for the client by using the new P2P topology relationship under the condition that the P2P topology relationship data maintained by the server is scheduled.

A dispatch server system, comprising:

a primary scheduling server, configured to provide a scheduling service for the client;

At least one standby scheduling server, when the primary scheduling server cannot provide scheduling services for the client, one of the standby scheduling servers uses the new P2P topology without obtaining the P2P topology relationship data maintained by the primary scheduling server. Relationships provide scheduling services for clients.

12. A method for scheduling a server to provide a scheduling service, comprising:

When the scheduling server is working again, determining whether the P2P topology relationship data originally maintained by the scheduling server can be obtained;

If not, the scheduling server uses the new P2P topology to provide scheduling services for the client.

The method for providing a scheduling service by a scheduling server according to claim 12, wherein the scheduling server determines whether a client needs to join a new P2P topology relationship, and the scheduling server determines the client according to the following manner. Need to join the new P2P topology relationship:

The scheduling server obtains information reported by the client;

The scheduling server determines, according to the information, whether the client needs to join a new P2P topology relationship.

The method for providing a scheduling service by the scheduling server according to claim 12, wherein the scheduling server provides the scheduling service for the client by using the new P2P topology relationship, specifically: if the original maintained P2P topology relationship is The client does not need to join the new P2P topology relationship, and the client in the original maintained P2P topology relationship still obtains P2P data in the originally maintained P2P topology relationship.

The method for providing a scheduling service by the scheduling server according to claim 14, wherein the scheduling server determines whether a client in the originally maintained P2P topology relationship needs to join a new P2P topology relationship, The scheduling server determines whether the client in the originally maintained P2P topology relationship needs to join the new P2P topology relationship as follows:

The scheduling server obtains the information reported by the client in the P2P topology relationship that is originally maintained; the scheduling server determines, according to the information, whether the client in the originally maintained P2P topology relationship needs to join the new P2P topology. In the relationship.

16. A scheduling server, comprising: a determining unit, configured to determine whether the originally maintained P2P topology relationship data can be obtained when the scheduling server is re-working;

The scheduling service providing unit is configured to provide a scheduling service for the client by using the new P2P topology relationship after the determining unit determines that the originally maintained P2P topology relationship data cannot be obtained.

17. A method for scheduling a server to provide a scheduling service, the method comprising:

The scheduling server performs message interaction with the client;

If the client needs to join the P2P topology relationship currently maintained by the scheduling server, the scheduling server provides information for identifying the client to the client.

The method for providing a scheduling service according to claim 17, wherein after the scheduling server provides information for identifying the client to the client, if the message is sent again to the client Interaction also includes:

The scheduling server again provides information for identifying the client to the client, and the client checks whether it is in a new P2P topology relationship;

If the scheduling server obtains information about the client in the new P2P topology relationship reported by the client, the scheduling server determines that the client is in a new P2P topology relationship, if the scheduling The server obtains information that the client is not in the new P2P topology relationship, and the scheduling server determines that the client is not in the new P2P topology relationship.

The method for providing a scheduling service according to claim 17, wherein after the scheduling server provides information for identifying the client to the client, if the message is sent again to the client In an interaction, the scheduling server determines, according to the information that the scheduling server is used by the scheduling server that is sent by the client, to identify the client, whether the client is in a new P2P topology relationship.

20. A scheduling server, comprising:

a message interaction unit, configured to perform message interaction with the client;

An information providing unit, configured to: if the client needs to join the current maintenance of the scheduling server

In the P2P topology relationship, information used by the scheduling server to identify the client is provided to the client.