CN117956034A - Communication method, device and system based on NETCONF protocol - Google Patents

Abstract

The application provides a communication method, a device and a system based on a NETCONF protocol, which are applied to the technical field of communication. The method may include: the server receives a first call request from the client, the first call request including a first service identification, the first service identification indicating a first service scenario. The server processes the first call request using the first thread, the first thread Cheng Duiying a first traffic scenario. The server receives a second call request from the client, the second call request including a second service identification, the second service identification indicating a second service scenario, the second service scenario being different from the first service scenario. The server processes the second call request by using a second thread, the second thread corresponds to a second service scenario, and the second thread is a parallel thread with the first thread. Based on the method, the server can process call requests corresponding to different scenes in parallel, and communication efficiency can be improved.

Description

Communication method, device and system based on NETCONF protocol

Technical Field

The present application relates to the field of communications technologies, and in particular, to a communications method, apparatus, and system based on a network configuration (network configuration, netcon) protocol.

Background

The netcon f protocol is a network configuration and management protocol based on extensible markup language (extensible markup language, XML) that provides a remote procedure call (Remote Procedure Call, RPC) based mechanism to enable communication between netcon f clients (clients) and netcon f servers (servers). The netcon f protocol may be applied in a software-defined network (SDN) architecture, and the client may manage the server based on the netcon f protocol.

In the netcon protocol, after the netcon client establishes a session with the netcon server, the netcon client may instruct the netcon server to perform some operation through an RPC request. The netcon f server is serially processing the RPC requests and the netcon f server will send RPC responses in exactly the order in which the RPC requests were received.

However, if the number of netcon f client requests is large, the netcon f server receives a large number of RPC requests. Because the netcon server processes RPC requests serially, a large number of RPC requests will backlog, thus making the overall flow of service processing slower and performance worse.

Disclosure of Invention

The application provides a communication method, a device and a system based on a NETCONF protocol, which are used for solving the problem that the communication efficiency of the traditional NETCONF client and a NETCONF server is lower.

In order to achieve the above purpose, the application adopts the following technical scheme:

In a first aspect, a communication method based on the netcon protocol is provided, where the method may be performed by a server, or may be performed by a component of the server, such as a processor, a chip, or a chip system of the server, or may be implemented by a logic module or software that can implement all or part of the functions of the server. The method may include: the server receives a first call request from the client, the first call request including a first service identification, the first service identification indicating a first service scenario. The server processes the first call request using the first thread, the first thread Cheng Duiying a first traffic scenario. The server receives a second call request from the client, the second call request including a second service identification. Wherein the second service identifier indicates a second service scenario, the second service scenario being different from the first service scenario. The server processes the second call request using the second thread. The second thread corresponds to a second service scene, and the second thread and the first thread are parallel threads.

Based on the scheme, the call request corresponding to the service request sent by the client to the server can comprise a service identifier, and the service identifier can indicate a service scene to which the service request belongs. And, the server can allocate threads for processing call requests according to the service scenario. For call requests (such as the first call request and the second call request) corresponding to different service scenarios, the server can use parallel threads to process. The parallel threads work in parallel, so that the method can improve the efficiency of processing the call request by the server, and can improve the communication efficiency between the client and the server.

With reference to the first aspect, in a possible implementation manner, in a case that the server receives the first call request through the first session, the server also receives the second call request through the first session. The first session corresponds to a first thread pool to which both the first thread and the second thread belong.

With reference to the first aspect, in a possible implementation manner, in a case that the server receives the first call request through the first session, the server receives the second call request through the second session, where the second session is different from the first session. The first session corresponds to a first thread pool to which the first thread belongs. The second session corresponds to a second thread pool, and the second thread belongs to the second thread pool.

With reference to the first aspect, in a possible implementation manner, before the server receives the first call request from the client, the method may further include: the server sends first capability information to the client, wherein the first capability information is used for indicating that the server supports parallel transmission. The server receives second capability information from the client, the second capability information indicating that the client supports parallel transmission.

With reference to the first aspect, in one possible implementation manner, the server communicates with the client based on netcon, the server is a netcon server, the client is a netcon client, and the first call request and the second call request belong to RPC requests.

With reference to the first aspect, in one possible implementation manner, the first call request includes a first message identification field, where the first message identification field includes a first portion and a second portion, the first portion is used to carry a message identification of the first call request, and the second portion is used to carry a first service identification.

With reference to the first aspect, in one possible implementation manner, the first call request includes a first service identifier field, where the first service identifier field is used to carry a first service identifier.

With reference to the first aspect, in a possible implementation manner, the method may further include: the server receives a third call request from the client, wherein the third call request comprises a third service identifier, and the third service identifier indicates the first service scene. And, the server processes the third call request using the first thread.

With reference to the first aspect, in a possible implementation manner, in a case that the server receives the first call request through the first session, the server also receives the third call request through the first session.

In a second aspect, a communication method based on the netcon f protocol is provided, where the method may be performed by a client, or may be performed by a component of the client, such as a processor, a chip, or a chip system of the client, or may be implemented by a logic module or software that can implement all or part of the functions of the client. The method may include: the client sends a first call request corresponding to the first service request to the server, wherein the first call request comprises a first service identifier, and the first service identifier indicates a first service scene to which the first service request belongs. The client sends a second call request corresponding to the second service request to the server, wherein the second call request comprises a second service identifier, and the second service identifier indicates a second service scene to which the second service request belongs. Wherein the second service scenario is different from the first service scenario, and the second service identification is different from the first service identification.

