A digital currency transaction method and apparatus

Abstract

This invention discloses a digital currency transaction method and apparatus, relating to the field of computer technology. One specific embodiment of the method includes: command interaction with a first wallet and a second wallet respectively; during the command interaction, after sending a first command to the first wallet, performing the following two operations in parallel: receiving response data of the first command in blocks from the first wallet, and sending a second command in blocks to the second wallet; wherein the data block of the sent second command is generated based on the data block of the received response data of the first command; after completing all command sending and corresponding response data receiving operations with the first and second wallets, the digital currency transaction process ends. This embodiment enables parallel processing of data reception and transmission, reducing the time consumption of data transmission and reception processing, and improving the efficiency of digital currency transactions.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a digital currency transaction method and device. BACKGROUND

[0002] The transaction of digital currency usually has three participating entities, a terminal APP (application program), a payee wallet and a payer wallet. The terminal APP serves as a data communication hub of the payee wallet and the payer wallet, and realizes the authentication of the transaction parties and the payment operation of the transaction by exchanging the data of the payee wallet and the payer wallet. Since the processing of one wallet depends on the processing data result of the other wallet, the terminal APP processing is a serial execution process on the flow, that is, after receiving the complete data packet of one wallet, the complete data packet is sent to the other wallet. Limited by the physical interface or communication protocol characteristics of the wallet, the communication buffer size is limited, and when the data packet size sent by the wallet exceeds the communication buffer size, the data packet needs to be divided into several data blocks and sent multiple times. The terminal APP must wait until the complete data packet is received before the complete data packet is split into several data blocks and sent to the other wallet for processing.

[0003] In the process of implementing the present application, the inventors have found that the prior art at least has the following problems:

[0004] The receiving data and sending data are serially processed, the time consumption of data receiving and sending processing is long, and the efficiency of digital currency transaction is low. SUMMARY

[0005] Therefore, the embodiments of the present application provide a digital currency transaction method and device, which can realize parallel processing of receiving data and sending data, reduce the time consumption of data receiving and sending processing, and improve the efficiency of digital currency transaction.

[0006] To achieve the above object, according to an aspect of the embodiments of the present application, a digital currency transaction method is provided.

[0007] A digital currency transaction method, comprising: performing command interaction with a first wallet and a second wallet respectively, and in the process of the command interaction, when a first command is sent to the first wallet, performing the following two operations in parallel: an operation of receiving response data of the first command from the first wallet in blocks, and an operation of sending a second command to the second wallet in blocks; wherein the data block of the second command sent is generated based on the data block of the received response data of the first command; after completing all command sending and corresponding response data receiving operations with the first wallet and the second wallet, ending the digital currency transaction process.

[0008] Optionally, the first wallet is a payment wallet, the first command is a payment command, and the second wallet is a collection wallet, the second command is a collection command; or, the first wallet is a collection wallet, the first command is a collection command, and the second wallet is a payment wallet, the second command is a payment command.

[0009] Optionally, the first command is sent to the first wallet and the response data of the first command is received from the first wallet by a first thread, and the second command is sent to the second wallet by a second thread.

[0010] Optionally, the first thread and the second thread determine the order of the issued commands by the state machines maintained by them respectively when the number of the issued commands is more than one.

[0011] Optionally, the first thread or the second thread switches the maintained state machine to a state of sending the next command after sending each command.

[0012] Optionally, the parallel execution of the operation of receiving the response data of the first command from the first wallet and the operation of sending the second command to the second wallet includes: the first thread receives the first data block of the response data of the first command from the first wallet; after receiving a preset number of data blocks of the response data of the first command, the first thread triggers the second thread by a message, so that the second thread generates the data block of the second command according to the data blocks of the response data of the first command received by the first thread while the first thread receives the remaining data blocks of the response data of the first command, and sends the generated data block of the second command to the second wallet.

[0013] Optionally, after receiving a preset number of data blocks of the response data of the first command, the first thread sets the parallel processing message corresponding to the second thread as valid to trigger the second thread.

[0014] Optionally, the setting of the parallel processing message corresponding to the second thread as valid includes: writing a data valid length in the parallel processing message corresponding to the second thread according to the received data blocks of the response data of the first command; the method further includes: dynamically updating the data valid length in the parallel processing message corresponding to the second thread in the process of receiving the remaining data blocks of the response data of the first command by the first thread.

[0015] Optionally, the data block of the response data of the first command received from the first wallet is stored in a shared data buffer; and the second thread generates the data block of the second command according to the data block of the response data of the first command received by the first thread, including: when the second thread checks that the parallel processing message corresponding to the second thread is valid, the second thread acquires the data block of the response data of the first command from the shared data buffer according to the data valid length, and generates the data block of the second command according to the acquired data block.

[0016] Optionally, after the first thread receives all the data blocks of the response data of the first command, the value of the data reception completion identifier in the parallel processing message corresponding to the second thread is set to a specific value.

[0017] Optionally, after the second thread sends the generated data block of the second command to the second wallet, the second thread counts the length of the data sent to the second wallet, and when the length of the data sent to the second wallet by the second thread is equal to the data valid length and the value of the data reception completion identifier in the parallel processing message corresponding to the second thread is the specific value, the second thread restores the parallel processing message corresponding to the second thread to an initial state.

