CN109818959B

CN109818959B - Remote service communication method, server and system

Info

Publication number: CN109818959B
Application number: CN201910081005.4A
Authority: CN
Inventors: 汪强
Original assignee: Xindong Network Co ltd
Current assignee: Xindong Network Co ltd
Priority date: 2019-01-28
Filing date: 2019-01-28
Publication date: 2021-05-28
Anticipated expiration: 2039-01-28
Also published as: CN109818959A

Abstract

The invention discloses a remote service communication method, which comprises the following steps: the service server sends a communication connection request to the central server to establish communication connection with the central server; the central server sends a registration request to the service server, wherein the data packet text of the registration request comprises first verification data; the service server returns registration data to the central server after successfully verifying the first verification data, wherein the data packet text of the registration data comprises the application name of the service server and the second verification data; after the central server successfully verifies the registration data, sending a registration success request to the service server, wherein the data packet text of the registration success request comprises third verification data; and the business server verifies the registration success request, if the verification is successful, the business server is provided for the central server, otherwise, the connection with the central server is disconnected. The invention also discloses a remote service communication method executed in the two servers, a corresponding server and a corresponding system.

Description

Remote service communication method, server and system

Technical Field

The invention relates to the technical field of internet, in particular to a remote service communication method, a server and a system.

Background

With the rapid development of internet technology, the number of network information resources is rapidly increased, so that the business system is more and more huge at present, the system of a company is composed of thousands of services with different sizes, and each service is deployed on different machines and is responsible for different teams. For example, for game services, games are usually deployed in different machine rooms, and a background console for managing the games, public services, and the like are in an IDC machine room, so that secure cross-machine-room network interconnection and intercommunication call services need to be implemented.

The traditional implementation is to implement an API interface and expose ports in the gaming machine room, and the game console server calls the corresponding API. Although the method can be verified through Token, once the encryption algorithm and the key are leaked, the encryption algorithm and the key can be directly cracked by others to utilize an API interface, so that the potential safety hazard exists, and the API of the game needs to be developed and deployed by each project group, so that the development and deployment cost is increased. Therefore, a service calling method capable of effectively avoiding the occurrence of similar potential safety hazards and reducing the development and deployment difficulty is needed.

Disclosure of Invention

To this end, the present invention provides a new teleservice communication method, server and system in an attempt to solve or at least alleviate the problems presented above.

According to an aspect of the present invention, there is provided a teleservice communication method adapted to be performed in a central server, the method comprising: receiving a communication connection request of a service server, and establishing communication connection with the service server; sending a registration request to the service server, wherein a data packet body of the registration request comprises first verification data; receiving registration data returned by the service server after the first verification data passes verification, wherein the data packet body of the registration data comprises the application name of the service server and second verification data; and verifying the registration data, if the verification is successful, sending a registration success request to the service server so that the service server provides service to the central server after the verification of the registration success request is passed, wherein a data packet body of the registration success request comprises third verification data.

Alternatively, in the remote service communication method according to the present invention, the first authentication data includes a registration request time of the center server, a first random number, and a first encryption value calculated based on the registration request time and the first random number; the second verification data comprises the registration return time of the service server, a second random number and a second encryption value calculated based on the registration return time and the second random number; and the third authentication data includes a registration success time of the service server, a third random number, and a third encrypted value calculated based on the registration success time and the third random number.

Optionally, in the teleservice communication method according to the present invention, the first encrypted value, the second encrypted value, and the third encrypted value are calculated according to a key agreed in advance between the service server and the central server.

Optionally, in the teleservice communication method according to the present invention, further comprising the steps of: and if the verification of the registration data fails, sending a registration failure request to the service server, and disconnecting the communication connection with the service server so that the service server re-requests to connect the central server when receiving the registration failure request.

Alternatively, in the teleservice communication method according to the invention, the establishing of the communication connection is performed by a secure transport protocol.

Optionally, in the teleservice communication method according to the present invention, each data packet body is represented in a serialized manner, and the data packet body of the registration data further includes a service name and/or version of the service server.

Optionally, in the teleservice communication method according to the present invention, each data packet further includes a data packet prefix, and the data packet prefix includes at least one of a data identifier, a version, a length, header information, and a custom context.

Optionally, in the teleservice communication method according to the present invention, the data identifier includes at least one of a system message request identifier, a request return mode identifier, a message completion identifier, and a browser request identifier.

Optionally, in the teleservice communication method according to the present invention, the header information includes at least one of an application identifier of the requester, a service identifier of the requester or the requested party, a request sequence number, an administrator identifier, and a length of the custom information.

Optionally, in the teleservice communication method according to the present invention, further comprising the steps of: and opening an interface corresponding to the service server, wherein the interface has an interface connection serial number so as to receive or forward data through the interface.

Optionally, in the teleservice communication method according to the present invention, further comprising the step of forwarding data between a plurality of traffic servers: receiving a data packet sent by a first service server, and analyzing an application identifier and a service identifier in a data packet prefix; determining a second service server corresponding to the application identifier and the service identifier and an interface of the second service server in a central server; the data packet is forwarded to a second service server through the interface, and a data forwarding result returned by the second service server is received; and feeding back the data forwarding result to the first service server.

Optionally, in the teleservice communication method according to the present invention, after receiving the data packet sent by the first traffic server, the method further includes the steps of: and analyzing the data identifier in the data packet prefix, and if the identifier is 0 or an unidentified numerical value, continuously analyzing the application identifier and the service identifier in the data packet prefix.