With reference to the second aspect, in a possible implementation manner, in a case that the client sends the first call request through the first session, the client also sends the second call request through the first session.

With reference to the second aspect, in a possible implementation manner, in a case that the client sends the first call request through the first session, the client sends the second call request through the second session, where the second session is different from the first session.

With reference to the second aspect, in one possible implementation manner, before the client sends a first call request corresponding to the first service request to the server, the method may further include: the client receives first capability information from the server, the first capability information being used to indicate that the server supports parallel transmission. The client sends second capability information to the server, wherein the second capability information is used for indicating that the client supports parallel transmission.

With reference to the second aspect, in one possible implementation manner, the server communicates with the client based on netcon, the server is a netcon server, the client is a netcon client, and the first call request and the second call request belong to RPC requests.

With reference to the second aspect, in one possible implementation manner, the first call request includes a first message identification field, where the first message identification field includes a first portion and a second portion, the first portion is used to carry a message identification of the first call request, and the second portion is used to carry a first service identification.

With reference to the second aspect, in one possible implementation manner, the first call request includes a first service identifier field, where the first service identifier field is used to carry a first service identifier.

With reference to the second aspect, in a possible implementation manner, in a case that the client sends the first call request through the first session, the method further includes: the client sends a third call request corresponding to a third service request to the server through the first session, wherein the third call request comprises a third service identifier, the third service identifier indicates a first service scene, and the third service request belongs to the first service scene.

In a third aspect, a communication device is provided, which has the functionality to implement the method of the first or second aspect. The functions can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the functions described above.

In a fourth aspect, there is provided a communication apparatus comprising: a processor and a memory; the memory is configured to store computer-executable instructions that, when executed by the communication device, cause the communication device to perform the netcon f protocol-based communication method of any one of the first or second aspects.

In a fifth aspect, there is provided a communication apparatus comprising: a processor; the processor is configured to couple with the memory and execute the netcon f protocol-based communication method according to any one of the first or second aspects according to the instruction after reading the instruction in the memory.

In a sixth aspect, there is provided a computer readable storage medium having instructions stored therein, which when run on a computer, cause the computer to perform the netcon f protocol-based communication method according to any one of the first or second aspects above.

In a seventh aspect, a computer program product comprising instructions is provided which, when run on a computer, causes the computer to perform the netcon f protocol-based communication method of any of the first aspects above.

The technical effects caused by any one of the design manners of the third aspect to the seventh aspect may be referred to as the technical effects caused by the different design manners of the first aspect or the second aspect, and are not repeated herein.

Drawings

Fig. 1 is a schematic diagram of a network architecture of netcon f according to an embodiment of the present application;

fig. 2 is a flow chart of a communication method based on the netcon f protocol according to an embodiment of the present application;

Fig. 3 is a flowchart of a session establishment process between a netcon f client and a netcon f server provided in an embodiment of the present application;

fig. 4 is a flowchart of a netcon f client communicating with a netcon f server according to an embodiment of the present application;

Fig. 5 is a schematic structural diagram of a communication device according to an embodiment of the present application;

Fig. 6 is a schematic structural diagram of another communication device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application. Wherein, in the description of the present application, "/" means that the related objects are in a "or" relationship, unless otherwise specified, for example, a/B may mean a or B; the "and/or" in the present application is merely an association relationship describing the association object, and indicates that three relationships may exist, for example, a and/or B may indicate: there are three cases, a alone, a and B together, and B alone, wherein a, B may be singular or plural. Also, in the description of the present application, unless otherwise indicated, "a plurality" means two or more than two. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or plural. In addition, in order to facilitate the clear description of the technical solution of the embodiments of the present application, in the embodiments of the present application, the words "first", "second", etc. are used to distinguish the same item or similar items having substantially the same function and effect. It will be appreciated by those of skill in the art that the words "first," "second," and the like do not limit the amount and order of execution, and that the words "first," "second," and the like do not necessarily differ. Meanwhile, in the embodiments of the present application, words such as "exemplary" or "such as" are used to mean serving as examples, illustrations or explanations. Any embodiment or design described herein as "exemplary" or "e.g." in an embodiment should not be taken as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion that may be readily understood.

Netcon f: an XML-based network management protocol provides a programmable method for configuring and managing servers. Netcon provides a framework and RPC mechanism by which network administrators and application developers can operate the configuration of servers and obtain server state data from the framework and collection.

Fig. 1 shows a schematic diagram of a netcon f network architecture that employs a client (C1 ient)/server (server) mode, abbreviated as C/S mode, or C/S architecture. The network configuration protocol between the netcon f client and the netcon f server is divided into four layers, namely a secure transmission (secure transport layer) layer, a message layer (MESSAGE LAYER), an operation layer and a content layer (content layer) from bottom to top. Wherein, NETCONF of the content layer is not standardized and is defined by the Yang modeling language. The secure transport layer may include a secure shell protocol (secure shel, SSH), a secure transport layer protocol (transport layer security, TLS), a block extensible exchange protocol (blocks extensible exchange protocol, BEEP) or a secure transport layer protocol (TLS), a simple object access protocol (simple object access protocol, SOAP) or a hypertext transport protocol (hypertext transfer protocol, HTTP), etc. The message layer may include a remote procedure call protocol request instruction < rpc >, a remote procedure call protocol response instruction < rpc-reply >, and a notification instruction < notification >. The operation layer may include an edit instruction < edit-config >, a get instruction < get-config >. The content layer may include configuration data (configuration data), notification data (notification data), etc., and the netcon f may also include other required parameters or protocol instructions, as is not limited herein.