[0018] According to another aspect of the embodiments of the present application, a digital currency transaction device is provided.

[0019] A digital currency transaction device includes: a command interaction module configured to perform command interaction with a first wallet and a second wallet respectively, and when a first command is sent to the first wallet, the following two operations are performed in parallel: an operation of receiving response data of the first command from the first wallet in blocks, and an operation of sending a second command to the second wallet in blocks; wherein the data block of the second command sent is generated based on the data block of the received response data of the first command; and a transaction flow end module configured to end a digital currency transaction flow after completing all command sending and corresponding response data receiving operations with the first wallet and the second wallet.

[0020] Optionally, the first wallet is a payment wallet, the first command is a payment command, and the second wallet is a receiving wallet, and the second command is a receiving command; or the first wallet is a receiving wallet, the first command is a receiving command, and the second wallet is a payment wallet, and the second command is a payment command.

[0021] Optionally, the command interaction module sends the first command to the first wallet through a first thread and sends the second command to the second wallet through a second thread.

[0022] Optionally, the first thread and the second thread respectively determine the order of the issued commands through the state machines maintained by the threads when the number of the issued commands is more than one.

[0023] Optionally, the command interaction module switches the state machine maintained by the corresponding thread to a state of sending the next command after sending one command through the first thread or the second thread each time.

[0024] Optionally, the command interaction module further receives, through the first thread, a first data block of the response data of the first command from the first wallet, and triggers the second thread through a message after receiving a preset number of data blocks of the response data of the first command through the first thread, so that the second thread generates data blocks of the second command according to the data blocks of the response data of the first command received by the first thread while the first thread receives the remaining data blocks of the response data of the first command, and sends the generated data blocks of the second command to the second wallet.

[0025] Optionally, the command interaction module sets the parallel processing message corresponding to the second thread as valid to trigger the second thread after receiving a preset number of data blocks of the response data of the first command through the first thread.

[0026] Optionally, the command interaction module further writes a data valid length in the parallel processing message corresponding to the second thread according to the received data blocks of the response data of the first command, and the apparatus further comprises a data valid length updating module configured to dynamically update the data valid length in the parallel processing message corresponding to the second thread during the process of receiving the remaining data blocks of the response data of the first command by the first thread.

[0027] Optionally, the data blocks of the response data of the first command received from the first wallet are stored in a shared data buffer area, and the command interaction module further acquires the data blocks of the response data of the first command from the shared data buffer area according to the data valid length when the parallel processing message corresponding to the second thread is checked as valid through the second thread, and generates data blocks of the second command according to the acquired data blocks.

[0028] Optionally, the command interaction module sets a value of a data receiving completion identifier in the parallel processing message corresponding to the second thread to a specific value after the first thread receives all data blocks of response data of the first command.

[0029] Optionally, the command interaction module, after the second thread sends a data block of the second command generated by the second thread to the second wallet, counts a length of data sent to the second wallet, and in a case where the length of data sent to the second wallet by the second thread is equal to the valid data length and the value of the data receiving completion identifier in the parallel processing message corresponding to the second thread is the specific value, restores the parallel processing message corresponding to the second thread to an initial state.

[0030] According to still another aspect of the embodiments of the present application, an electronic device is provided.

[0031] An electronic device includes one or more processors; a memory for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the digital currency transaction method provided by the embodiments of the present application.

[0032] According to still another aspect of the embodiments of the present application, a computer readable medium is provided.

[0033] A computer readable medium having stored thereon a computer program, which, when executed by a processor, implements the digital currency transaction method provided by the embodiments of the present application.

[0034] The above-mentioned embodiment of the present application has the following advantages or beneficial effects: command interaction is performed with the first wallet and the second wallet respectively, and in the process of the command interaction, the following two operations are performed in parallel after the first command is sent to the first wallet: an operation of receiving response data of the first command from the first wallet in blocks, and an operation of sending the second command to the second wallet in blocks; wherein the data block of the second command sent is generated based on the received data block of the response data of the first command; after the operations of sending all commands and receiving corresponding response data with the first wallet and the second wallet are completed, the digital currency transaction process is ended. Parallel processing of receiving data and sending data can be implemented, time consumption of data receiving and sending processing is reduced, and digital currency transaction efficiency is improved.

[0035] Further effects of the above-mentioned non-conventional optional mode will be described in the following combined with the specific embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0036] The accompanying drawings are used to better understand the present application, and do not constitute an improper limitation on the present application. Among them:

[0037] Figure 1 is a schematic diagram of main steps of a digital currency transaction method according to an embodiment of the present application;

[0038] Figure 2 is an architecture diagram of a digital currency transaction according to an embodiment of the present application;

[0039] Figure 3 is a structural diagram of a digital currency transaction according to an embodiment of the present application;

[0040] Figure 4 is a structural diagram of parallel processing messages according to an embodiment of the present application;

[0041] Figure 5 is a flowchart of a digital currency transaction according to an embodiment of the present application;

[0042] Figure 6 is a schematic diagram of data receiving and sending according to an embodiment of the present application;