According to another aspect of the present invention, there is provided a teleservice communication method adapted to be performed in a service server, the method comprising: sending a communication connection request to a central server, and establishing communication connection with the central server; receiving a registration request sent by the central server, wherein a data packet body of the registration request comprises first verification data; verifying the first verification data, and returning registration data to the central server after the verification is passed, wherein the data packet text of the registration data comprises the application name of the service server and the second verification data; receiving a registration success request sent by the central server after the registration data is successfully verified, wherein the data packet text of the registration success request comprises third verification data; and verifying the successful registration request, if the successful registration request passes the verification, providing the service for the central server, and otherwise, disconnecting the communication connection with the central server.

Optionally, in the teleservice communication method according to the present invention, further comprising the steps of: receiving a registration failure request sent by the central server after the verification failure of the registration data, and requesting to connect the central server again after the central server is disconnected from the communication connection with the service server

According to still another aspect of the present invention, there is provided a teleservice communication method including: the service server sends a communication connection request to the central server to establish communication connection with the central server; the central server sends a registration request to the service server, wherein the data packet text of the registration request comprises first verification data; the service server verifies the first verification data and returns registration data to the central server after the verification is successful, and the data packet body of the registration data comprises the application name of the service server and the second verification data; the central server verifies the registration data, if the verification is successful, a registration success request is sent to the service server, and the data packet text of the registration success request comprises third verification data; and the business server verifies the registration success request, if the verification is successful, the business server is provided for the central server, otherwise, the connection with the central server is disconnected.

According to still another aspect of the present invention, there is provided a center server including: the first communication connection module is suitable for receiving a communication connection request of the service server and establishing communication connection with the service server; the first request sending module is suitable for sending a registration request to the service server, and the data packet text of the registration request comprises first verification data; the first request returning module is suitable for receiving registration data returned after the first verification data is successfully verified by the service server, and the data packet text of the registration data comprises the application name of the service server and the second verification data; and the second request sending module is suitable for verifying the registration data, and if the verification is successful, a registration success request is sent to the service server, so that the service server provides service to the central server after the verification of the registration success request is successful, and a data packet body of the registration success request comprises third verification data.

According to still another aspect of the present invention, there is provided a service server, including: the second communication connection module is suitable for sending a communication connection request to the central server and establishing communication connection with the central server; the first request receiving module is suitable for receiving a registration request sent by the central server, and the data packet text of the registration request comprises first verification data; the first request processing module is suitable for verifying the first verification data and returning registration data to the central server after the verification is passed, and the data packet text of the registration data comprises the application name of the service server and the second verification data; the second request receiving module is suitable for receiving a registration success request sent by the central server after the registration data is successfully verified, and a data packet body of the registration success request comprises third verification data; and the second request processing module is suitable for verifying the successful registration request, providing service for the central server if the successful registration request passes the verification, and disconnecting the communication connection with the central server if the successful registration request passes the verification.

According to still another aspect of the present invention, there is provided a server including: one or more processors; a memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for performing the request processing method as described above.

According to still another aspect of the present invention, there is provided a readable storage medium storing one or more programs, the one or more programs including instructions, which when executed by a server, cause the server to perform the request processing method as described above.

According to a further aspect of the present invention there is provided a teleservices communication system comprising a central server as described above, and one or more business servers as described above.

According to the technical scheme of the invention, the business server is directly connected to the central server through TLS, the service is provided after the successful verification and registration, and the external server cannot snoop data or directly connect to the business server to attack and steal data. The invention innovatively realizes a new control mode and RPC requests for interconnection and intercommunication among servers crossing a machine room, avoids potential safety hazards caused by the fact that a service server exposes a port in the traditional scheme, and simultaneously reduces the development and deployment difficulty of the service server.

Drawings

To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings, which are indicative of various ways in which the principles disclosed herein may be practiced, and all aspects and equivalents thereof are intended to be within the scope of the claimed subject matter. The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description read in conjunction with the accompanying drawings. Throughout this disclosure, like reference numerals generally refer to like parts or elements.

FIG. 1 illustrates a block diagram of a teleservices communication system 100 in accordance with one embodiment of the present invention;

FIG. 2 illustrates an implementation architecture diagram of a teleservices communication service according to one embodiment of the invention;

FIG. 3 shows a block diagram of a server 300 according to one embodiment of the invention;

FIG. 4 illustrates a flow diagram of a teleservices communication system method 400 performed in the system 100, in accordance with one embodiment of the present invention;

FIG. 5 illustrates a flow diagram for data forwarding by multiple traffic servers executing in the system 100, according to one embodiment of the invention;

FIG. 6 shows a flow diagram 600 of a teleservice communication method performed in a central server according to one embodiment of the invention;

FIG. 7 shows a flow diagram of a teleservice communication method 700 performed in a traffic server according to yet another embodiment of the invention; and

fig. 8 shows a block diagram of the structure of a central server 800 and a service server 900 according to an embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

Fig. 1 shows a schematic diagram of a teleservices communication system 100 according to one embodiment of the invention. As shown in fig. 1, the teleservices communication system 100 includes a central server 110, one or more service servers 120 (e.g.,

service servers

121, 122, and 123). It should be noted that the teleservice communication system 100 of fig. 1 is merely exemplary, and in a specific practical situation, there may be different numbers of central servers and business servers in the teleservice communication system 100, and the present invention does not limit the number of central servers and business servers included in the teleservice communication system 100.

The central server 110 may be communicatively coupled to the service servers 120, respectively, and further may be configured to establish a connection using a security transport protocol, such as a TLS connection (as shown in fig. 2) or an SSL connection, and a remote procedure call service (RPC) may be implemented between the various servers. The central server 110 may be one server, or a server cluster composed of a plurality of servers, or a cloud computing service center, and a plurality of servers for constituting the server cluster or the cloud computing service center may reside in a plurality of geographic locations. It can typically be located as an RPC server in an enterprise's internet data center room, which typically includes a back-end console for data management games and public services. Alternatively, the central server may be an RPC proxy server, the server domain name or port of which may be provided by the online physical environment.