It should be noted that Yang is a data modeling language designed for the netcon f protocol to define a tree data structure.

Clients in the network may manage servers using the netcon f protocol, where clients may act as netcon f clients and servers may act as netcon f servers. Thus, the client and the server form a C/S architecture, and the client may indicate configuration information of the server and acquire status data of the server through a netcon message.

The following describes a specific flow of the communication method based on the netcon f protocol provided by the present application with reference to the accompanying drawings.

Fig. 2 is a schematic flow chart of a communication method based on the netcon f protocol according to an embodiment of the present application, and as shown in fig. 2, the method may include the following steps:

Step 201, the client sends a first call request to the server, and accordingly, the server receives the first call request from the client. The first invocation request includes a first service identification, the first service identification indicating a first service scenario.

The first invocation request may be used to request the server for obtaining service-related data. The first call request carries a first service identifier indicating a first service scenario and can be used for indicating the service scenario corresponding to the data requested to be acquired by the first call request to the server.

Optionally, the first call request may be a call request corresponding to the first service request, and the first call request may be triggered and generated by the first service request. Prior to step 201, the client may obtain a first service request, which may be used to request the client for obtaining service related data. Further, the client may generate a first call request from the first service request, where the first call request requests the server to obtain service-related data.

In the embodiment of the present application, the first call request may include a first service identifier indicating a first service scenario, where the first service scenario is a service scenario to which the first service request belongs. That is, the first call request corresponding to the first service request sent by the client may indicate the first service scenario to which the service corresponding to the first service request belongs. Based on the first service scenario corresponding to the first call request can be identified by the server. In the embodiment of the present application, the server may allocate a thread for processing the first call request according to the service scenario corresponding to the first call request, which is described in detail in the following step 202.

Step 202, the server processes the first call request by using the first thread, and the first thread Cheng Duiying is the first service scenario.

It should be understood that after receiving the first call request, the server may obtain the first service identifier carried by the first call request. Alternatively, the server may allocate a thread that processes the first call request according to the first traffic scenario indicated by the first traffic identification.

As a possible implementation manner, the server does not receive other call requests corresponding to the first service scenario before receiving the first call request. In other words, the first call request is a call request corresponding to the first service scenario received by the server for the first time. In this case, the server may allocate an existing thread or newly create a thread to process the first call request. The server may also associate a thread that processes the first call request with the first business scenario.

As another possible implementation manner, the server receives other call requests corresponding to the first service scenario before receiving the first call request. In this case, there are threads in the server that have processed other call requests corresponding to the first service scenario, and thus, the client may process the first call request using threads that have processed other call requests corresponding to the first service scenario. In other words, in the embodiment of the present application, the call requests corresponding to the same service scenario should be processed using the same thread.

In the embodiment of the present application, a thread that processes a first call request may be referred to as a first thread.

Step 203, the client sends a second call request to the server, and accordingly, the server receives the second call request from the client. The second call request comprises a second service identifier, the second service identifier indicates a second service scene, and the second service scene is different from the first service scene.

The second invocation request may be triggered by a second service request. The second service request and the second call request may refer to the previous descriptions related to the first service request and the first call request, which are not described herein.

The second service scene indicated by the second service identifier in the second call request is the service scene to which the service corresponding to the second service request belongs.

Step 204, the server processes the second call request using the second thread. The second thread corresponds to a second service scene, and the second thread and the first thread are parallel threads.

It should be understood that after receiving the second call request, the server may obtain the second service identifier carried by the second call request. Alternatively, the server may also allocate a thread for processing the second call request according to the second service scenario indicated by the second service identifier. The manner in which the processing thread of the second call request is allocated may refer to the related description of the manner in which the processing thread of the first call request is allocated in step 202, which is not described herein.

Since the second traffic scenario is different from the first traffic scenario, the thread that processes the second call request may be different from the thread that processes the first call request. In the embodiment of the application, the thread for processing the second call request can be called a second thread, so that the second thread can correspond to a second service scene, and the second thread is a parallel thread with the first thread.

From the above steps, in the embodiment of the present application, call requests corresponding to different service scenarios may be processed in parallel by the server using different threads.

In addition, in the embodiment of the application, for the call requests corresponding to the same service scene, the server can use the same thread for serial processing. It should be appreciated that different service requests of the same service scenario may be associated, and thus, different call requests corresponding to the same service scenario may also be associated, and the same thread processing may be employed to ensure that the service is performed correctly.

Optionally, the communication method based on the netcon f protocol may further include:

Step 205, the server receives a third call request from the client, where the third call request includes a third service identifier, and the third service identifier indicates the first service scenario.

Optionally, the third call request may be a call request corresponding to a third service request, where the third service request may belong to the first service scenario, and thus the third call request may include a third service identifier indicating the first service scenario.

Step 206, the server processes the third call request using the first thread.

In the embodiment of the application, as the third call request corresponds to the same service scenario (first service scenario) as the first call request, the server can process different call requests corresponding to the first service scenario by using the same thread.