[0043] Figure 7 is a schematic diagram of main modules of a digital currency transaction device according to an embodiment of the present application;

[0044] Figure 8 is an exemplary system architecture diagram to which embodiments of the present application can be applied;

[0045] Figure 9 is a structural diagram of a computer system of a terminal device suitable for implementing embodiments of the present application. DETAILED DESCRIPTION

[0046] Exemplary embodiments of the present application are described below with reference to the accompanying drawings, which include various details of the embodiments of the present application to assist in understanding, which should be considered in the context of the present application. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and structures are omitted from the following description for the sake of clarity and conciseness.

[0047] Figure 1 is a schematic diagram of main steps of a digital currency transaction method according to an embodiment of the present application.

[0048] As shown in Figure 1 , the digital currency transaction method of an embodiment of the present application mainly includes the following steps S101 to S102. The digital currency transaction method of the embodiment of the present application is executed by a terminal APP.

[0049] Step S101: command interaction with the first wallet and the second wallet respectively, in the process of command interaction, when the first command is sent to the first wallet, the following two operations are performed in parallel: the operation of receiving the response data of the first command from the first wallet in blocks, and the operation of sending the second command to the second wallet in blocks; wherein the data block of the second command sent is generated based on the data block of the received response data of the first command.

[0050] Step S102: after completing the operation of sending all commands and receiving corresponding response data with the first wallet and the second wallet, end the digital currency transaction process.

[0051] Wherein, the first wallet is a payment wallet, the first command is a payment command, and the second wallet is a receiving wallet, and the second command is a receiving command; or, the first wallet is a receiving wallet, the first command is a receiving command, and the second wallet is a payment wallet, and the second command is a payment command.

[0052] The payment command specifically refers to the command sent by the terminal APP to the payment wallet in the command interaction process, and the receiving command specifically refers to the command sent by the terminal APP to the receiving wallet in the command interaction process. The first command is sent to the first wallet by the first thread, and the response data of the first command is received from the first wallet in blocks. The second command is sent to the second wallet in blocks by the second thread.

[0053] The first thread and the second thread respectively determine the order of the issued commands through the state machine maintained by each thread when the number of issued commands is multiple.

[0054] After sending each command, the first thread or the second thread switches the maintained state machine to the state of sending the next command. Wherein, a command can be a data packet, and the data packet can be sent in blocks, that is, a data packet can include one or more data blocks, that is, when all data blocks of a command are sent, it is considered that the command is sent.

[0055] The parallel execution of the following two operations: the operation of receiving the response data of the first command from the first wallet in blocks, and the operation of sending the second command to the second wallet in blocks, can include: the first thread receives the first data block of the response data of the first command from the first wallet; after receiving a preset number of data blocks of the response data of the first command, the first thread triggers the second thread through a message, so that while the first thread receives the remaining data blocks of the response data of the first command, the second thread generates the data block of the second command according to the data block of the response data of the first command received by the first thread, and sends the generated data block of the second command to the second wallet.

[0056] The first thread sets the second thread corresponding parallel processing message as valid after receiving a preset number of data blocks of the response data of the first command, so as to trigger the second thread. If the second thread is a payee thread, the second thread corresponding parallel processing message is a payee parallel processing message, and the first thread is a payer thread at this time. If the second thread is a payer thread, the second thread corresponding parallel processing message is a payer parallel processing message, and the first thread is a payee thread at this time.

[0057] Setting the second thread corresponding parallel processing message as valid can include: writing a data valid length in the second thread corresponding parallel processing message according to the received data block of the response data of the first command.

[0058] In the process that the first thread receives the remaining data blocks of the response data of the first command, the data valid length in the second thread corresponding parallel processing message is dynamically updated.

[0059] The data block of the response data of the first command received from the first wallet is stored in a shared data buffer area.

[0060] The second thread generates a data block of a second command according to the data block of the response data of the first command received by the first thread, which can include: the second thread acquires the data block of the response data of the first command from the shared data buffer area according to the data valid length when it is found that the second thread corresponding parallel processing message is valid, and generates a data block of a second command according to the acquired data block.

[0061] After the first thread receives all the data blocks of the response data of the first command, the value of the data reception completion identifier in the second thread corresponding parallel processing message can be set to a specific value.

[0062] After the second thread sends the generated data block of the second command to the second wallet, it counts the data length that has been sent to the second wallet. When the data length that has been sent to the second wallet by the second thread is equal to the data valid length, and the value of the data reception completion identifier in the second thread corresponding parallel processing message is the specific value, the second thread corresponding parallel processing message is restored to the initial state.

[0063] In one embodiment, the digital currency transaction includes three-party entities, namely a payer wallet, a payee wallet, and a terminal APP (i.e., a digital currency transaction device), which can be used as a data transfer hub, i.e., receiving data from the payer wallet and forwarding to the payee wallet, or receiving data from the payee wallet and forwarding to the payer wallet. In the case of receiving data from the payer wallet and forwarding to the payee wallet, the terminal APP can have two command interactions with the payer wallet, PAY CMD1 (payment command 1) and PAY CMD2 (payment command 2), and two command interactions with the payee wallet, RECEIVE CMD1 (receive command 1) and RECEIVE CMD2 (receive command 2). The communication buffer of the wallet is 256 bytes, and the specific content and logical relationship of the commands are shown in Table 1.