Each service server 120, such as a game server, may be located in different machine rooms, and each service server corresponds to one or more services, such as one game service, a certain module under a game, or a certain module shared by multiple games. As shown in fig. 2, the game server in machine room a corresponds to game a, the game server in machine room B corresponds to game B, and each game server can be used as an RPC client. The service server 120 will register on the central server 110, and the RPC method and its prototype function implemented by the service server 120 include at least one of: a system registration method sys _ reg ($ time, $ range, $ hash), a system registration failure method sys _ regErr ($ msg, $ data $ null), a system registration success method sys _ regOk ($ data, $ time, $ range, $ hash), a write log method sys _ log ($ type, $ log, $ data $) a system reload method sys _ reload (), and a method sys _ getFunctions () of acquiring all methods of RPC.

In the system registration method sys _ reg ($ time, $ range, $ hash), $ time is a timestamp when the registration request is initiated, $ range is a random string, typically 16 bytes, when the registration request is initiated, and $ hash is a check code, which may be any commonly used algorithm in the art, and according to one embodiment, may be sha1($ time. $ range. For example: and time is 1544755188, rand abcdef, and hash is 92bc96dbae66092ce7627278c75ff997cf9dd 102. After receiving the registration request of the central server, the service server verifies the data in the registration request, if the verification fails or the time of the request exceeds a preset time (such as 30s), false is returned, the connection with the central server is disconnected, and if the verification succeeds, a registration data array is returned, and the registration data array is packaged in a body area by using an RPC service protocol.

In the system registration failure method sys _ regErr ($ msg, $ data $ null), msg is error information, $ data is an optional data, and null is defaulted. After the center server fails to verify the received registration data, it will initiate an RPC request of sys _ regErr () and close the connection, and when the service server receives the request, it can execute the operation of reconnecting or abandoning the connection according to the actual service.

In the system registration success method sys _ regOk ($ data, $ time, $ range, $ hash), $ data is the data information to the service server after the central server is successfully registered, $ time is the time when the registration is successful, $ range is a random string, $ hash is a verification parameter, and the algorithm is the same as the hash algorithm in sys _ reg. The central server initiates a registration success request after successfully verifying the received registration data, the service server verifies the registration success request without returning content after receiving the request, and the connection can be closed and then the verification is carried out again if the verification fails. Examples of the data text of the method are: cs9"sys _ regOk" a4{ m1{ s10"pageServer" m2{ s4"host" s22"http://127.0.0.1:8060/" s3"key" s16"41628805afed2139" } i 1546939264; s16"oPvkv8RgY7gEUOYU" s40"5520d7c0b6ec2dbc05ef64a7ab94ee8ed3879d89" } z

The log writing method sys _ log ($ type, $ log, $ data $ null) is mainly used for writing logs into a service server by an RPC central server, wherein $ type is a log type (including debug, war, info, and the like), $ log is log text content, and $ data is optional data content, and is usually array data. After receiving the RPC request, the service server can use a function written in a log by a program to process and can also choose to ignore information, and data does not need to be returned to the central server. Examples of the data text of the method are: cs7"sys _ log" a2{ s4 "wan" s18"This is a test log" } z

The method of acquiring all methods of RPC (sys _ getFunctions) essentially returns a list of all callable RPC method names to the service server, which do not need the system method containing the sys _ prefix, and if not, a null array. The data text shows, for example: ra2{ s4"test" s6"myFunc" } z, which represents that the server has two callable RPC methods of test () and myFunc (). According to the various RPC service methods of the present invention, the method beginning with sys _ in the name is system-defined and not available for business logic, the name of RPC method is used with an underline (_) as the definition namespace, such as the my _ test _ callback () method indicates the callback method name in my's test namespace. In addition, the RPC request and the RPC return packet are both packaged in the text area of the RPC service protocol by using an Hprose serialization method and an Hprose deserialization method.

After the service server 120 is successfully registered, the central server 110 allocates a server identifier, an application name, a service name, and the like to the service server 120, and further opens an interface corresponding to each service server 120 for normal request processing and return, for example, for forwarding data received by the central server, where each interface has an interface connection serial number. There are also data storage devices in the two servers for storing data, for example, the central server 110 stores the application identifier, service name, version, corresponding interface number, etc. of each service server 120, and the service server 120 stores the application service class data of each game, etc.

The central server 110 may implement data forwarding between the service servers 120, e.g., the a server may initiate RPC requests of the B server. After receiving the data of the server a, the central server 110 obtains the connection serial number of the server B at the current central server, and forwards the data to the connection interface in a TCP manner, and the interface performs normal request processing and returning, for example, forwards the data to the server B, and obtains a data forwarding result returned by the server B, and the central server feeds back the data forwarding result to the server a when requesting, thereby completing a complete multi-end server RPC request.

The central server 110 may also be communicatively coupled to clients for providing services to the clients. In general, the central server 110 may provide services to clients through client servers that manage the clients. The client server acts as an intermediate server, and when receiving a request from a client, forwards the request to the central server 110, so that the central server 110 requests data from a certain service server in response to the data request, and sends the data returned by the service server to the client via the client server. Or, the data packet sent by the service server can be directly received and forwarded to the corresponding client through the client server, for example, the game currency is issued to the client. Of course, the central server may also be directly connected to the client for communication and providing services thereto, which is not limited by the present invention. The client may be a mobile device such as a smart phone, a tablet computer, a desktop computer, and a notebook computer, which may be connected to the network, but is not limited thereto.

Therefore, compared with the traditional scheme that the service server is required to realize the API in the machine room of the service server and expose the port, the method and the system do not need to expose the port in the machine room of the service server, but connect each service server to the central server of the IDC machine room directly through TLS, start to provide service after verification and registration are successful, and the external server cannot snoop data and cannot be directly connected to the service server to attack and steal data. Meanwhile, the technical implementation also facilitates the development and deployment of the service server.

According to embodiments of the present invention, various components in teleservices communication system 100 described above, such as a central server and a business server, may communicate over one or more networks, such as a Local Area Network (LAN) or a Wide Area Network (WAN), such as the internet, and may each be implemented by computing device 300 as described below.

FIG. 3 shows a schematic diagram of a computing device 300, according to one embodiment of the invention. As shown in FIG. 3, in a basic configuration 302, a computing device 300 typically includes a system memory 306 and one or more processors 304. A memory bus 308 may be used for communication between the processor 304 and the system memory 306.

Depending on the desired configuration, the processor 304 may be any type of processing, including but not limited to: a microprocessor (μ P), a microcontroller (μ C), a Digital Signal Processor (DSP), or any combination thereof. The processor 304 may include one or more levels of cache, such as a level one cache 310 and a level two cache 312, a processor core 314, and registers 316. The example processor core 314 may include an Arithmetic Logic Unit (ALU), a Floating Point Unit (FPU), a digital signal processing core (DSP core), or any combination thereof. The example memory controller 318 may be used with the processor 304, or in some implementations the memory controller 318 may be an internal part of the processor 304.

Depending on the desired configuration, system memory 306 may be any type of memory, including but not limited to: volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.), or any combination thereof. System memory 306 may include an operating system 320, one or more applications 322, and program data 324. In some implementations, the application 322 can be arranged to execute instructions on the operating system with the program data 324 by one or more processors 304.

The computing device 300 may also include an interface bus 340 that facilitates communication from various interface devices (e.g., output devices 342, peripheral interfaces 344, and communication devices 346) to the basic configuration 302 via the bus/interface controller 330. The example output devices 342 include a graphics processing unit 348 and an audio processing unit 350. They may be configured to facilitate communications with various external devices, such as a display or speakers, via one or more a/V ports 352. Example peripheral interfaces 344 may include a serial interface controller 354 and a parallel interface controller 356, which may be configured to facilitate communication with external devices such as input devices (e.g., keyboard, mouse, pen, voice input device, touch input device) or other peripherals (e.g., printer, scanner, etc.) via one or more I/O ports 358. An example communication device 346 can include a network controller 360, which can be arranged to facilitate communications with one or more other computing devices 362 over a network communication link via one or more communication ports 364.

A network communication link may be one example of a communication medium. Communication media may typically be embodied by computer readable instructions, data structures, program modules, and may include any information delivery media, such as carrier waves or other transport mechanisms, in a modulated data signal. A "modulated data signal" may be a signal that has one or more of its data set or its changes made in such a manner as to encode information in the signal. By way of non-limiting example, communication media may include wired media such as a wired network or private-wired network, and various wireless media such as acoustic, Radio Frequency (RF), microwave, Infrared (IR), or other wireless media. The term computer readable media as used herein may include both storage media and communication media.

Computing device 300 may be implemented as a server, such as a database server, an application server, a WEB server, and the like, or as a personal computer including both desktop and notebook computer configurations. Of course, computing device 300 may also be implemented as part of a small-sized portable (or mobile) electronic device.

In an embodiment in accordance with the invention, computing device 300 is configured to perform teleservice communication methods 600 and/or 700 in accordance with the invention. Where application 322 of computing device 300 includes a plurality of program instructions for performing teleservices communication method 600 and/or 700 in accordance with the present invention, program data 324 may also store configuration information for teleservices communication system 100, and the like.

Fig. 4 shows a flow diagram of a teleservice communication method 400, suitable for execution in the teleservice communication system 100, according to an embodiment of the invention. As shown in fig. 4, the method begins at step S410.

In step S410, the service server sends a communication connection request to the central server, and establishes a communication connection therewith.

According to one embodiment, the establishment of the communication connection is performed by a security transport protocol, such as the transport Layer security protocol tls (transport Layer security) or its predecessor secure socket Layer protocol ssl (secure Sockets Layer). It should be understood that the process of establishing a communication connection through a security transport protocol is a mature technical means in the field, and a person skilled in the art can implement its communication connection by himself or herself as required, and will not be described in detail herein.

Subsequently, in step S420, the central server sends a registration request to the service server, where the body of the data packet of the registration request includes the first verification data. The central server initiates a registration request to call the system registration method sys _ reg ($ time, $ rand, $ hash).

According to one embodiment, the first authentication data includes a registration request time (i.e., a time at which the registration request is initiated) of the center server, a first random number, and a first cryptographic value calculated based on the registration request time and the first random number. In addition, as shown in the foregoing, in the communication service method of the present invention, especially in the registration process of the server, the contents of each data packet to be transmitted are represented in a serialized manner, that is, each array value to be transmitted is represented in a serialized text format, for example, in an Hprose serialized manner. When the receiver receives the data packet, the serialized text is converted into a corresponding array value through an deserialization method. The following is an example of a data package body of the first verification data:

Cs7"sys_reg"a3{i1546939264；s16"vqa16tT3KhrtcyjD"s40"40d976164249006afa8580ff4502b9a4dde849c9"}z

subsequently, in step S430, the service server verifies the first verification data, and returns registration data to the central server after the verification is successful, where a data packet body of the registration data includes the application name of the service server and second verification data, and the second verification data includes registration return time of the service server (i.e., time for returning the registration data), a second random number, and a second encryption value calculated based on the registration return time and the second random number.

When the first verification data is verified, firstly, the time variable $ time is verified, if the comparison value with the current timestamp (the current time is the seconds from 1/0 in 1970) is different by more than a preset time (such as 30s), the request is regarded as an expired data packet, and the connection can be disconnected for reconnection. And then verifying the received encryption value $ hash, wherein the verification method comprises the following steps: the received time $ time and random number $ rand variables are used, a sha1 value $ token (the algorithm is the same as the hash algorithm in sys _ reg ()) is calculated by combining the keys agreed by the two parties in advance, finally, the received encryption value $ hash and $ token are used for carrying out character string comparison, if the two values are the same, the success is shown, otherwise, the verification is considered to be failed, the connection with the corresponding server can be disconnected, and the server is tried to be connected again.

According to one embodiment, the data packet body of the registration data may further include the service name and/or version of the service server, and the registration data array thus transmitted may generally include the application name app, the service name, the registration return time, the second random number rand, the second encryption value hash, and the like. The calculation method of the encrypted value hash may be as described above, and according to one embodiment, it may be sha1("$ app. $ name. $ time. $ rand. $ key.xdapp.com"), where $ app, $ name, $ time, $ rand are the values of the corresponding key in the return array, and $ key is a key agreed by both parties. The following examples of the registration data array and its serialized text format are provided for the service server:

conversion to Hprose text format is:

m6{s3"app"s4"demo"s4"name"s7"console"s4"time"i1546937937；s4"rand"s16"2LMk264IwkrwRDyR"s7"version"s6"v1.1.0"s4"hash"s40"05947113fd5ac57e903a91a996d53ffeff360f50"}z。

subsequently, in step S440, the central server verifies the registration data, and if the verification is successful, sends a registration success request to the service server, where a data packet body of the registration success request includes third verification data.

When verifying the registration data, the received time variable and the received encryption value variable also need to be verified, and the verification method is the same as the first verification data, which is not described herein again. In addition, the application name, service name and version, etc. in the registration data can be verified, which is mainly to compare with the basic information of the application server stored in the central server to determine whether each item of content exists and is correct.

According to one embodiment, the third authentication data includes a registration success time (i.e., a time when the registration success request is initiated) of the service server, a third random number, and a third cryptographic value calculated based on the registration success time and the third random number. The algorithm of the third encryption value is still the same as the first and second encryption values, i.e. the calculation is performed based on the secret key agreed in advance between the service server and the central server.

Of course, if the verification of the registration data fails, a registration failure request is sent to the service server to call the system registration failure method sys _ regErr ($ msg, $ data ═ null), where the registration failure request includes error information of registration failure, and the communication connection with the service server is disconnected, so that the service server re-requests to connect the central server when receiving the registration failure request, that is, re-performs the communication connection establishment procedure in step S410.

Finally, in step S450, the service server verifies the registration success request, and provides the service to the central server if the verification is successful, otherwise, disconnects the connection with the central server, and resumes the communication connection with the central server. The verification of the third verification data is also the verification of the time and the encrypted value, and the method is as described above and will not be described herein again. It should be appreciated that the addition of the registration success request and the third verification data further improves the security of the service communication system of the present invention, and effectively prevents the data in the server from being hacked or stolen.

In addition, the RPC service protocol supports a bidirectional and concurrent mode, the data sending packet and the data returning packet have the same structure and respectively comprise a data packet prefix and a data packet body, wherein the data packet body is represented in a serialization mode, and the data packet prefix comprises at least one of a data identification Flag, a version Ver, a Length, a Header information Header and a custom Context. The following table shows a structural representation of a packet and its formatting data:

identification	Version(s)	Length of	Header information	Custom context	Text
						Flag	Ver	Length	Header	Context	Body
1	1	4	17	Default 0, indefinite	Indefinite article
						C	C	N		a*	a*

Where C is an unsigned character, 1 byte in length; n is unsigned short integer (16 bits, 2 bytes long, big endian); n is unsigned long integer (32 bits, 4 bytes long, big endian); a is a string of non-fixed length packed in NUL bytes.

1) The data Flag may include at least one of a system message request Flag, a request return mode Flag, a message completion Flag, and a browser request Flag, where each Flag may correspond to a different value, and the four flags are described below.