In summary, in the communication method based on the netcon protocol provided by the present application, the call request corresponding to the service request sent by the client to the server may include a service identifier, where the service identifier may indicate a service scenario to which the service request belongs. And, the server can allocate threads for processing call requests according to the service scenario. For call requests (such as the first call request, the second call request or the third call request) corresponding to different service scenarios, the server can use parallel threads to process. The parallel threads work in parallel, so that the method can improve the efficiency of processing the call request by the server, and can improve the communication efficiency between the client and the server.

It should be understood that the present application provides a communication method based on the netcon f protocol, so that the above client may be referred to as a netcon client, and the server may be referred to as a netcon server. Therefore, the communication method based on the NETCONF protocol provided by the application can fully utilize the processing capacities of the NETCONF client and the NETCONF server, and improve the communication performance. For the concurrent scene of the service, the throughput of the NETCONF client and the NETCONF server can be adjusted to realize dynamic capacity expansion and contraction, and the flexibility is better.

Alternatively, the call request (e.g., the first call request, the second call request, and the third call request) may be an RPC request. The RPC request may be obtained after the client inputs the acquired service request into the netcon f Yang model. And processing the service request message by a NETCONF Yang model to obtain a corresponding RPC request message. In the embodiment of the application, the service identifier can be carried by inputting the service request message into the RPC request message obtained by the NETCONF Yang model. The traffic scene identification may be considered as added by the netcon f Yang model, which may be preconfigured. Compared with the prior art, the application correspondingly improves the NETCONF Yang model in the client, so that the RPC request message can carry the service identifier for indicating the service scene.

Optionally, compared with the prior art, the application also improves the format of the RPC request message to a certain extent, so that the RPC request message can carry the service identifier indicating the service scene.

As a possible implementation manner, compared with the RPC request message in the prior art, the present application can extend a message identifier (message-id) field in the RPC request message, so that the message identifier field can include both a message identifier and a service identifier. For example, the message identification field may include a first portion that may be a service identification and a second portion that may be a message identification; or the first part may be a message identification and the second part may be a service identification. Alternatively, the first portion and the second portion may be separated using special characters to distinguish. Alternatively, the client and server may pre-define the message format of the RPC request in advance so that the server can identify the first and second portions of the message identification field in the RPC request.

By way of example, the message format of the RPC request provided by the embodiment of the present application may be as follows:

The value of the message-id field is "1111_01", the value "1111" before the underline may be regarded as a first portion, the value "01" after the underline may be regarded as a second portion, 1111 may be a service identifier corresponding to the RPC request, and 01 may be a message identifier of the RPC request.

As another possible implementation manner, compared with the RPC request message in the prior art, the present application may add a service-id (service-id) field to the RPC request message, where the service-id field is used to carry a service identifier. Alternatively, the client and server may pre-define the message format of the RPC request in advance so that the server can identify the service identification field in the RPC request.

By way of example, the message format of the RPC request provided by the embodiment of the present application may be as follows:

The message-id field may also include a service-id field before the message-id field, where the value "1111" of the service-id field may be the service identifier.

The first call request, the second call request, or the third call request in the above embodiment may be RPC requests, which may be implemented based on the above two implementations.

Optionally, the first call request may include a first message identification field, and the first message identification field may include a first portion for carrying a message identification of the first call request and a second portion for carrying a first service identification. Or the first invocation request may include a first service identification field, where the first service identification field is used to carry the first service identification.

Optionally, the second call request may include a second message identification field, and the second message identification field may include a first portion for carrying a message identification of the second call request and a second portion for carrying the first service identification. Or the second invocation request may include a second service identification field, the second service identification field being for carrying a second service identification.

Optionally, the third call request may include a third message identification field, and the third message identification field may include a first portion for carrying a message identification of the third call request and a second portion for carrying a third service identification. Or the third call request may include a third service identification field, where the third service identification field is used to carry a third service identification.

In the embodiment of the application, a session can be established between the client and the server, and the client can send a call request to the server through the session. When the client sends a call request (such as the first call request, the second call request or the third call request), the session for sending the call request can be selected according to the service scenario corresponding to the call request.

Optionally, because the service identifier indicating the service scenario is carried in the call request generated by the client, before the client sends the call request, the client may first read the service identifier in the call request, and then select the session for sending the call request according to the service identifier.

Optionally, the call requests corresponding to the same service scenario may be transmitted through the same session. It should be appreciated that different service requests for the same service scenario may be associated, and thus, different call requests corresponding to the same service scenario may also be associated. Different call requests corresponding to the same service scene are sent by using the same session, so that the call requests corresponding to the same service scene can be ensured to be sent in series, and time sequence errors are avoided.

Optionally, call requests corresponding to different service scenarios may be sent through the same session, or may be sent through different sessions, which is not limited by the present application.

As a possible implementation manner, the server receives other service requests corresponding to the first service scenario before receiving the first service request, so that other call requests corresponding to the first service scenario are sent. In this case, there is a session between the client and the server, where other call requests corresponding to the first service scenario are sent, and then the client may send the first call request using the session corresponding to the first service scenario.