[0064] Table 1. Specific content and logical relationship of commands

[0065] Serial number Command Command length Command content Response length 1 PAY CMD1 10 bytes Transaction amount, time >256 bytes 2 RECEIVE CMD1 >256 bytes PAY CMD1 response data >256 bytes 3 PAY CMD2 >256 bytes RECEIVE CMD1 response data >256 bytes 4 RECEIVE CMD2 >256 bytes PAY CMD2 response data 0

[0066] As shown in Table 1, due to the limitation of the physical characteristics of the wallet, for the PAY CMD1 response data exceeding 256 bytes, the terminal APP needs to send PAY CMD1, GET RESPONSE 1, GET RESPONSE 2... commands to the payer wallet to receive all the PAY CMD1 response data. Similarly, because the RECEIVE CMD1 command data exceeds 256 bytes, the APP also needs to divide the RECEIVE CMD1 command into RECEIVE CMD1-0, RECEIVE CMD1-1, RECEIVE CMD1-2... commands and send them to the payee wallet. The same situation exists for PAY CMD2 and RECEIVE CMD2. In the prior art, serial operation is used, i.e., the RECEIVE CMD1 command cannot be sent until all the PAY CMD1 response data is received. In the embodiment of the present application, parallel operation is used to reduce the overall interaction time, and the greater the interaction data length, the more the optimization time.

[0067] Figure 2 Figure 1 is a schematic diagram of a digital currency transaction according to one embodiment of the present application.

[0068] As Figure 2As shown, the terminal APP of the embodiment of the present application supports two threads of a collection thread and a payment thread, which are used to process data communication of the collection wallet and the payment wallet; supports two parallel processing messages of collection and payment, which are used to control data sending time between the two threads to realize parallel processing; supports a shared data buffer area, which is used to receive and send parallel data to reduce data copy and moving process. The collection thread is used to communicate with the collection wallet, to interact with the collection party wallet through the control of the physical communication interface, and to save the received data to the shared data buffer area if the received data needs to be used for parallel processing. The payment parallel processing message is used to record the valid data length of the payment data that needs to be processed in parallel and whether there is remaining data. The payment parallel processing message is a thread shared information, which is used to notify the payment thread to send the data in the shared data buffer area. The payment thread is used to communicate with the payment wallet, to interact with the payment party wallet through the control of the physical communication interface, and to save the received data to the shared data buffer area if the received data needs to be used for parallel processing. The collection parallel processing message is used to record the valid data length of the collection data that needs to be processed in parallel and whether there is remaining data. The collection parallel processing message is a thread shared information, which is used to notify the collection thread to send the data in the shared data buffer area. The shared data buffer area is used to receive the response data from the payment wallet or the collection wallet, and to directly use the data in the buffer area for sending, so as to reduce the data moving operation.

[0069] Figure 3 is a structural diagram of a digital currency transaction according to an embodiment of the present application.

[0070] As Figure 3As shown, the terminal APP creates a payment thread debtorThread, which establishes a session and a channel with the payment wallet through system services, and maintains a state machine to process the two commands PAY CMD1 and PAY CMD2 in strict sequence. The payment thread is used to send command data to the wallet according to the state machine, and store the response data that needs to be processed in parallel into the shared data buffer shareBuffer of the APP. The terminal APP creates a payment parallel processing message structure msgParalellforDebt, which contains the valid length validLength of data, the offset of data in the shared data buffer finishFlag, and all can be initialized to 0. The terminal APP creates a creditor thread creditorThread, which establishes a session and a channel with the creditor wallet through system services, and maintains a state machine to process the two commands RECEIVE CMD1 and RECEIVE CMD2 in strict sequence. The creditor thread is used to send command data to the creditor wallet according to the state machine, and store the response data that needs to be processed in parallel into the shared data buffer shareBuffer of the APP. The terminal APP creates a creditor parallel processing message structure msgParalellforCredit, which contains the valid length validLength of data, the completion flag finishFlag of data reception, and all can be initialized to 0. The structure diagram of the parallel processing message is as shown in Figure 4

[0071] Figure 5 is a processing flow diagram of a digital currency transaction according to an embodiment of the present application, Figure 6 is a schematic diagram of data reception and sending according to an embodiment of the present application.

[0072] As shown in Figure 5 and Figure 6 in an embodiment, the terminal APP sends a first payment command (i.e. PAY CMD1) to the creditor wallet (i.e. payment wallet), and the payment thread receives the first data block of the response data of the first payment command from the payment wallet. Specifically, after the user inputs the transaction amount through the terminal APP, the payment thread of the terminal APP sends the first command PAY CMD1 to the creditor wallet according to the state machine design, the creditor wallet returns the first data block of 256 bytes of the response data of the first payment command PAY CMD1 to the terminal APP, and the terminal APP stores the data returned by the creditor wallet into the shared data buffer.