const FLAG _ SYS _ MSG is 1; # message request from System Call

const FLAG _ RESULT _ MODE ═ 2; the # request Return mode indicates that this is an RPC result Return

const FLAG _ FINISH ═ 4; # message complete, used in message Return mode, indicates that RPC returns end of content

const FLAG _ TRANSPORT ═ 8; # forward browser RPC request, indicating that this is a request from the browser

Flag is 1 byte, the above 4 values are currently defined, the return message needs to be incremented by 2 (i.e., Flag _ RESULT _ MODE), otherwise for request MODE, Flag _ FINISH needs to be incremented if the message ends, e.g., $ Flag |2| 4.

Judging whether the current Flag is met

if(2＝＝＝($Flag&2)){

// data Return mode

}

2) The Length is the sum of the lengths of the Header, the Context and the Body, does not include the byte Length occupied by Flag, Ver and the Length, and can cut off the data packet and transmit the data packet in packets according to the Length. Usually, the longest length of the text is recommended not to exceed 0x200000 (i.e. 2097152), and the text content is packetized during packetization, and each packetization still needs other data packet prefix parts and upper parts.

3) The data structure of the Header information Header is shown in the following table, and includes at least one of an application identifier AppId of a requester, a service identifier ServiceId of a requester or a requested party, a request sequence number RequestId, an administrator identifier AdminId, and a custom information length ContextLength. When the header information is packaged back, except that the service identifier can be changed, other contents are all in the original band.