Of course, if the server does not receive other service requests of the first service scenario before receiving the first service request, other call requests corresponding to the first service scenario are not sent. In other words, the first service request is a service request belonging to the first service scenario, which is received by the client for the first time, and the first call request is a call request corresponding to the first service scenario, which is sent by the server for the first time. In this case, the client may arbitrarily allocate a session for transmitting the first call request. And, the client may associate the session that sent the first invocation request with the first business scenario.

As a possible implementation manner, the server receives other service requests corresponding to the second service scenario before receiving the second service request, so that other call requests corresponding to the second service scenario are sent. In this case, there is a session between the client and the server, in which other call requests corresponding to the second service scenario are sent, so that the client may send the second call request using the session corresponding to the second service scenario.

Of course, if the server does not receive other service requests of the second service scenario before receiving the second service request, other call requests corresponding to the second service scenario are not sent. In other words, the second service request is a service request belonging to the second service scenario, which is received by the client for the first time, and the second call request is a call request corresponding to the second service scenario, which is sent by the server for the first time. In this case, the client may arbitrarily allocate a session for sending the second call request. And, the client may associate the session that sent the second invocation request with the second traffic scenario.

As a possible implementation manner, since the second call request is different from the service scenario corresponding to the first call request, the second call request may be sent through the same session as the first call request, or the second call request may be sent through a session different from the first call request.

For example, the first call request and the second call request may each be transmitted over a first session between the client and the server. The first session may correspond to a first thread pool, the first thread that processes the first call request and the second thread that processes the second call request being two parallel threads in the first thread pool.

As another example, the first invocation request may be transmitted over a first session between the client and the server, and the second invocation request may be transmitted over a second session between the client and the server, the second session being different from the first session. The first session may correspond to a first thread pool to which the first thread that processes the first call request belongs. The second session may correspond to a second thread pool to which the second thread that processes the second call request belongs. The first thread pool is parallel to the second thread pool.

As a possible implementation, since the third call request and the first call request correspond to the same service scenario (first service scenario), the third call request and the first call request may be sent through the same session between the client and the server.

For example, the first call request and the third call request may each be transmitted over a first session between the client and the server.

Optionally, before the step 201, the method may further include a step 207 and a step 208, and the order of the step 207 and the step 208 is not limited in the present application.

Step 207, the server sends the first capability information to the client, and accordingly, the client receives the first capability information from the server. The first capability information is used to indicate that the server supports parallel transmission.

Step 208, the client sends the first capability information to the server, and accordingly, the server receives the second capability information from the client. The second capability information is used to indicate that the client supports parallel transmission.

The capability information interaction of step 207 and step 208 is passed so that the client and the server determine that the other side supports parallel transmission. Under the condition that the client side and the server carry out capability information interaction and both sides support parallel transmission, the client side and the server are determined to support parallel transmission: the client may generate and send a call request (e.g., a first call request, a second call request, or a third call request) in the manner described above in steps 201 through 206, and the server may process the call request in the manner described above in steps 201 through 206.

Alternatively, the first capability information and the second capability information may correspond to a codec manner of the call request. Under the condition that the client side and the server carry out capability information interaction and both sides support parallel transmission, the client side and the server are determined to support parallel transmission: the client can generate and send the call request by adopting the coding mode corresponding to the capability information, and the server can receive and process the call request by adopting the decoding mode corresponding to the capability information.

Alternatively, the client and server may interact with the capability information during the establishment of the session.

As a possible implementation, fig. 3 shows a flowchart of a process for establishing a session between a client and a server, which may include the following steps.

Step 301, a client initiates an SSH connection with a server.

Step 302, the server sends hello message to the client, where the hello message is used to indicate a capability set of the server.

In the embodiment of the present application, the capability set of the server may include the first capability information, and the first capability information may indicate that the server supports parallel transmission.

After receiving the hello message from the server, the client can learn the capability set of the server, thereby learning the first capability information. Further, the client may determine that subsequent communications with the server may be transmitted in parallel.

Step 303, the client sends a hello reply (hello reply) message to the server, where the hello reply is used to indicate the capability set of the client. So far, the client and the server complete hello message handshake, and the session is successfully established.

In the embodiment of the present application, the capability set of the client may include the second capability information, where the second capability information may indicate that the client supports parallel transmission.

After receiving the hello message from the client response, the server can acquire the capability set of the client, thereby acquiring the second capability information. Further, the server may determine that subsequent communications with the client may be transmitted in parallel.

Optionally, after the server interacts the capability information with the client and determines that both sides support parallel transmission, the server may create multiple buffers (buffers) for buffering call requests received by the server from the session. Subsequently, the thread needs to read the call request to be processed from the buffer.

Optionally, after the server obtains the call request, the server may allocate a buffer storing the call request according to the service identifier in the call request. As a possible implementation manner, the service identifiers may be in one-to-one correspondence with buffers, call requests of different service identifiers are stored in different buffers, and call requests of the same service identifier are stored in the same buffer.

Alternatively, threads in the server may be in one-to-one correspondence with buffers, each thread handling call requests in its corresponding buffer. And because the service identifiers can be in one-to-one correspondence with the buffers, the service identifiers are also in one-to-one correspondence with the threads. Thus, call requests corresponding to the same service identifier can be allocated to the same thread process, and call requests corresponding to different service identifiers can be allocated to different thread processes.

Based on the corresponding relation among the service identifier, the buffer and the thread, the server can realize parallel processing of the call request. Moreover, it should be understood that the service identifier indicates a service scenario, so that call requests corresponding to different service scenarios are stored in different buffers, and the call request messages stored in different buffers have no dependency relationship. Therefore, the parallel processing is consistent with the business processing flow and does not have errors.