[0073] ​The payment thread sets the parallel processing message corresponding to the payment thread as valid after receiving a preset number of data blocks of the response data of the first payment command, so as to trigger the payment thread. The preset number is preferably 1, that is, after receiving the first data block of the response data of the first payment command, the parallel processing message corresponding to the payment thread is set as valid, so as to trigger the payment thread, which can minimize the overall interaction time. In this embodiment, specifically, the terminal APP payment thread judges that the 256-byte PAY CMD1 (first payment command) response data can be sent in parallel through the payment thread, and then sets the payment parallel processing message as valid, and writes the length of the PAY CMD1 response data into the valid length of the payment parallel processing message data.

[0074] In the process of receiving the remaining data blocks of the response data of the first payment command by the payment thread, the data valid length in the parallel processing message corresponding to the payment thread is dynamically updated. Specifically, the terminal APP payment thread continues to receive the remaining response data of the PAY CMD1 command through the GET RESPONSE command, places the new response data after the previous response data, and updates the data valid length in the payment parallel processing message.

[0075] After receiving a preset number of data blocks of the response data of the first payment command, the payment thread triggers the payment thread through the message, so that while the payment thread receives the remaining data blocks of the response data of the first payment command, the payment thread generates the data block of the first payment command according to the data blocks of the response data of the first payment command received by the payment thread, and sends the generated data block of the first payment command (i.e. RECEIVE CMD1) to the payment wallet. Specifically, the payment thread checks that the payment parallel processing message is valid, then acquires the received response data of the payment thread from the shared data buffer according to the data length in the message, and sends it to the payment wallet using the RECEIVE CMD1 command. The payment thread records the length of the data sent by itself.

[0076] When the number of commands issued by the payment thread and the payment thread is multiple, the order of the commands issued is determined by the respective state machines maintained by the payment thread and the payment thread. After the payment thread receives all the data blocks of the response data of the first payment command, the value of the data reception completion identifier in the parallel processing message corresponding to the payment thread is set to a specific value, wherein the specific value can be 1. Specifically, the terminal APP payment thread continues to receive the response data of the PAY CMD1 command until the PAY CMD1 data reception is completed, switches the state machine to the PAY CMD2 state, and sets the data reception completion identifier in the payment parallel processing message to 1.

[0077] The collection thread sends the generated data block of the first collection command to the collection wallet, and then counts the length of the data sent to the collection wallet. When the length of the data sent to the collection wallet by the collection thread is equal to the valid length of the data, and the value of the data reception completion identifier in the parallel processing message corresponding to the collection thread is a specific value, the parallel processing message corresponding to the collection thread is restored to the initial state. Specifically, the collection thread continues to send data to the collection wallet until the length of the sent data is equal to the valid length of the data in the collection parallel processing message, and the data reception completion identifier in the message is 1. The identifier of the last piece of data is set in the RECEIVE CMD1 command and sent, and the RECEIVE CMD1 command is completed. The msgParalellforCredit information in the collection parallel processing message structure body is initialized to all 0.

[0078] After the collection thread receives a preset number of data blocks of the response data of the first collection command, the collection thread sets the parallel processing message corresponding to the payment thread to be valid to trigger the payment thread. Specifically, the collection thread enters the data receiving state of the RECEIVE CMD1 response, judges that the response data of the RECEIVE CMD1 can be processed in parallel in the payment thread, and then updates the valid length of the data in the payment parallel processing message and stores the received response data in the shared data buffer area after receiving the response data of the RECEIVE CMD1 response.

[0079] During the process of the collection thread receiving the remaining data blocks of the response data of the first collection command, the valid length of the data in the parallel processing message corresponding to the payment thread is dynamically updated. Specifically, the collection thread continues to receive the remaining response data of the RECEIVE CMD1 command through the GET RESPONSE command, places the new response data after the previous response data, and updates the valid length of the data in the payment parallel processing message.

[0080] After the collection thread receives a preset number of data blocks of the response data of the first collection command, the collection thread is triggered by the message. Specifically, the payment thread checks that the payment parallel processing message is valid, acquires the response data from the shared data buffer area according to the data length in the message, and sends it to the payment wallet using the PAY CMD2 command (second payment command). The payment thread records the length of the data sent by itself.

[0081] After the payment thread receives all data blocks of the response data of the first payment command, the value of the data reception completion identifier in the parallel processing message corresponding to the payment thread is set to a specific value, which can be 1. Specifically, the payment thread continues to receive the response data of the RECEIVE CMD1 command until the response data reception of the RECEIVE CMD1 command is completed, switches the state machine to the REEIVE CMD2 (second payment command) state, and sets the data reception completion identifier to 1 in the payment parallel processing message.

[0082] After the payment thread sends the generated data blocks of the second payment command to the payment wallet, the payment thread counts the length of the data sent to the payment wallet, and in the case that the length of the data sent to the payment wallet by the payment thread is equal to the data valid length of the payment parallel processing message, and the value of the data reception completion identifier in the parallel processing message corresponding to the payment thread is the specific value, the parallel processing message corresponding to the payment thread is restored to the initial state. Specifically, the payment thread continues to execute the PAY CMD2 command until the length of the data sent is equal to the data valid length in the payment parallel processing message, and the data reception completion identifier in the payment parallel processing message is 1, sets the identifier of the last piece of data in the PAY CMD2 command and sends it, and completes the data sending of the PAY CMD2 command. The payment parallel processing message msgParalellforDebt information is initialized to all 0.