AppId	Service ID	rpc request sequence number	Administrator ID	Self-defined information length
					AppId	ServiceId	RequestId	AdminId	ContextLength
4	4	4	4	1
					N	N	N	N	C

The application identifier is usually the application identifier of the requester, and more than 1000 are the application identifiers of the system. If the RPC packet is the one that initiated the request (Flag &2 value is not 2), the parameter is filled to 0, and the system will automatically fill the current application id when forwarding.

For the service identifier serviceId, when an RPC request is made, the service identifier in the data packet is the requested service ID, the background service management of the console can be logged in to check the corresponding service ID, and the transmission of 0 indicates that the XdApp self-service is requested; when the RPC request is returned, the service ID in the data packet is usually the requestor service ID, for example, 0 may represent the request of the XdApp system, 1 may be the request from the Console browser, and 2 may be the request from the data center. That is, if the service server a wants to initiate a request to the service server B through the central server, the service identifier in the data packet of the request is the service identifier of the requested service server B; and when the service server B returns data to the service server A, the service identifier in the returned data packet is the service identifier of the service server A.

The RPC request sequence number RequestId is a custom value, the value range of the RPC request sequence number RequestId is 0-4294967295), and the original value is returned when the RPC request sequence number RequestId is returned. AdminId is the administrator ID of the request, 0 means that administrator rights are not verified. The default of the custom Context ContextLength is 0 to 255, the length of the Context is marked, and if the custom parameters need to be added, the ContextLength is extended.

