WO2012034496A1 - 一种异步通信方法及系统 - Google Patents
一种异步通信方法及系统 Download PDFInfo
- Publication number
- WO2012034496A1 WO2012034496A1 PCT/CN2011/079473 CN2011079473W WO2012034496A1 WO 2012034496 A1 WO2012034496 A1 WO 2012034496A1 CN 2011079473 W CN2011079473 W CN 2011079473W WO 2012034496 A1 WO2012034496 A1 WO 2012034496A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- server
- transaction
- processing
- client
- request
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/567—Integrating service provisioning from a plurality of service providers
Definitions
- the present invention relates to communication interaction technologies, and in particular, to a transaction state based asynchronous communication method and system. Background technique
- One step operation That is to say, in this simple synchronous interaction mode, both parties need to wait for the processing result of the peer end to continue the subsequent processing. In this way, if the network is jittery or the processing speed of the peer is slow, the processing efficiency of the local end is reduced, which seriously affects the quality of service.
- the other is to use nested asynchronous mode, which allows the client to send a request and wait for the server to return a response, then send the next request, and so on to form a nested mode.
- the client sends a service request 1 to the server.
- the client can continue to send the service request 2 to the server.
- the client can also Continue to send the service request 3 to the server.
- the service request 1 is the first layer and the outermost layer
- the service request 2 is the second layer and belongs to the middle layer
- the service request 3 is the third layer and the innermost layer.
- the nested asynchronous method can continuously send multiple requests, when receiving the response, the response of the service request 3, the response of the service request 2, and the response of the service request 1 must be sequentially received, so that the subsequent processing can be continued in sequence. That is, it needs to be introverted
- the outer layer is processed sequentially, that is: only the inner layer is released, and the adjacent next layer can be processed. If the response of the current layer is not received, even if other layers are received, the processing cannot be performed, which not only greatly increases the number of Service processing time reduces service throughput and reduces service quality.
- there are certain restrictions on the number of nested layers because too many nesting layers will cause processing. The ability has been greatly reduced, and even the entire system is paralyzed. Summary of the invention
- the main object of the present invention is to provide an asynchronous communication method and system, which can not only realize asynchronous interaction, but also reduce the impact of network performance fluctuations on communication services and improve service quality.
- the present invention provides an asynchronous communication method, including:
- the server After receiving each request from the client, the server generates a transaction and assigns a unique transaction number, and sends the service requested by the client to the corresponding collaborative server for processing;
- the server receives the other requests from the client, and waits for the processing response returned by the cooperating server. After receiving the processing response returned by the cooperating server, the server finds the corresponding transaction according to the transaction number, completes the subsequent processing, and returns the processing result to the client. .
- the method further includes: the server saves the current transaction state; correspondingly, after the service requested by the client is sent to the collaborative server, the method further includes : The server updates the transaction status.
- the method after receiving the processing response returned by the collaborative server, the method further includes: the server parsing the processing response, extracting the transaction number in the processing response, and updating the transaction status.
- the method further includes: the client presenting the received processing result.
- the number of the coordinated server ends is multiple.
- the present invention also provides an asynchronous communication system, including: a client, a server, and a collaborative server;
- the client is configured to send a request to the server, request the server to perform service processing, and receive a service processing result;
- the server is configured to receive a request from the client, generate a transaction for each request, and allocate a transaction number, send the service that the client needs to process to the coordinated server for processing, continue to receive other requests from the client, and wait for the coordinated server. Processing the response; after receiving the processing response, finding the corresponding transaction according to the transaction number, completing the subsequent processing and returning the processing result to the client; the collaborative server, for receiving the collaborative processing request sent by the server, completing the client Request processing of the business, and return a processing response to the server.
- the server is further configured to save a transaction state of a transaction and update a transaction state.
- the server includes a data transceiver manager and a transaction state manager; wherein the data transceiver manager is configured to complete data interaction between the server and the client and the collaboration server;
- the transaction state manager is configured to generate a transaction for each request and assign a unique transaction number; extract the transaction number in the processing response returned by the collaborative server, query the corresponding transaction according to the transaction number, and complete subsequent processing; The transaction corresponding to the transaction is deleted and the transaction number is deleted after it is processed; it is also used to save the transaction status and update the transaction status.
- the client is further configured to display the received processing result.
- the asynchronous communication method and system provided by the present invention completes service processing by the collaborative server auxiliary server, and the server can continuously receive the request of the client, generate a transaction and assign a unique transaction number after receiving each request, and The service requested for processing is sent to the corresponding collaborative server for processing; after receiving the processing result returned by the collaborative server, the corresponding transaction is found according to the transaction number, the subsequent processing is completed, and the processing result is returned to the client.
- the server and the client can interact with each other through a transaction-based asynchronous manner, and process and manage various types of services requested by the client by establishing a transaction and assigning a transaction number, thereby effectively reducing network performance fluctuations.
- the communication interaction parties do not need to receive the response immediately, and do not need to process in order, and the server receives any service processing response from the coordinated server, and can find the transaction number according to the transaction number. The corresponding transaction continues to be processed, so that the server can process multiple services at the same time, which can effectively improve service throughput and improve service quality and processing capability.
- FIG. 1 is a schematic flowchart of an implementation process of an asynchronous communication method according to the present invention
- FIG. 2 is a schematic diagram showing the structure of an asynchronous communication system according to the present invention. detailed description
- the basic idea of the present invention is: the server generates a transaction and assigns a unique transaction number after receiving each request from the client, and sends the service requested by the client to the corresponding collaborative server for processing; receiving the coordinated server After the returned processing response, the server finds the corresponding transaction according to the transaction number, completes the subsequent processing, and returns the processing result to the client.
- FIG. 1 is a schematic flowchart of an implementation of an asynchronous communication method according to the present invention. As shown in FIG. 1, the asynchronous communication method of the present invention includes the following steps:
- Step 101 The server receives the request sent by the client, generates a transaction for each received request, and assigns a unique transaction number to the transaction, and saves the current transaction state.
- the request is a processing request and a service request initiated by the client to the server, and the requesting server completes the required service processing;
- the generating transaction may generate an event to be processed, and name the service to be processed.
- the business naming can be accompanied by business information to better mark the transaction; after assigning a unique transaction number, saving the generated transaction and its transaction number is equivalent to saving the initial state of the transaction, and the current transaction state of the transaction is the initial state. .
- the client sends an authentication request carrying the authentication information, and after the server receives the verification request, Generate a verification transaction, and assign a unique transaction number to the verification transaction, and then save the face certificate transaction and its transaction number.
- saving the verification transaction and its transaction number is equivalent to saving the initial transaction status of the face certificate transaction.
- Step 102 The server initiates a collaborative processing request to the collaborative server, and sends the service that the client needs to process to the coordinated server for processing, and updates the transaction status of the transaction corresponding to the service.
- the server itself cannot process the service requested by the client, and needs to cooperate with the server to process the service. Therefore, the service that the client needs to process is sent to the collaborative server; and the server does not need to Waiting for the collaborative server to immediately return the processing result, just update the transaction status of its own transaction, waiting for the processing result.
- the update transaction status refers to: updating the transaction status of the transaction corresponding to the transaction number.
- the server when the server receives the request sent by the client, it needs to query the data.
- the server first generates a query transaction, and assigns a unique transaction number to the query transaction.
- the transaction number corresponds to the query transaction, and the query transaction is saved at this time.
- the transaction number is used as the initial transaction state of the query transaction.
- the server sends the query request to the collaborative server together with the transaction number of the query transaction, and the coordination server processes the query service.
- the transaction status of the update query transaction is Waiting for the query result; Because it is asynchronous, after the query request is issued, the server does not need to wait for the query result immediately, so the server can continue to process other transactions after sending the query request and querying the transaction to the collaborative server; correspondingly, the collaborative server receives After the query request, the query is immediately performed, and after the query ends, the query data and the corresponding transaction number are returned as a processing response to the server; after receiving the processing response, the server finds the query transaction waiting for the query result according to the transaction number in the processing response.
- update the query transaction Service status has been the result of the query; then, the data returned from the server to the client, until all the data is returned successfully, the update query transaction state of affairs to return success; and finally, The server cleans up and deletes the query transaction, and the entire query process ends.
- Step 103 After receiving the collaborative processing request, the collaborative server processes the corresponding service; at the same time, the server continues to receive other requests from the client, and waits for the processing response of the coordinated server.
- the server can continuously receive the new request of the client, and send the service to be processed to the corresponding collaborative server, and also wait for the processing response of the service previously sent to the coordinated server, in this case, the service
- the end and the collaborative server are equivalent to parallel processing services, each handling different services without interfering with each other. In practical applications, there may be multiple collaborative servers, which are used to process the same or different services.
- the other requests of the client may be different requests for the same client to process different services, or may be requests from different clients.
- Step 104 The collaborative server returns a processing response to the server after processing the service.
- Steps 105 - 106 After receiving the processing response, the server parses the processing response, extracts the transaction number in the processing response, finds the transaction status of the corresponding transaction according to the transaction number, continues to complete the subsequent processing of the corresponding service of the office, and updates Transaction status.
- Step Zun 107 After the server processes the business, it returns the business processing result to the client.
- the server needs to delete the transaction corresponding to the service and its transaction number.
- the client after receiving the processing result, the client will display the received processing result to the user.
- the server and the collaboration server may both be servers.
- the client, the server, and the collaborative server are relatively speaking in the present invention.
- the same device can serve as a client, and/or a server, and/or a coordinated server according to actual needs. Roles, the roles played by the same device are not fixed.
- the present invention also provides an asynchronous communication system, as shown in FIG. 2,
- the system includes a client, a server, and a collaboration server; wherein
- the client is configured to send a request to the server, request the server to perform service processing, and receive the service processing result;
- the client and the server interact with the agreed protocol
- the agreed protocol may be a custom protocol negotiated by both parties or a standard protocol.
- the client is also used to display the received processing result.
- the server is configured to receive a request from the client, generate a transaction for each request, and allocate a transaction number; send the service that the client needs to process to the collaborative server for processing, continue to receive other requests from the client, and wait for the coordinated server. Processing the response; extracting the transaction number after receiving the processing response, finding the corresponding transaction, completing the subsequent processing, and returning the processing result to the client;
- the server is further configured to save the transaction state of the transaction; after the service is sent to the cooperating server, and the processing response returned by the cooperating server is received, the transaction status is updated.
- the server is the core of the entire system, and is mainly used to coordinate the completion of the client's business processing.
- the server includes two functional modules: a data transceiver manager and a transaction state manager, where the data transceiver manager is configured to complete data interaction between the server and the client and the collaboration server; It includes the establishment and maintenance of data channels, receiving and sending service requests, processing requests, co-processing requests, receiving and sending processing responses, and processing results. It also includes the assembly and parsing of data to ensure the integrity of data transmission between the two parties.
- the transaction state manager is configured to generate a transaction for each request and assign a unique transaction number; extract the transaction number in the processing response returned by the collaborative server, query the corresponding transaction according to the transaction number, and complete subsequent processing; The transaction corresponding to the transaction is deleted and the transaction number is deleted after it is processed; it is also used to save the transaction status and update the transaction status.
- the data transceiver manager can be implemented by a variety of technologies, such as: under Linux Epoll and select mode; completion port under Windows (IOCP) and so on.
- the collaborative server is configured to receive a collaborative processing request sent by the server, and the auxiliary server completes processing the service requested by the client, and returns a processing response to the server;
- collaborative server terminals there may be multiple collaborative server terminals that perform the same or different functions, for example: There are two authentication servers as the collaborative server, and one of them may be selected to verify the customer information each time; there may also be two Collaborative server, one is the authentication server, and the other is the configuration server, which performs different functions.
- the server for a transaction, it is generally necessary to complete multiple steps of the transaction, in order to complete the entire business process of the corresponding business of the firm.
- the service to be processed is:
- the access server needs to respond quickly to the access of the client, where the access server is the server, and the authentication server for verifying the user information is the collaborative server.
- the processing procedure based on the asynchronous communication method of the present invention is specifically:
- the user first sends the authentication information such as the password and the user name (or code) to the access server through the client.
- the access server After the access server performs the necessary verification, it generates an authentication transaction and assigns a unique transaction number to the verification transaction, and saves the verification transaction and its transaction.
- the number is the initial transaction status of the verification transaction; then the access server establishes a good communication channel between itself and the verification server, forwards the corresponding verification request to the verification server for face verification, and the access server updates its own transaction status to wait for verification.
- the access server continues to access the verification request of the next client; after the verification server passes a series of verifications such as data comparison, the verification result is asynchronously returned to the access server as a processing response; the access server parses the received processing.
- the client After receiving the verification result, the client presents the result of the face certificate to the user and guides the user to continue the operation.
Abstract
本发明公开了一种异步通信方法，包括：服务端在收到客户端的每个请求后生成一个事务并分配唯一的事务号，将客户端请求处理的业务发给相应的协同服务端处理；服务端接收客户端的其他请求，并等待协同服务端返回的处理应答；收到协同服务端返回的处理应答后，服务端根据事务号查找出相应的事务，完成后续处理，并返回处理结果给客户端。本发明还同时公开了一种异步通信系统，采用本发明不仅能实现异步交互，且能减少网络性能波动对通信服务的影响，提高服务质量。
Description
一种异步通信方法及系统 技术领域
本发明涉及通信交互技术， 特别是涉及一种基于事务状态的异步通信 方法及系统。 背景技术
随着网络的发展， 网络通信越来越普及， 应用越来越广泛。 在现有的 网络通信中， 大多采用客户端和服务端交互的模式， 客户端与服务端进行 通信交互的方式主要有两种：
一种是采用同步方式交互， 这种方式是客户端发送一个请求给服务端 后， 需要等收到服务端的响应后才能发送下一个请求； 服务端也是一样， 需要等到对端的回复后才能继续下一步操作。 也就是说， 这种简单的同步 交互方式， 交互双方都需要等待对端的处理结果， 才能继续后续处理。 这 样， 如果由于网络抖动或对端处理速度慢， 就会导致本端处理效率降低， 严重影响服务质量。
另一种是采用嵌套异步方式， 这种方式是允许客户端在发送一个请求、 且未等到服务端返回响应时， 就可以发送下一个请求， 依次类推形成嵌套 模式。 比如： 客户端向服务端发送业务请求 1， 在未收到业务请求 1的响应 时， 客户端可以继续向服务端发送业务请求 2,在未收到业务请求 2的响应 时， 客户端还可以继续向服务端发送业务请求 3， 这种情况下， 业务请求 1 是第一层， 也是最外层； 业务请求 2是第二层， 属于中间层； 业务请求 3 是第三层， 也是最内层。 这种嵌套的异步方式虽然可以连续发送多个请求， 但是， 在接收响应时， 必须顺序接收业务请求 3的响应、 业务请求 2的响 应、 业务请求 1 的响应， 才能依次继续后续处理， 也就是说， 需要由内向
外逐层依次处理， 即： 只有内层锋放了， 才能处理相邻的下一层， 如果未 收到当前层的响应， 即使收到其它层响应也不能进行处理， 这样， 不仅大 大增加了业务处理时间， 降低了业务吞吐量， 降低了服务质量； 而且， 对 于通信能力和处理能力有限的网络， 对嵌套的层数也会有一定的限制， 因 为嵌套层数太多会导致处理能力大大减緩， 甚至使整个系统瘫痪。 发明内容
有鉴于此， 本发明的主要目的在于提供一种异步通信方法及系统， 不 仅能实现异步交互， 且能减少网络性能波动对通信服务的影响， 提高服务 质量。
为达到上述目的， 本发明的技术方案是这样实现的：
本发明提供了一种异步通信方法， 包括：
服务端在收到客户端的每个请求后生成一个事务并分配唯一的事务 号， 将客户端请求处理的业务发给相应的协同服务端处理；
服务端接收客户端的其他请求， 并等待协同服务端返回的处理应答； 收到协同服务端返回的处理应答后， 服务端根据事务号查找出相应的 事务， 完成后续处理并返回处理结果给客户端。
上述方案中， 在服务端生成事务并分配事务号后， 该方法进一步包括： 服务端保存当前的事务状态； 相应的， 在将客户端请求处理的业务发给协 同服务端后， 该方法进一步包括： 服务端更新事务状态。
上述方案中， 在收到协同服务端返回的处理应答后， 该方法进一步包 括： 服务端解析处理应答， 提取出处理应答中的事务号， 并更新事务状态。
该方法进一步包括： 客户端展现收到的处理结果。
上述方案中， 所述协同服务端为多个。
本发明还提供了一种异步通信系统， 包括： 客户端、 服务端和协同服 务端； 其中，
客户端， 用于向服务端发送请求， 请求服务端进行业务处理， 并接收 业务处理结果；
服务端， 用于接收客户端的请求， 为每个请求生成一个事务并分配事 务号， 将客户端需要处理的业务发送给协同服务端进行处理， 自身继续接 收客户端的其他请求， 并等待协同服务端的处理应答； 在收到处理应答后， 根据事务号查找到对应的事务， 完成后续处理并将处理结果返回客户端； 协同服务端， 用于接收服务端发送的协同处理请求， 完成对客户端所 请求业务的处理， 并返回处理应答给服务端。
上述方案中， 所述服务端还用于保存事务的事务状态、 以及更新事务 状态。
上述方案中， 所述服务端包括数据收发管理器和事务状态管理器； 其 中， 所述数据收发管理器， 用于完成服务端与客户端和协同服务端之间的 数据交互；
所述事务状态管理器， 用于为每个请求生成一个事务并分配唯一的事 务号； 提取协同服务端返回的处理应答中的事务号， 根据事务号查询对应 的事务， 并完成后续处理； 在事务对应的业务处理完毕后删除事务及其事 务号； 还用于保存事务状态和更新事务状态。
上述方案中， 所述客户端， 还用于展现收到的处理结果。
本发明所提供的异步通信方法及系统， 由协同服务端辅助服务端完成 业务处理， 服务端可以不断接收客户端的请求， 在收到每个请求后生成一 个事务并分配唯一的事务号， 并将请求处理的业务发给相应的协同服务端 处理； 当收到协同服务端返回的处理结果后， 根据事务号查找出相应的事 务， 完成后续处理， 并返回处理结果给客户端。 如此， 服务端和客户端可 通过基于事务状态的异步方式进行交互， 并通过建立事务及分配事务号对 客户端所请求的各类业务进行处理和管理， 从而有效降低了网络性能波动
和 /或处理对端异常所导致的服务质量下降， 提高了服务质量和服务能力。 另外， 对于本发明采用的异步模式网络服务来说， 通信交互双方不需 要立即得到响应， 也无需按顺序依次处理， 服务端收到来自协同服务端的 任何一个业务处理应答， 都可以根据事务号找到对应的事务继续进行后续 处理， 这样， 服务端可以同时处理多个业务， 能有效提高业务吞吐量， 进 而提高服务质量和处理能力。 附图说明
图 1为本发明异步通信方法的实现流程示意图；
图 2为本发明异步通信系统的组成结构示意图。 具体实施方式
本发明的基本思想是： 服务端在收到客户端的每个请求后生成一个事 务并分配唯一的事务号， 并将客户端请求处理的业务发给相应的协同服务 端处理； 收到协同服务端返回的处理应答后， 服务端根据事务号查找出相 应的事务， 完成后续处理， 并返回处理结果给客户端。
图 1为本发明异步通信方法的实现流程示意图， 如图 1所示， 本发明 异步通信方法包括以下步骤：
步骤 101: 服务端接收客户端发送的请求， 为每个收到的请求生成一个 事务， 并为该事务分配唯一的事务号， 保存当前的事务状态。
这里， 所述请求为客户端向服务端发起的处理请求、 业务请求， 请求 服务端完成所需的业务处理； 所述生成事务可以是生成一个待处理的事件， 并以要处理的业务命名， 该业务命名中可以附带业务信息， 以便更好的标 志事务； 分配唯一的事务号后， 保存所生成事务及其事务号就相当于保存 该事务的初始状态， 该事务的当前事务状态为初始状态。
举例来说， 客户端发送携带验证信息的验证请求， 服务端收到后， 会
生成验证事务， 并为验证事务分配唯一的事务号， 之后保存脸证事务及其 事务号， 这里， 保存验证事务及其事务号就相当于保存该臉证事务的初始 事务状态。
步骤 102: 服务端向协同服务端发起协同处理请求，将客户端需要处理 的业务发送给协同服务端进行处理， 并更新所述业务所对应事务的事务状 态。
由于一些情况下， 服务端本身并不能独自处理客户端所请求处理的业 务， 需要协同服务端辅助处理， 因此， 会将客户端需要处理的业务发送给 协同服务端； 并且， 服务端并不需要等待协同服务端立即返回处理结果， 只是更新自身事务的事务状态， 等待处理结果即可。
这里， 服务端向协同服务端发送协同处理请求时， 会建立服务端与协 同服务端之间的通信通道。 所述更新事务状态是指： 将事务号所对应的事 务的事务处理状态进行更新。
举例来说， 服务端收到客户端发送的请求， 需要查询数据； 服务端首 先生成查询事务， 并为查询事务分配一个唯一的事务号， 事务号与查询事 务相对应， 此时保存查询事务及其事务号作为该查询事务的初始事务状态； 然后， 服务端将查询请求与查询事务的事务号一起发给协同服务端， 由协 调服务端处理查询业务， 此时， 更新查询事务的事务状态为等待查询结果； 由于是异步， 发出查询请求后， 服务端不需要立即等待查询结果， 因此服 务端在发送查询请求和查询事务给协同服务端后可继续处理其他事务； 相 应的， 协同服务端收到查询请求后， 立即进行查询， 并在查询结束后将查 询数据以及对应的事务号作为处理应答返回服务端； 服务器收到处理应答 后， 根据处理应答中的事务号找到等待查询结果的查询事务， 此时， 更新 查询事务的事务状态为已经得到查询结果； 随后， 服务端返回数据给客户 端， 待全部数据返回成功后， 更新查询事务的事务状态为返回成功； 最后，
服务端清理删除该查询事务， 整个查询流程结束。
步驟 103: 协同服务端收到协同处理请求后， 对相应业务进行处理； 同 时， 服务端继续接收客户端的其他请求， 并等待协同服务端的处理应答。
这里， 服务端可以不断地接收客户端新的请求， 并将所需处理的业务 发送给相应协同服务端， 同时也等待之前发送给协同服务端处理的业务的 处理应答， 这种情况下， 服务端和协同服务端相当于并行处理业务， 各自 处理不同的业务， 互不干扰。 实际应用中， 协同服务端可以有多个， 分别 用于处理相同或不同的业务。
所述客户端的其他请求可以是同一客户端要求处理不同业务的不同请 求， 也可以是不同客户端的请求。
步骤 104: 协同服务端处理完业务后向服务端返回处理应答。
步骤 105 - 106: 服务端收到处理应答后， 解析处理应答， 提取出处理 应答中的事务号， 根据事务号查找出对应事务的事务状态， 继续完成该事 务所对应业务的后续处理， 并更新事务状态。
这里， 所有事务状态可线性存储于一个事务列表中， 以便于查找， 当 然也可以采用其它方式存储。
步尊 107: 服务端处理完业务后， 将业务处理结果返回客户端。
进一步的， 服务端在处理完某个业务后， 需要将该业务对应的事务及 其事务号删除。
进一步的， 客户端收到处理结果后， 会向用户展现收到的处理结果。 上述处理过程中， 所述服务端、 协同服务端均可为服务器。 并且， 本 发明中所述客户端、 服务端以及协同服务端都是相对而言的， 实际应用中， 同一设备可以根据实际的需求充当客户端、 和 /或服务端、 和 /或协同服务端 的角色， 同一设备所充当的角色并非固定不变的。
为实现上述方法， 本发明还提供了一种异步通信系统， 如图 2所示，
该系统包括客户端、 服务端和协同服务端； 其中，
客户端， 用于向服务端发送请求， 请求服务端进行业务处理， 并接收 业务处理结果；
这里， 客户端与服务端采用约定的协议进行交互， 所述约定的协议可 以是经双方协商的自定义协议、 或为标准协议。
进一步的， 客户端还用于展现收到的处理结果。
服务端， 用于接收客户端的请求， 为每个请求生成一个事务并分配事 务号； 将客户端需要处理的业务发送给协同服务端进行处理， 自身继续接 收客户端的其他请求， 并等待协同服务端的处理应答； 在收到处理应答后 提取出事务号， 查找到对应的事务， 完成后续处理， 并将处理结果返回客 户端；
进一步的， 服务端， 还用于保存事务的事务状态； 在将业务发送给协 同服务端、 收到协同服务端返回的处理应答后， 更新事务状态。
这里， 服务端是整个系统的核心， 主要用于协调完成客户端的业务处 理。
进一步的， 服务端包括数据收发管理器和事务状态管理器两个功能模 块， 其中， 所述数据收发管理器， 用于完成服务端与客户端和协同服务端 之间的数据交互； 具体的， 包括数据通道的建立与維护， 接收和发送业务 请求、 处理清求、 协同处理请求， 接收和发送处理应答、 处理结果； 还包 括对数据的组装和解析， 以保证交互双方数据传输的完整。
所述事务状态管理器， 用于为每个请求生成一个事务并分配唯一的事 务号； 提取协同服务端返回的处理应答中的事务号， 根据事务号查询对应 的事务， 并完成后续处理； 在事务对应的业务处理完毕后删除事务及其事 务号； 还用于保存事务状态和更新事务状态。
其中， 数据收发管理器可以通过很有多种技术实现， 比如： Linux下的
epoll和 select模式； Windows下的完成端口 （ IOCP )等等。
协同服务端， 用于接收服务端发送的协同处理请求， 辅助服务端完成 对客户端所请求业务的处理， 并返回处理应答给服务端；
实际应用中， 协同服务端可以有多个， 分别完成相同或不同功能， 例 如： 有两个验证服务器作为协同服务端， 每次可任选其中之一对客户信息 进行验证； 也可以有两个协同服务端， 一个是验证服务器， 一个是配置服 务器， 分别完成不同的功能。 在服务端中， 对于某个事务一般需要完成该 事务的多个步骤， 才能完成该事务所对应业务的整个业务处理过程。
下面再结合具体实施例对本发明异步通信的方法和系统进一步详细说 明。
本实施例中， 需处理的业务是： 接入服务器需要快速响应客户端的接 入， 其中， 接入服务器为服务端， 用于验证用户信息的验证服务器为协同 服务端。
基于本发明异步通信方法的处理过程具体为：
用户先通过客户端发送密码和用户名称 （或编码 )等验证信息到接入 服务器， 接入服务器进行必要的验证后， 生成验证事务并为验证事务分配 唯一的事务号， 保存验证事务及其事务号为验证事务的初始事务状态； 随即接入服务器通过自身与验证服务器之间建立好的通信通道， 将相 应的验证请求转发给验证服务器进行脸证， 接入服务器更新自身的事务状 态为等待验证结果； 之后， 接入服务器继续接入下一个客户端的验证请求； 验证服务器通过数据对比等一系列的验证后， 将验证结果作为处理应 答异步返回给接入服务器； 接入服务器解析收到的处理应答， 得到对应的 事务号和验证结果， 并根据事务号找到先前保存的等待验证结果的验证事 务， 继续该事务的后续处理， 并更新自身的事务状态为已经得到验证结果； 处理完成后， 将验证结果返回客户端， 并更新自身的事务状态为返回成功；
最后， 接入服务器在自身结束并删除该验证事务；
客户端收到验证结果后， 将脸证结果展现给用户， 并引导用户继续操 作。
以上所述， 仅为本发明的较佳实施例而已， 并非用于限定本发明的保 护范围， 凡在本发明的精神和原则之内所作的任何修改、 等同替换和改进 等， 均应包含在本发明的保护范围之内。
Claims
1、 一种异步通信方法， 其特征在于， 该方法包括：
服务端在收到客户端的每个请求后生成一个事务并分配唯一的事务 号， 将客户端请求处理的业务发给相应的协同服务端处理；
服务端接收客户端的其他请求， 并等待协同服务端返回的处理应答； 收到协同服务端返回的处理应答后， 服务端根据事务号查找出相应的 事务， 完成后续处理并返回处理结果给客户端。
2、 根据权利要求 1所述的异步通信方法， 其特征在于， 在服务端生成 事务并分配事务号后， 该方法进一步包括： 服务端保存当前的事务状态； 相应的， 在将客户端请求处理的业务发给协同服务端后， 该方法进一 步包括： 服务端更新事务状态。
3、 根据权利要求 1所述的异步通信方法， 其特征在于， 在收到协同服 务端返回的处理应答后， 该方法进一步包括： 服务端解析处理应答， 提取 出处理应答中的事务号， 并更新事务状态。
4、 根据权利要求 1所述的异步通信方法， 其特征在于， 该方法进一步 包括： 客户端展现收到的处理结果。
5、 根据权利要求 1至 4任一项所述的异步通信方法， 其特征在于， 所 述协同服务端为多个
6、 一种异步通信系统， 其特征在于， 该系统包括： 客户端、 服务端和 协同服务端； 其中，
客户端， 用于向服务端发送请求， 请求服务端进行业务处理， 并接收 业务处理结果；
服务端， 用于接收客户端的请求， 为每个请求生成一个事务并分配事 务号， 将客户端需要处理的业务发送给协同服务端进行处理， 自身继续接 收客户端的其他请求， 并等待协同服务端的处理应答； 在收到处理应答后， 根据事务号查找到对应的事务， 完成后续处理并将处理结果返回客户端； 协同服务端， 用于接收服务端发送的协同处理请求， 完成对客户端所 请求业务的处理， 并返回处理应答给服务端。
7、 根据权利要求 6所述的异步通信系统， 其特征在于， 所述服务端， 还用于保存事务的事务状态、 以及更新事务状态。
8、 根据权利要求 7所述的异步通信系统， 其特征在于， 所述服务端包 括数据收发管理器和事务状态管理器； 其中，
所述数据收发管理器， 用于完成服务端与客户端和协同服务端之间的 数据交互；
所述事务状态管理器， 用于为每个请求生成一个事务并分配唯一的事 务号； 提取协同服务端返回的处理应答中的事务号， 根据事务号查询对应 的事务， 并完成后续处理； 在事务对应的业务处理完毕后删除事务及其事 务号； 还用于保存事务状态和更新事务状态。
9、 根据权利要求 6所述的异步通信系统， 其特征在于， 所述客户端， 还用于展现收到的处理结果。
10、 根据权利要求 6至 9任一项所述的异步通信系统， 其特征在于， 所述协同服务端为多个。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201010284408.8A CN102404367B (zh) | 2010-09-13 | 2010-09-13 | 一种异步通信方法及系统 |
| CN201010284408.8 | 2010-09-13 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2012034496A1 true WO2012034496A1 (zh) | 2012-03-22 |
Family
ID=45831006
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2011/079473 WO2012034496A1 (zh) | 2010-09-13 | 2011-09-08 | 一种异步通信方法及系统 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN102404367B (zh) |
| WO (1) | WO2012034496A1 (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103037011A (zh) * | 2012-12-26 | 2013-04-10 | 泉州豪杰信息科技发展有限公司 | 基于iocp的海量终端设备接入系统 |
| CN104753957A (zh) * | 2015-04-16 | 2015-07-01 | 国家电网公司 | 一种用电信息采集系统的海量终端通信连接管理方法 |
| CN112835687A (zh) * | 2021-01-22 | 2021-05-25 | 恒生电子股份有限公司 | 一种计算机事务处理方法及系统 |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105099989B (zh) * | 2014-04-24 | 2019-11-22 | 阿里巴巴集团控股有限公司 | 用于处理业务请求及获取业务处理结果的方法、装置和系统 |
| CN105635083A (zh) * | 2014-11-14 | 2016-06-01 | 航天信息股份有限公司 | 基于服务器和客户端架构的业务处理方法及业务处理系统 |
| CN104767737A (zh) * | 2015-03-23 | 2015-07-08 | 贵阳朗玛信息技术股份有限公司 | 插入式事务管理器及其应用方法 |
| CN105391776A (zh) * | 2015-10-20 | 2016-03-09 | 上海斐讯数据通信技术有限公司 | 长连接消息的通信方法及系统 |
| CN108337285B (zh) * | 2017-01-20 | 2021-01-26 | 北京京东尚科信息技术有限公司 | 一种通信系统及通信方法 |
| CN109040251A (zh) * | 2018-08-07 | 2018-12-18 | 中国建设银行股份有限公司 | 一种异步消息的处理方法及系统 |
| CN110995817B (zh) * | 2019-11-27 | 2022-05-20 | 广州华多网络科技有限公司 | 请求回调方法、装置及客户端设备 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101317408A (zh) * | 2005-09-29 | 2008-12-03 | 蒂蒙系统公司 | 通过互联网提供异步通信的方法和系统 |
| CN101667928A (zh) * | 2009-09-25 | 2010-03-10 | 中兴通讯股份有限公司 | 客户端、信令跟踪服务器、协议模块和信令跟踪方法 |
| CN101800974A (zh) * | 2009-02-11 | 2010-08-11 | 朗讯科技公司 | 处理移动设备的任务请求的方法和用户代理应用服务器 |
-
2010
- 2010-09-13 CN CN201010284408.8A patent/CN102404367B/zh active Active
-
2011
- 2011-09-08 WO PCT/CN2011/079473 patent/WO2012034496A1/zh active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101317408A (zh) * | 2005-09-29 | 2008-12-03 | 蒂蒙系统公司 | 通过互联网提供异步通信的方法和系统 |
| CN101800974A (zh) * | 2009-02-11 | 2010-08-11 | 朗讯科技公司 | 处理移动设备的任务请求的方法和用户代理应用服务器 |
| CN101667928A (zh) * | 2009-09-25 | 2010-03-10 | 中兴通讯股份有限公司 | 客户端、信令跟踪服务器、协议模块和信令跟踪方法 |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103037011A (zh) * | 2012-12-26 | 2013-04-10 | 泉州豪杰信息科技发展有限公司 | 基于iocp的海量终端设备接入系统 |
| CN103037011B (zh) * | 2012-12-26 | 2016-02-17 | 泉州豪杰信息科技发展有限公司 | 基于iocp的海量终端设备接入系统 |
| CN104753957A (zh) * | 2015-04-16 | 2015-07-01 | 国家电网公司 | 一种用电信息采集系统的海量终端通信连接管理方法 |
| CN104753957B (zh) * | 2015-04-16 | 2017-12-26 | 许继集团有限公司 | 一种用电信息采集系统的海量终端通信连接管理方法 |
| CN112835687A (zh) * | 2021-01-22 | 2021-05-25 | 恒生电子股份有限公司 | 一种计算机事务处理方法及系统 |
| CN112835687B (zh) * | 2021-01-22 | 2023-05-26 | 恒生电子股份有限公司 | 一种计算机事务处理方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102404367A (zh) | 2012-04-04 |
| CN102404367B (zh) | 2016-04-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2012034496A1 (zh) | 一种异步通信方法及系统 | |
| US8665860B2 (en) | Relay device and method for continuing service | |
| JP2005516544A (ja) | 制御されたマルチキャストのシステム及び実行方法 | |
| CN111338906B (zh) | 终端设备、边缘节点及基于区块链的应用监管方法和系统 | |
| WO2008138241A1 (fr) | Serveur de service à la clientèle, procédé et système fondés sur la messagerie instantanée | |
| CN103873449B (zh) | 网络接入方法与系统 | |
| WO2011026430A1 (zh) | 内容分发网络中数据同步的方法及系统 | |
| WO2009094890A1 (fr) | Procédé de programmation d'un service et système associé, appareil de programmation de services | |
| CN106331155B (zh) | 一种防止用户重复登录的方法和服务器 | |
| SG194651A1 (en) | Method and device for establishing conversation relation | |
| WO2015039306A1 (zh) | 一种视讯会议的实现方法、业务管理设备及视讯会议系统 | |
| CN103812900A (zh) | 一种数据同步方法、装置及系统 | |
| CN113572864B (zh) | 一种数据处理方法、网元设备以及可读存储介质 | |
| CN102118397B (zh) | 一种基于手机的远程会议通信方法和系统 | |
| CN101420681B (zh) | 一种业务管理平台下处理多渠道请求订购的方法和装置 | |
| CN101729557A (zh) | 一种实现终端设备资源共享的方法及系统 | |
| CN109041036A (zh) | Wifi连接方法及设备 | |
| CN109150290B (zh) | 一种卫星轻量化数据传输保护方法及地面安全服务系统 | |
| CN107241422B (zh) | 一种实时将外部用户及用户组信息同步进Apache Ranger的方法 | |
| CN102404351A (zh) | 一种ldap云存储服务系统 | |
| CN1223155C (zh) | 一种基于集群管理的802.1x通信实现方法 | |
| CN109413142A (zh) | 一种Linux下的iSCSI虚拟代理实现方法 | |
| CN201985895U (zh) | 一种ldap云存储服务系统 | |
| CN116095081A (zh) | 基于区块链系统的事件处理方法及装置、设备、介质 | |
| CN114827062A (zh) | 一种基于用户真实地理位置确定聊天对象的网络社交方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11824566 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 22/05/2013) |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 11824566 Country of ref document: EP Kind code of ref document: A1 |