[0083] In one embodiment, the REEIVE CMD2 command is executed in sequence according to the order of the state machine, and the entire payment and collection transaction process is completed.

[0084] Figure 7 is a schematic diagram of the main modules of the digital currency transaction device according to one embodiment of the application.

[0085] As shown in Figure 7 , the digital currency transaction 700 according to one embodiment of the application mainly includes a command interaction module 701 and a transaction process end module 702.

[0086] The command interaction module 701 is configured to perform command interaction with the first wallet and the second wallet respectively. During the command interaction, when the first command is sent to the first wallet, the following two operations are performed in parallel: the operation of receiving the response data of the first command from the first wallet in blocks, and the operation of sending the second command to the second wallet in blocks; wherein the data blocks of the second command sent are generated based on the received data blocks of the response data of the first command.

[0087] The transaction process end module 702 is configured to end the digital currency transaction process after completing all command sending and corresponding response data receiving operations with the first wallet and the second wallet.

[0088] In one embodiment, the first wallet is a pay wallet, the first command is a pay command, and the second wallet is a receive wallet, the second command is a receive command; or, the first wallet is a receive wallet, the first command is a receive command, and the second wallet is a pay wallet, the second command is a pay command.

[0089] In one embodiment, the first thread sends the first command to the first wallet and receives the response data of the first command from the first wallet in blocks, and the second thread sends the second command to the second wallet in blocks.

[0090] In one embodiment, the first thread and the second thread respectively determine the order of the issued commands by the state machine maintained by each thread when the number of the issued commands is multiple.

[0091] In one embodiment, the first thread or the second thread switches the maintained state machine to a state of waiting for sending the next command after sending each command.

[0092] In one embodiment, the command interaction module 701 is further configured to: the first thread receives a first data block of the response data of the first command from the first wallet; and after the first thread receives a preset number of data blocks of the response data of the first command, the first thread triggers the second thread by a message, so that the second thread generates a data block of the second command according to the data blocks of the response data of the first command received by the first thread while the first thread receives the remaining data blocks of the response data of the first command, and sends the generated data block of the second command to the second wallet.

[0093] In one embodiment, after the first thread receives a preset number of data blocks of the response data of the first command, the first thread sets the parallel processing message corresponding to the second thread as valid to trigger the second thread.

[0094] In one embodiment, the command interaction module 701 is further configured to: write a data valid length in the parallel processing message corresponding to the second thread according to the received data blocks of the response data of the first command; and the apparatus further comprises a data valid length updating module configured to: dynamically update the data valid length in the parallel processing message corresponding to the second thread in the process that the first thread receives the remaining data blocks of the response data of the first command.

[0095] In one embodiment, the data blocks of the response data of the first command received from the first wallet are stored in a shared data buffer area; and the command interaction module 701 is further configured to: the second thread acquires the data blocks of the response data of the first command from the shared data buffer area according to the data valid length when the second thread checks that the parallel processing message corresponding to the second thread is valid, and generates a data block of the second command according to the acquired data blocks.

[0096] In one embodiment, after the first thread receives all data blocks of the response data of the first command, the value of the data reception completion identifier in the parallel processing message corresponding to the second thread is set to a specific value.

[0097] In one embodiment, after the second thread sends the generated data block of the second command to the second wallet, the second thread counts the length of the data sent to the second wallet, and in the case that the length of the data sent to the second wallet by the second thread is equal to the valid length of the data, and the value of the data reception completion identifier in the parallel processing message corresponding to the second thread is the specific value, the parallel processing message corresponding to the second thread is restored to the initial state.

[0098] In addition, the specific implementation of the digital currency transaction device in the embodiments of the present application has been described in detail in the above digital currency transaction method, and therefore the repeated content will not be described here.

[0099] Figure 8 An exemplary system architecture 800 in which the digital currency transaction method or the digital currency transaction device according to the embodiments of the present application can be applied is shown.

[0100] As shown in Figure 8 The system architecture 800 can include terminal devices 801, 802, 803, a network 804 and a server 805. The network 804 is used as a medium to provide a communication link between the terminal devices 801, 802, 803 and the server 805. The network 804 can include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0101] A user can use the terminal devices 801, 802, 803 to interact with the server 805 through the network 804 to receive or send messages, etc. Various communication client applications can be installed on the terminal devices 801, 802, 803, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).

[0102] The terminal devices 801, 802, 803 can be various electronic devices with display screens and support for web browsing, including but not limited to smartphones, tablet computers, laptop computers and desktop computers, etc.

[0103] The server 805 can be a server that provides various services, such as a background management server that provides support for shopping websites browsed by users using the terminal devices 801, 802, 803 (only as an example). The background management server can analyze and process received transaction information and other data, and feed back the processing results (such as transaction results - only as an example) to the terminal devices.

[0104] It should be noted that the digital currency transaction method provided by the embodiments of the present application is generally executed by the terminal device 801, 802, 803, and accordingly, the digital currency transaction apparatus is generally arranged in the terminal device 801, 802, 803.