4) The custom Context returns this content as it is when the RPC packet is returned.

5) The Body is the content of the RPC request, the Body is the requested Body when the RPC request is made, the Body is the returned content when the RPC is returned, and the default format of the Body content is Hprose serialized data content.

An example of a request inclusion is as follows:

Cs7"sys_reg"a3{i1546998981；s16"xUQjbKiTdfP8yUMN"s40"0a87b73a17c02c0eb74a46858208bc6c67243c12"}

an example of a return inclusion is as follows:

Rm6{s3"app"s4"demo"s4"name"s7"console"s4"time"i1546998981；s4"rand"s16"xUQjbKiTdfP8yUMN"s7"version"s6"v1.1.0"s4"hash"s40"8c2cbfd951f44fe4fb deb3021a6ff185c1be6feb"}z

in addition, according to an embodiment of the present invention, the central server may further open an interface corresponding to the service server, where the interface has an interface connection serial number, so as to receive or forward data through the interface. Based on this, the method 400 may further include a step of data forwarding between the service servers, and the flow thereof is shown in fig. 5. Specifically, the service server sends a data packet to the central server; the central server analyzes the application identifier and the service identifier in the data packet prefix, and determines a second service server corresponding to the application identifier and the service identifier, and an interface and a connection serial number of the second service server in the central server; the central server forwards the data packet to a second service server through the interface, receives a data forwarding result returned by the second service server, and feeds the data forwarding result back to the first service server.

The data forwarding result returned by the service server B also includes a data identifier (indicating that the returned data packet is a data packet of a request return mode class), an application identifier, a service identifier, and the like, and the central server can analyze and forward the identifiers to the corresponding servers. Of course, it is also possible to directly record the original data sender, i.e. the service server a, and directly return the forwarding result message to it. In addition, after receiving the data packet sent by the first service server, the central server may also analyze the data identifier in the data packet prefix, determine what type of data is according to the data identifier, determine that the data identifier is an RPC request if the data identifier is 0 or an unidentified numerical value, and continue to analyze the application identifier and the service identifier in the data packet prefix.

Fig. 6 shows a flow diagram of a teleservice communication method 600, suitable for execution in a central server, according to another embodiment of the invention. As shown in fig. 6, the method begins in step S610.

In step S610, a communication connection request from the service server is received, and a communication connection is established with the service server.

Subsequently, in step S620, a registration request is sent to the service server, and the body of the data packet of the registration request includes the first verification data.

Subsequently, in step S630, the registration data returned by the service server after the first verification data is verified is received, and the data packet body of the registration data includes the application name of the service server and the second verification data.

Finally, in step S640, the registration data is verified, and if the verification is successful, a registration success request is sent to the service server, so that the service server provides the service to the central server after the verification of the registration success request is passed, and a data packet body of the registration success request includes third verification data.

According to an embodiment of the present invention, the method 600 may further include the step of performing data forwarding between a plurality of service servers: receiving a data packet sent by a first service server, and analyzing an application identifier and a service identifier in a data packet prefix; determining a second service server corresponding to the application identifier and the service identifier and an interface of the second service server in a central server; the data packet is forwarded to a second service server through the interface, and a data forwarding result returned by the second service server is received; and feeding back the data forwarding result to the first service server.

Fig. 7 shows a flow diagram of a teleservice communication method 700, suitable for execution in a traffic server, according to another embodiment of the invention. As shown in fig. 7, the method begins in step S710.

In step S710, a communication connection request is sent to the central server, and a communication connection is established therewith.

Subsequently, in step S720, a registration request sent by the central server is received, and the data packet body of the registration request includes the first verification data.

Subsequently, in step S730, the first verification data is verified, and registration data is returned to the central server after the verification is passed, where a data packet body of the registration data includes the application name of the service server and the second verification data.

Subsequently, in step S740, a registration success request sent by the central server after the registration data is successfully verified is received, and the data packet body of the registration success request includes the third verification data.

Finally, in step S750, the registration success request is verified, and if the verification is passed, the service is provided to the central server, otherwise, the communication connection with the central server is disconnected.

Fig. 8 shows a block diagram of the structure of a central server 800 and a service server 900 according to an embodiment of the present invention. The central server includes a first communication connection module 810, a first request sending module 820, a first request returning module 830, and a second request sending module 840. The service server includes a second communication connection module 910, a first request receiving module 920, a first request processing module 930, a second request receiving module 940, and a second request processing module 950.