According to the above method, fig. 4 shows a flowchart of a client communicating with a server. As shown in fig. 4, a client may obtain multiple service requests (e.g., service request a, service request B, service request C, and service request D), where the multiple service requests may enter a connection pool of the client, and the connection pool may output multiple RPC requests (e.g., RPC request A, RPC request B, RPC request C and RPC request D) corresponding to the multiple service requests. The multiple RPC requests output by the connection pool in the client may be transmitted to the server through sessions between the client and the server (e.g., session 1 and session 2 in fig. 4). RPC request a and RPC request C may be transmitted via session 1, and RPC request B and RPC request D may be transmitted via session 2. The RPC request, after arriving at the server, first enters the connection pool of the server as well. Subsequently, the server may assign RPC requests in the connection pool to thread processing in a thread pool (e.g., thread pool 1 and thread pool 2 in fig. 4). Thread pool 1 corresponds to session 1 so that RPC request a and RPC request C can be assigned to threads in thread pool 1 for processing. Thread pool 2 corresponds to session 2 so that RPC request B and RPC request D can be assigned to threads in thread pool 2 for processing.

Alternatively, in the processing flow corresponding to fig. 4, the server may store the RPC request A, RPC request B, RPC request C and the RPC request D in different buffers, and the processing thread reads the RPC request from the buffer for processing.

Alternatively, the method performed by the server may be performed by a component of the server, for example, a processor, a chip, or a chip system of the server, or may be implemented by a logic module or software that can implement all or part of the functions of the server.

Alternatively, the method performed by the client may be performed by a component of the client, for example, a processor, a chip, or a chip system of the client, or may be implemented by a logic module or software that can implement all or part of the functions of the client.

Optionally, the communication method based on the netcon protocol provided by the present application may be applied to a software defined network (software defined network, SDN), where the client may be a software client in the SDN, the client may not be a specific physical device, and the functions of the client may be implemented by hardware structures such as a processor and a memory. In addition, the server may not be a specific physical device, but may be implemented by a part of hardware structures and software definitions (for example, a cloud server). For this scenario, the above method is still applicable and is described herein in detail.

Alternatively, the client and the server in the embodiment of the present application may adopt the composition structure shown in fig. 5 or include the components shown in fig. 5. Fig. 5 is a schematic structural diagram of a communication device 50 according to an embodiment of the present application, where, as shown in fig. 5, the communication device 50 includes one or more processors 501, a communication line 502, and at least one communication interface (fig. 5 is only an example and includes a communication interface 503, and a processor 501 is illustrated as an example), and optionally includes a memory 504.