[0105] It should be understood that Figure 8 The number of terminal devices, networks and servers in the above-mentioned system is only illustrative. Any number of terminal devices, networks and servers can be provided according to the implementation needs.

[0106] Reference will be made to Figure 9 which shows a structural schematic diagram of a computer system 900 of a terminal device suitable for implementing the embodiments of the present application. Figure 9 The terminal device shown is only an example and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0107] As shown in Figure 9 , the computer system 900 includes a central processing unit (CPU) 901 which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 902 or programs loaded from a storage portion 908 into a random access memory (RAM) 903. Various programs and data required for the operation of the system 900 are also stored in the RAM 903. The CPU 901, the ROM 902 and the RAM 903 are connected to each other through a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0108] The following components are connected to the I / O interface 905: an input portion 906 including a keyboard, a mouse, etc.; an output portion 907 including a display such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage portion 908 including a hard disk, etc.; and a communication portion 909 including a network interface card such as a LAN card, a modem, etc. The communication portion 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the I / O interface 905 as needed. A removable recording medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 910 as needed, so that a computer program read therefrom is installed in the storage portion 908 as needed.

[0109] In particular, the processes described above with reference to the flow charts can be implemented as a computer software program in accordance with the embodiments disclosed herein. For example, embodiments disclosed herein include a computer program product which includes a computer program tangibly embodied on a computer readable medium, the computer program including program code for executing the methods illustrated by the flow charts. In such embodiments, the computer program can be downloaded and installed from a network via the communication portion 909 and / or installed from the removable media 911. When the computer program is executed by the central processing unit (CPU) 901, the above-described functions defined in the system of the present application are executed.

[0110] It should be noted that the computer readable medium shown in the present application can be a computer readable signal medium or a computer readable storage medium or any combination of the two. The computer readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination of the above. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or apparatus. In the present application, the computer readable signal medium can include a data signal carried in a baseband or as a carrier wave in a propagated data signal, in which the computer readable program code is carried. Such a propagated data signal can take many forms, including but not limited to an electromagnetic signal, an optical signal or any suitable combination of the above. The computer readable signal medium can also be any computer readable medium that can send, propagate or transfer a program for use by or in connection with an instruction execution system, device or apparatus. The program code contained on the computer readable medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0111] The computer program product of the present application can be a computer program embodied on a computer readable medium. The computer program product can be stored in the memory 130 and executed by the processor 120 as computer readable instructions. The computer program product can include a process for performing one of the embodiments of the present application on the processor 120 as computer readable instructions. The computer program product can also include a process for performing any related actions on the processor 120 as computer readable instructions. The computer program product can also include a process for performing any related actions on the processor 120 as computer readable instructions.

[0112] The modules described in the embodiments of the present application can be implemented by software, or implemented by hardware. The described modules can also be arranged in a processor, for example, a processor can be described as including a command interaction module, a transaction process ending module. In some cases, the names of these modules do not constitute a limitation on the modules themselves, for example, the transaction process ending module can also be described as "a module for ending the digital currency transaction process after completing all command sending and corresponding response data receiving operations with the first wallet and the second wallet".

[0113] As another aspect, the present application also provides a computer readable medium, which can be included in the device described in the above embodiments, or can exist separately without being assembled into the device. The computer readable medium carries one or more programs, which, when executed by the device, cause the device to include: performing command interaction with the first wallet and the second wallet respectively, and during the command interaction, after sending the first command to the first wallet, performing the following two operations in parallel: an operation of receiving response data of the first command from the first wallet in blocks, and an operation of sending the second command to the second wallet in blocks; wherein the data blocks of the sent second command are generated based on the received data blocks of the response data of the first command; and ending the digital currency transaction process after completing all command sending and corresponding response data receiving operations with the first wallet and the second wallet.

[0114] According to the technical scheme of the embodiment of the present application, the command interaction is respectively performed with the first wallet and the second wallet, and in the process of the command interaction, after the first command is sent to the first wallet, the following two operations are performed in parallel: the operation of receiving the response data of the first command from the first wallet in blocks, and the operation of sending the second command to the second wallet in blocks; wherein the data block of the sent second command is generated based on the received data block of the response data of the first command; after the operation of all command sending and corresponding response data receiving with the first wallet and the second wallet is completed, the digital currency transaction process is ended. Parallel processing of receiving data and sending data can be realized, time consumption of data receiving and sending processing is reduced, and digital currency transaction efficiency is improved.