The first communication connection module 810 is adapted to receive a communication connection request from the service server and establish a communication connection with the service server. The first request sending module 820 is adapted to send a registration request to the service server, where the body of the data packet of the registration request includes the first verification data. The first request returning module 830 is adapted to return the registration data after the first verification data is successfully verified by the service server, and a data packet body of the registration data includes an application name of the service server and the second verification data. The second request sending module 840 is adapted to verify the registration data, and if the verification is successful, send a registration success request to the service server, so that the service server provides the service to the central server after the verification of the registration success request is successful, and a data packet body of the registration success request includes third verification data.

The second communication connection module 910 is adapted to send a communication connection request to the central server, establishing a communication connection therewith. The first request receiving module 920 is adapted to receive a registration request sent by a central server, where a data packet body of the registration request includes first verification data. The first request processing module 930 is adapted to verify the first verification data and return registration data to the central server after the verification is passed, wherein the data packet body of the registration data includes the application name of the service server and the second verification data. The second request receiving module 940 is adapted to receive a registration success request sent by the central server after the registration data is successfully verified, where a data packet body of the registration success request includes third verification data. The second request processing module 950 is adapted to verify the registration success request, and provide the service to the central server if the verification is passed, otherwise, disconnect the communication connection with the central server.

The

methods

600 and 700, the central server 800 and the service server 900 according to the present invention have been disclosed in detail in the description based on fig. 1 to 5, and are not described herein again.

According to the technical scheme of the invention, the central server and the business server establish connection through a transport layer security protocol, and perform service registration through a three-time verification mechanism, so that the security and confidentiality of the service are greatly improved, and the development and deployment of the business server are facilitated.

A4, the method of A1, further comprising the steps of: and if the verification of the registration data fails, sending a registration failure request to the service server, and disconnecting the communication connection with the service server, so that the service server re-requests to connect the central server when receiving the registration failure request.

A5, the method as in a1, wherein the establishing of the communication connection is performed by a secure transport protocol.

A6, the method as in a1, wherein each data packet body is represented in a serialized manner, and the data packet body of the registration data further comprises a service name and/or version of the service server.

A7, the method according to any one of a1-a6, wherein each data packet further comprises a data packet prefix, and the data packet prefix comprises at least one of data identification, version, length, header information and custom context.

A8, the method as in A7, wherein the data identification comprises at least one of a system message request identification, a request return pattern identification, a message completion identification, and a browser request identification.

A9, the method as in a7, wherein the header information includes at least one of an application identification of the requesting party, a service identification of the requesting or requested party, a request sequence number, an administrator identification and a custom information length.

A10, the method of any one of A1-A9, further comprising the steps of: and opening an interface corresponding to the service server, wherein the interface has an interface connection serial number so as to receive or forward data through the interface.

A11, the method as in a10, further comprising the step of data forwarding between a plurality of service servers: receiving a data packet sent by a first service server, and analyzing an application identifier and a service identifier in a data packet prefix; determining a second service server corresponding to the application identifier and the service identifier and an interface of the second service server in the central server; the data packet is forwarded to the second service server through the interface, and a data forwarding result returned by the second service server is received; and feeding back the data forwarding result to the first service server.

A12, the method as in a11, further comprising the steps of, after receiving the data packet sent by the first service server: and analyzing the data identifier in the data packet prefix, and if the identifier is 0 or an unidentified numerical value, continuously analyzing the application identifier and the service identifier in the data packet prefix.

B14, the method as set forth in B13, further comprising the steps of: and receiving a registration failure request sent by the central server after the central server fails to verify the registration data, and requesting to connect the central server again after the central server is disconnected from the communication connection with the service server.

The various techniques described herein may be implemented in connection with hardware or software or, alternatively, with a combination of both. Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.

In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Wherein the memory is configured to store program code; the processor is configured to perform the teleservice communication method of the present invention in accordance with instructions in the program code stored in the memory.

By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer-readable media includes both computer storage media and communication media. Computer storage media store information such as computer readable instructions, data structures, program modules or other data. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. Combinations of any of the above are also included within the scope of computer readable media.

In the description provided herein, algorithms and displays are not inherently related to any particular computer, virtual system, or other apparatus. Various general purpose systems may also be used with examples of this invention. The required structure for constructing such a system will be apparent from the description above. Moreover, the present invention is not directed to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any descriptions of specific languages are provided above to disclose the best mode of the invention.

In the description provided herein, numerous specific details are set forth. It is understood, however, that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be interpreted as reflecting an intention that: that the invention as claimed requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.

Those skilled in the art will appreciate that the modules or units or components of the devices in the examples disclosed herein may be arranged in a device as described in this embodiment or alternatively may be located in one or more devices different from the devices in this example. The modules in the foregoing examples may be combined into one module or may be further divided into multiple sub-modules.

Those skilled in the art will appreciate that the modules in the device in an embodiment may be adaptively changed and disposed in one or more devices different from the embodiment. The modules or units or components of the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or elements of any method or apparatus so disclosed, may be combined in any combination, except combinations where at least some of such features and/or processes or elements are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features included in other embodiments, rather than other features, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments may be used in any combination.

Furthermore, some of the described embodiments are described herein as a method or combination of method elements that can be performed by a processor of a computer system or by other means of performing the described functions. A processor having the necessary instructions for carrying out the method or method elements thus forms a means for carrying out the method or method elements. Further, the elements of the apparatus embodiments described herein are examples of the following apparatus: the apparatus is used to implement the functions performed by the elements for the purpose of carrying out the invention.

As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this description, will appreciate that other embodiments can be devised which do not depart from the scope of the invention as described herein. Furthermore, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the appended claims. The present invention has been disclosed in an illustrative rather than a restrictive sense, and the scope of the present invention is defined by the appended claims.

Claims

1. A teleservice communication method, adapted to be performed in a central server, the method comprising:

receiving a communication connection request of a service server, and establishing communication connection with the service server;

sending a registration request to the service server, wherein a data packet body of the registration request comprises first verification data;