The processor 501 may be a general purpose central processing unit (central processing unit, CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the programs of the present application.

The communication line 502 may include a pathway for communication between different components.

The communication interface 503 may be a transceiver module for communicating with other devices or communication networks, such as ethernet, RAN, wireless local area network (wireless local area networks, WLAN), etc. For example, the transceiver module may be a device such as a transceiver, or the like. Optionally, the communication interface 503 may also be a transceiver circuit located in the processor 501, so as to implement signal input and signal output of the processor.

The memory 504 may be a device having a memory function. For example, but not limited to, a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (random access memory, RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (ELECTRICALLY ERASABLE PROGRAMMABLE READ-only memory, EEPROM), a compact disc read-only memory (compact disc read-only memory) or other optical disk storage, optical disk storage (including compact discs, laser discs, optical discs, digital versatile discs, blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory may be self-contained and coupled to the processor via communication line 502. The memory may also be integrated with the processor.

The memory 504 is used for storing computer-executable instructions for implementing the inventive arrangements, and is controlled by the processor 501 for execution. The processor 501 is configured to execute computer-executable instructions stored in the memory 504, thereby implementing the netcon f protocol-based communication method provided in the embodiment of the present application.

Alternatively, in the embodiment of the present application, the processor 501 may perform the functions related to the processing in the communication method provided in the embodiment of the present application, where the communication interface 503 is responsible for communicating with other devices or communication networks, and the embodiment of the present application is not limited in particular.

Alternatively, the computer-executable instructions in the embodiments of the present application may be referred to as application program codes, which are not particularly limited in the embodiments of the present application.

In a particular implementation, as one embodiment, processor 501 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 5.

In a particular implementation, as one embodiment, the communication device 50 may include a plurality of processors, such as processor 501 and processor 507 in fig. 5. Each of these processors may be a single-core processor or a multi-core processor. The processor herein may include, but is not limited to, at least one of: a central processing unit (central processing unit, CPU), microprocessor, digital Signal Processor (DSP), microcontroller (microcontroller unit, MCU), or artificial intelligence processor, each of which may include one or more cores for executing software instructions to perform operations or processes.

In a specific implementation, as an embodiment, the communication apparatus 50 may further include an output device 505 and an input device 506. The output device 505 communicates with the processor 501 and may display information in a variety of ways. For example, the output device 505 may be a Liquid Crystal Display (LCD) CRYSTAL DISPLAY, a Light Emitting Diode (LED) display device, a Cathode Ray Tube (CRT) display device, or a projector (projector), or the like. The input device 506 is in communication with the processor 501 and may receive user input in a variety of ways. The communication device 50 described above may also be referred to as a communication device, and may be a general-purpose device or a dedicated device. For example, the communication device 50 may be a desktop computer, a portable computer, a web server, a personal computer (PDA), a mobile phone, a tablet computer, a wireless terminal device, an embedded device, or a device having a similar structure as in fig. 5. Embodiments of the present application are not limited in the type of communication device 50.

Alternatively, in the above embodiment of the method, the processor 501 in the communication device 50 shown in fig. 5 may call the application code stored in the memory 504 to instruct the client to execute the action of the client, and the processor 501 in the communication device 50 shown in fig. 5 may call the application code stored in the memory 504 to instruct the server to execute the action of the server.

Optionally, the embodiment of the application also provides another communication device, which can be used for implementing the various methods. The communication device may be a client in the above method embodiment, or a device including the client, or a component for implementing the client. Or the communication device may be a server in the above method embodiment, or a device including the above server, or a means for implementing the server. It will be appreciated that the communication device, in order to achieve the above-described functions, comprises corresponding hardware structures and/or software modules performing the respective functions. Those of skill in the art will readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The embodiment of the application can divide the functional modules of the communication device according to the embodiment of the method, for example, each functional module can be divided corresponding to each function, or two or more functions can be integrated in one processing module. The integrated modules may be implemented in hardware or in software functional modules. It should be noted that, in the embodiment of the present application, the division of the modules is schematic, which is merely a logic function division, and other division manners may be implemented in actual implementation.

Fig. 6 shows a schematic structural diagram of a communication device 60. The communication device 60 may include a transceiver module 601 and a processing module 602. The transceiver module 601 may also be referred to as a transceiver unit, and may be, for example, a transceiver circuit, a transceiver, or a communication interface.

Taking the communication device 60 as the server in the above method embodiment as an example:

The transceiver module 601 may be configured to receive a first call request from a client, where the first call request includes a first service identifier, and the first service identifier indicates a first service scenario. The processing module 602 may be configured to process a first call request using a first thread, a first thread Cheng Duiying, and a first traffic scenario. The transceiver module 601 may be further configured to receive a second call request from the client, where the second call request includes a second service identifier. Wherein the second service identifier indicates a second service scenario, the second service scenario being different from the first service scenario. The processing module 602 may be further configured to process a second call request using a second thread; the second thread corresponds to a second service scene, and the second thread and the first thread are parallel threads.

The transceiver module 601 is further configured to send first capability information to the client before the transceiver module 601 receives the first call request from the client, where the first capability information is used to indicate that the server supports parallel transmission. And, the transceiver module 601 is further configured to receive second capability information from the client, where the second capability information is used to indicate that the client supports parallel transmission.

Optionally, the transceiver module 601 may be further configured to receive a third call request from the client, where the third call request includes a third service identifier, and the third service identifier indicates the first service scenario. The processing module 602 may also be configured to process the third call request using the first thread.

Taking the communication device 60 as the client in the above method embodiment as an example:

The transceiver module 601 may be configured to send a first call request corresponding to a first service request to a server, where the first call request includes a first service identifier, and the first service identifier indicates a first service scenario to which the first service request belongs. The transceiver module 601 may be further configured to send a second call request corresponding to the second service request to the server, where the second call request includes a second service identifier, and the second service identifier indicates a second service scenario to which the second service request belongs. Wherein the second service scenario is different from the first service scenario, and the second service identification is different from the first service identification.

Optionally, before the transceiver module 601 sends the first call request corresponding to the first service request to the server, the transceiver module 601 may be further configured to receive first capability information from the server, where the first capability information is used to indicate that the server supports parallel transmission. And, the transceiver module 601 may be further configured to send second capability information to the server, where the second capability information is used to indicate that the client supports parallel transmission.

Optionally, the transceiver module 601 may be further configured to send a third call request corresponding to a third service request to the server, where the third call request includes a third service identifier. The third service belongs to the first service scene, and the third service identifier indicates the first service scene.

It should be noted that, all relevant contents of each step related to the above method embodiment may be cited to the functional description of the corresponding functional module, which is not described herein. Since the communication device 60 provided in this embodiment can perform the above-mentioned communication method, the technical effects obtained by the communication device can be referred to the above-mentioned method embodiment, and will not be described herein.

Alternatively, the server or the client in the embodiments of the present application may also be referred to as a communication apparatus, which may be a general-purpose device or a special-purpose device, which is not specifically limited in the embodiments of the present application.

In the present embodiment, the communication device 60 is presented in a form in which the respective functional modules are divided in an integrated manner. A "module" herein may refer to a particular ASIC, an electronic circuit, a processor and memory that execute one or more software or firmware programs, an integrated logic circuit, and/or other device that can provide the described functionality. In a simple embodiment, one skilled in the art will appreciate that the communication device 60 may take the form of the communication device 50 shown in fig. 5.

For example, the processor 501 in the communication apparatus 50 shown in fig. 5 may cause the communication apparatus 50 to execute the communication method based on the netcon f protocol in the above-described method embodiment by calling the computer-executable instructions stored in the memory 504.

Specifically, the functions/implementation of the transceiver module 601 and the processing module 602 in fig. 6 may be implemented by the processor 501 in the communication device 50 shown in fig. 5 invoking computer executable instructions stored in the memory 504. Or the function/implementation of the transceiver module 601 in fig. 6 may be implemented through the communication interface 503 in the communication device 50 shown in fig. 5, and the function/implementation of the processing module 602 in fig. 6 may be implemented by the processor 501 in the communication device 50 shown in fig. 5 invoking a computer execution instruction stored in the memory 504.

It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

In the several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interface, indirect coupling or communication connection of devices or units, electrical, mechanical, or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using a software program, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device including one or more servers, data centers, etc. that can be integrated with the medium. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (Solid STATE DISK, SSD)), etc.

As used herein, the terms "component," "module," "system" and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, or software in execution. For example, the components may be, but are not limited to: a process running on a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of example, both an application running on a computing device and the computing device can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Furthermore, these components can execute from various computer readable media having various data structures thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the internet with other systems by way of the signal).

The present application may take form in various aspects, embodiments or features around a system that may include a plurality of devices, components, modules, etc. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. Furthermore, combinations of these schemes may also be used.

In addition, in the embodiments of the present application, the term "exemplary" is used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the term use of an example is intended to present concepts in a concrete fashion.

In the embodiment of the present application, information, signals, messages, channels may be mixed in some cases, and it should be noted that the meaning of the expression is consistent when the distinction is not emphasized. "of", "corresponding (corresponding, relevant)" and "corresponding (corresponding)" are sometimes used in combination, and it should be noted that the meaning of the expression is consistent when the distinction is not emphasized. "System" and "network" are sometimes used interchangeably, and are intended to be synonymous when de-emphasizing their distinction, e.g., "communication network" refers to "communication system".

The network architecture and the service scenario described in the embodiments of the present application are for more clearly describing the technical solution of the embodiments of the present application, and do not constitute a limitation on the technical solution provided by the embodiments of the present application, and those skilled in the art can know that, with the evolution of the network architecture and the appearance of the new service scenario, the technical solution provided by the embodiments of the present application is applicable to similar technical problems.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (15)

1. A communication method based on a network configuration netcon protocol, the method comprising:

The method comprises the steps that a server receives a first call request from a client, wherein the first call request comprises a first service identifier, and the first service identifier indicates a first service scene;

the server processes the first call request using a first thread, the first thread Cheng Duiying a first business scenario;

The server receives a second call request from the client, wherein the second call request comprises a second service identifier; wherein the second service identifier indicates a second service scenario, the second service scenario being different from the first service scenario;

The server processes the second call request using a second thread; the second thread corresponds to the second service scene, and the second thread and the first thread are parallel threads.

2. The method of claim 1, wherein, in the event that the server receives the first call request over a first session, the server also receives the second call request over the first session; the first session corresponds to a first thread pool to which both the first thread and the second thread belong.

3. The method of claim 1, wherein the server receives the second call request through a second session, the second session being different from the first session, if the server receives the first call request through a first session; the first session corresponds to a first thread pool to which the first thread belongs; the second session corresponds to a second thread pool, and the second thread belongs to the second thread pool.

4. A method according to any of claims 1-3, wherein before the server receives the first call request from the client, the method further comprises:

the server sends first capability information to the client, wherein the first capability information is used for indicating that the server supports parallel transmission;

The server receives second capability information from the client, the second capability information being used to indicate that the client supports parallel transmission.

5. The method of any of claims 1-4, wherein the server communicates with the client based on a network configuration protocol netcon f, the first call request and the second call request belonging to a remote procedure call RPC request.

6. The method of claim 5, wherein the first invocation request includes a first message identification field including a first portion for carrying a message identification of the first invocation request and a second portion for carrying the first traffic identification.

7. The method of claim 5, wherein the first invocation request includes a first service identification field, the first service identification field for carrying the first service identification.

8. The method according to any one of claims 1-7, further comprising:

the server receives a third call request from the client, wherein the third call request comprises a third service identifier, and the third service identifier indicates the first service scene;

the server processes the third call request using the first thread.

9. The method according to any of claims 1-7, wherein in case the server receives the first call request via a first session, the server also receives the third call request via the first session.

10. A communication method based on a network configuration netcon protocol, the method comprising:

The method comprises the steps that a client sends a first call request corresponding to a first service request to a server, wherein the first call request comprises a first service identifier, and the first service identifier indicates a first service scene to which the first service request belongs;

The client sends a second call request corresponding to a second service request to the server, wherein the second call request comprises a second service identifier, and the second service identifier indicates a second service scene to which the second service request belongs;

Wherein the second service scenario is different from the first service scenario, and the second service identifier is different from the first service identifier.

11. The method of claim 10, wherein in the event that the client sends the first call request over a first session, the client also sends the second call request over the first session.

12. The method of claim 10, wherein the client sends the second invocation request over a second session, the second session being different from the first session, in the event that the client sends the first invocation request over a first session.

13. The method according to claim 11 or 12, wherein in case the client sends the first call request over a first session, the method further comprises:

The client sends a third call request corresponding to a third service request through the first session, wherein the third call request comprises a third service identifier, the third service identifier indicates the first service scene, and the third service request belongs to the first service scene.

14. A communication device, the communication device comprising: a processor and a memory;

The memory is configured to store computer-executable instructions that, when executed by the processor, cause the communication device to perform the method of any of claims 1-9 or 10-13.

15. A computer readable storage medium, having stored thereon a computer program which, when executed by a computer, causes the computer to perform the method of any of claims 1-9 or 10-13.