[0115] The above specific embodiments do not constitute a limitation on the protection scope of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can occur depending on design requirements and other factors. Any modification, equivalent replacement and improvement made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method of digital currency transaction, characterized by, executed by a terminal application; the method comprises: the terminal application respectively performs command interaction with a first wallet and a second wallet, in the process of the command interaction, a first thread in the terminal application sends a first command to the first wallet and receives response data of the first command from the first wallet in blocks, and a second thread in the terminal application sends a second command to the second wallet in blocks; after sending the first command to the first wallet, the terminal application performs the following two operations in parallel: the operation of receiving the response data of the first command from the first wallet in blocks by the terminal application, and the operation of sending the second command to the second wallet in blocks by the terminal application; the terminal application performing the operations in parallel specifically comprises: the first thread stores the data blocks of the response data of the first command received from the first wallet in a shared data buffer area of the terminal application; after receiving a preset number of data blocks of the response data of the first command, the first thread writes a data valid length in a parallel processing message corresponding to the second thread according to the data blocks of the response data of the first command that have been received, sets the parallel processing message corresponding to the second thread as valid, so as to trigger the second thread through a message; and in the process of receiving the remaining data blocks of the response data of the first command by the first thread, the data valid length in the parallel processing message corresponding to the second thread is dynamically updated; while the first thread is receiving the remaining data blocks of the response data of the first command, the second thread, when checking that the parallel processing message corresponding to the second thread is valid, acquires the data blocks of the response data of the first command that have been received by the first thread from the shared data buffer area according to the data valid length, generates data blocks of the second command according to the acquired data blocks, and sends the generated data blocks of the second command to the second wallet; after completing all command sending and corresponding response data receiving operations with the first wallet and the second wallet, the terminal application ends the digital currency transaction process.

2. The method of claim 1, wherein, The first wallet is a payment wallet, the first command is a payment command, and the second wallet is a receiving wallet, and the second command is a receiving command; or, the first wallet is a receiving wallet, the first command is a receiving command, and the second wallet is a payment wallet, and the second command is a payment command.

3. The method of claim 1, wherein, The first thread and the second thread respectively determine the order of the issued commands through the state machines maintained by the first thread and the second thread respectively when the number of the issued commands is multiple.

4. The method of claim 1, wherein, The first thread or the second thread switches the maintained state machine to a state of waiting for sending the next command after sending one command each time.

5. The method of claim 1, wherein, After the first thread receives all data blocks of the response data of the first command, the value of a data receiving completion identifier in the parallel processing message corresponding to the second thread is set to a specific value.

6. The method of claim 5, wherein, The second thread, after sending the generated data block of the second command to the second wallet, counts the length of data sent to the second wallet, and in the case that the length of data sent to the second wallet by the second thread is equal to the valid data length and the value of the data reception completion identifier in the parallel processing message corresponding to the second thread is the specific value, the parallel processing message corresponding to the second thread is restored to the initial state.

7. A digital currency transaction device, characterized by The terminal application program is set to be arranged; The apparatus comprises: The command interaction module is configured to perform command interaction with the first wallet and the second wallet respectively, and in the process of the command interaction, a first thread in the terminal application program is configured to send a first command to the first wallet and receive response data of the first command from the first wallet in blocks, and a second thread in the terminal application program is configured to send a second command to the second wallet in blocks; when the sending of the first command to the first wallet is completed, the following two operations are performed in parallel: the operation of receiving the response data of the first command from the first wallet in blocks by the terminal application program, and the operation of sending the second command to the second wallet in blocks by the terminal application program; the terminal application program performing the operations in parallel specifically comprises: The first thread stores the data block of the response data of the first command received from the first wallet in a shared data buffer area of the terminal application program; after receiving a preset number of data blocks of the response data of the first command, the first thread writes a valid data length in a parallel processing message corresponding to the second thread according to the received data blocks of the response data of the first command, sets the parallel processing message corresponding to the second thread as valid, and triggers the second thread by a message; while the first thread receives the remaining data blocks of the response data of the first command, the second thread, in the case that the parallel processing message corresponding to the second thread is checked as valid, acquires the data blocks of the response data of the first command received by the first thread from the shared data buffer area according to the valid data length, generates data blocks of the second command according to the acquired data blocks, and sends the generated data blocks of the second command to the second wallet; The data valid length updating module is configured to dynamically update the valid data length in the parallel processing message corresponding to the second thread in the process that the first thread receives the remaining data blocks of the response data of the first command. The transaction flow ending module is configured to end the digital currency transaction flow after completing all the command sending and corresponding response data receiving operations with the first wallet and the second wallet.

8. The apparatus of claim 7, wherein, The first wallet is a payment wallet, the first command is a payment command, and the second wallet is a receiving wallet, and the second command is a receiving command; or, the first wallet is a receiving wallet, the first command is a receiving command, and the second wallet is a payment wallet, and the second command is a payment command.

9. The apparatus of claim 7, wherein, The first thread and the second thread respectively determine the order of the issued commands through the state machine maintained by each thread when the number of the issued commands is more than one.

10. The apparatus of claim 7, wherein, The command interaction module switches the state machine maintained by the corresponding thread to a state of sending the next command after sending one command through the first thread or the second thread each time.

11. The apparatus of claim 7, wherein, The command interaction module sets the value of the data reception completion identifier in the parallel processing message corresponding to the second thread to a specific value after the first thread receives all data blocks of the response data of the first command.

12. The apparatus of claim 11, wherein, The command interaction module, after the second thread sends the generated data block of the second command to the second wallet, counts the length of the data sent to the second wallet, and in the case that the length of the data sent to the second wallet by the second thread is equal to the data effective length, and the value of the data reception completion identifier in the parallel processing message corresponding to the second thread is the specific value, restores the parallel processing message corresponding to the second thread to the initial state.

13. An electronic device, comprising: comprising: one or more processors; a memory device for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the method of any one of claims 1-6.

14. A computer readable medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1-6.

Images