receiving registration data returned by the service server after the first verification data is verified, wherein a data packet body of the registration data comprises an application name and second verification data of the service server;

verifying the registration data, and if the verification is successful, sending a registration success request to the service server so that the service server provides service to the central server after the registration success request is verified, wherein a data packet text of the registration success request comprises third verification data;

wherein the first authentication data includes a registration request time of the center server, a first random number, and a first encrypted value calculated based on the registration request time and the first random number;

the second verification data comprises a registration return time of the service server, a second random number and a second encryption value calculated based on the registration return time and the second random number;

the third verification data comprises registration success time of the service server, a third random number and a third encryption value calculated based on the registration success time and the third random number;

and the first encryption value, the second encryption value and the third encryption value are calculated according to a secret key agreed in advance between the business server and the central server.

2. The method of claim 1, further comprising the steps of:

and if the verification of the registration data fails, sending a registration failure request to the service server, and disconnecting the communication connection with the service server, so that the service server re-requests to connect the central server when receiving the registration failure request.

3. The method of claim 1, wherein the establishing of the communication connection is performed by a secure transport protocol.

4. The method of claim 1, wherein each data packet body is represented in a serialized manner, and the data packet body of the registration data further includes a service name and/or version of the business server.

5. The method of any of claims 1-4, wherein each data packet further comprises a data packet prefix, the data packet prefix comprising at least one of a data identification, a version, a length, header information, and a custom context.

6. The method of claim 5, wherein the data identification comprises at least one of a system message request identification, a request return mode identification, a message completion identification, and a browser request identification.

7. The method of claim 5, wherein the header information comprises at least one of an application identification of the requesting party, a service identification of the requesting or requested party, a request sequence number, an administrator identification, and a custom information length.

8. The method of any one of claims 1-4, further comprising the step of:

and opening an interface corresponding to the service server, wherein the interface has an interface connection serial number so as to receive or forward data through the interface.

9. The method of claim 8, further comprising the step of forwarding data between a plurality of traffic servers:

receiving a data packet sent by a first service server, and analyzing an application identifier and a service identifier in a data packet prefix;

determining a second service server corresponding to the application identifier and the service identifier and an interface of the second service server in the central server;

the data packet is forwarded to the second service server through the interface, and a data forwarding result returned by the second service server is received; and

and feeding back the data forwarding result to the first service server.

10. The method of claim 9, further comprising, after receiving the data packet sent by the first service server, the steps of:

and analyzing the data identifier in the data packet prefix, and if the identifier is 0 or an unidentified numerical value, continuously analyzing the application identifier and the service identifier in the data packet prefix.

11. A teleservice communication method, adapted to be executed in a traffic server, the method comprising:

sending a communication connection request to a central server, and establishing communication connection with the central server;

receiving a registration request sent by the central server, wherein a data packet body of the registration request comprises first verification data;

verifying the first verification data, and returning registration data to the central server after the verification is passed, wherein a data packet body of the registration data comprises an application name of the service server and second verification data;

receiving a registration success request sent by the central server after the registration data is successfully verified, wherein a data packet body of the registration success request comprises third verification data;

verifying the successful registration request, if the successful registration request passes the verification, providing service for the central server, otherwise, disconnecting the communication connection with the central server;

12. The method of claim 11, further comprising the step of:

and receiving a registration failure request sent by the central server after the central server fails to verify the registration data, and requesting to connect the central server again after the central server is disconnected from the communication connection with the service server.

13. A teleservice communication method, comprising:

the service server sends a communication connection request to the central server to establish communication connection with the central server;

the method comprises the steps that a central server sends a registration request to a service server, wherein a data packet body of the registration request comprises first verification data;

the business server verifies the first verification data and returns registration data to a central server after the first verification data is successfully verified, wherein the data packet body of the registration data comprises the application name of the business server and second verification data;

the central server verifies the registration data, and if the verification is successful, a registration success request is sent to the service server, and a data packet body of the registration success request comprises third verification data;

the business server verifies the successful registration request, if the verification is successful, the business server provides business service for the central server, otherwise, the connection with the central server is disconnected;

14. A central server, comprising:

the first communication connection module is suitable for receiving a communication connection request of a service server and establishing communication connection with the service server;

the first request sending module is suitable for sending a registration request to the service server, and a data packet body of the registration request comprises first verification data;

the first request returning module is suitable for receiving registration data returned by the business server after the first verification data is successfully verified, and a data packet body of the registration data comprises an application name and second verification data of the business server; and

the second request sending module is suitable for verifying the registration data, and if the verification is successful, a registration success request is sent to the service server, so that the service server provides service to the central server after the registration success request is verified successfully, and a data packet body of the registration success request comprises third verification data;

15. A traffic server, comprising:

the second communication connection module is suitable for sending a communication connection request to the central server and establishing communication connection with the central server;

the first request receiving module is suitable for receiving a registration request sent by the central server, and a data packet body of the registration request comprises first verification data;

the first request processing module is suitable for verifying the first verification data and returning registration data to the central server after the verification is passed, and a data packet body of the registration data comprises an application name of the service server and second verification data;

the second request receiving module is suitable for receiving a registration success request sent by the central server after the registration data is successfully verified, and a data packet body of the registration success request comprises third verification data;

the second request processing module is suitable for verifying the successful registration request, if the successful registration request passes the verification, the second request processing module provides business service for the central server, and otherwise, the second request processing module disconnects the communication connection with the central server;

16. A server, comprising:

one or more processors;

a memory; and

one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising instructions for performing any of the methods of claims 1-12.

17. A readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by a server, cause the server to perform any of the methods of claims 1-12.

18. A teleservices communication system comprising a central server as claimed in claim 14 and one or more business servers as claimed in claim 15.