Mechanism for read workflow

Separate PSN spaces and dedicated acknowledgement packets for RDMA read responses address inefficiencies and complexity in existing RDMA protocols, enhancing reliability and efficiency in multipath transport.

WO2026123169A1PCT designated stage Publication Date: 2026-06-18DOUYIN VISION CO LTD +1

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
DOUYIN VISION CO LTD
Filing Date
2024-12-09
Publication Date
2026-06-18

AI Technical Summary

Technical Problem

The existing RDMA read operation in high-performance transport protocols is inefficient, leading to memory consumption, packet drops, and complex reliability mechanisms due to shared PSN spaces between read requests and responses, particularly in multipath transmission scenarios.

Method used

Implementing separate PSN spaces for read requests and responses, with dedicated acknowledgement packets for read responses, to ensure reliable and efficient transmission.

🎯Benefits of technology

This approach prevents read operations from blocking other messages and simplifies reliability mechanisms, ensuring efficient and reliable transmission of read responses even in multipath environments.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2024137876_18062026_PF_FP_ABST
    Figure CN2024137876_18062026_PF_FP_ABST
Patent Text Reader

Abstract

There are proposed methods, devices, and computer program products for read workflow. In the method, a first device transmits, to a second device, a message for a read request comprising a read request packet. The first device receives a first acknowledgement for the read request packet from the second device. The first device receives one or more read response packets corresponding to a read response message that is for the read request from the second device. The first device transmits a second acknowledgement for the read response message to the second device. In this way, it enables the reliable transmission of read response packets with simple and efficient reliability mechanisms.
Need to check novelty before this filing date? Find Prior Art

Description

MECHANISM FOR READ WORKFLOWFIELD

[0001] The present disclosure generally relates to image processing, and more specifically, to methods, devices and computer program products for read workflow.BACKGROUND

[0002] Remote direct memory access (RDMA) read is a widely-used operation in high-performance transport protocols that enable a requester to read a virtually contiguous block of memory on a responder. Thus, how to optimize the RDMA read operation is worth studying.SUMMARY

[0003] In a first aspect of the present disclosure, there is provided a method implemented at a first device. The method comprises: transmitting, to a second device, a message for a read request comprising a read request packet; receiving a first acknowledgement for the read request packet from the second device; receiving, from the second device, one or more read response packets corresponding to a read response message that is for the read request; and transmitting, to the second device, a second acknowledgement for the read response message.

[0004] In a second aspect of the present disclosure, there is provided a method implemented at a second device. The method comprises: receiving, from a first device, a message for a read request comprising a read request packet; transmitting a first acknowledgement for the read request packet to the first device; transmitting, to the first device, one or more read response packets corresponding to a read response message that is for the read request; and receiving, from the first device, a second acknowledgement for the read response message.

[0005] In a third aspect of the present disclosure, there is provided an electronic device. The electronic device comprises: a computer processor coupled to a computer-readable memory unit, the memory unit comprising instructions that when executed by the computer processor implements a method according to the first or second aspect of the present disclosure.

[0006] In a fourth aspect of the present disclosure, there is provided a computer program product, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by an electronic device to cause the electronic device to perform a method according to the first or second aspect of the present disclosure.

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0008] Through the more detailed description of some implementations of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein the same reference generally refers to the same components in the implementations of the present disclosure.

[0009] Fig. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented;

[0010] Fig. 2 illustrates an example diagram of RDMA write read operation;

[0011] Fig. 3 illustrates an example diagram of network re-ordering in a multipath transmission scenario;

[0012] Fig. 4 illustrates a signaling chart of read workflow according to implementations of the present disclosure;

[0013] Fig. 5 illustrates a schematic diagram of a read request and a read response according to implementations of the present disclosure;

[0014] Fig. 6 illustrates a signaling chart of read workflow according to implementations of the present disclosure;

[0015] Fig. 7 illustrates a signaling chart of outbound packets according to implementations of the present disclosure;

[0016] Fig. 8 illustrates an example flowchart of a method implemented at a first device according to implementations of the present disclosure;

[0017] Fig. 9 illustrates an example flowchart of a method implemented at a second device according to implementations of the present disclosure;

[0018] Fig. 10 illustrates a schematic diagram of an apparatus according to implementations of the present disclosure;

[0019] Fig. 11 illustrates a schematic diagram of an apparatus according to implementations of the present disclosure; and

[0020] Fig. 12 illustrates a block diagram of a computing device in which various implementations of the present disclosure can be implemented.DETAILED DESCRIPTION

[0021] Principle of the present disclosure will now be described with reference to some implementations. It is to be understood that these implementations are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

[0022] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0023] References in the present disclosure to “one implementation, ” “an implementation, ” “an example implementation, ” and the like indicate that the implementation described may include a particular feature, structure, or characteristic, but it is not necessary that every implementation includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same implementation. Further, when a particular feature, structure, or characteristic is described in connection with an example implementation, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other implementations whether or not explicitly described.

[0024] It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example implementations. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0025] The terminology used herein is for the purpose of describing particular implementations only and is not intended to be limiting of example implementations. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0026] Principle of the present disclosure will now be described with reference to some implementations. It is to be understood that these implementations are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below. In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0027] It may be understood that data involved in the present technical solution (including but not limited to the data itself, the acquisition or use of the data) should comply with requirements of corresponding laws and regulations and relevant rules.

[0028] It may be understood that, before using the technical solutions disclosed in various implementation of the present disclosure, the user should be informed of the type, scope of use, and use scenario of the personal information involved in the present disclosure in an appropriate manner in accordance with relevant laws and regulations, and the user’s authorization should be obtained.

[0029] For example, in response to receiving an active request from the user, prompt information is sent to the user to explicitly inform the user that the requested operation will need to acquire and use the user’s personal information. Therefore, the user may independently choose, according to the prompt information, whether to provide the personal information to software or hardware such as electronic devices, applications, servers, or storage media that perform operations of the technical solutions of the present disclosure.

[0030] As an optional but non-limiting implementation, in response to receiving an active request from the user, the way of sending prompt information to the user, for example, may include a pop-up window, and the prompt information may be presented in the form of text in the pop-up window. In addition, the pop-up window may also carry a selection control for the user to choose “agree” or “disagree” to provide the personal information to the electronic device.

[0031] It may be understood that the above process of notifying and obtaining the user authorization is only illustrative and does not limit the implementation of the present disclosure. Other methods that satisfy relevant laws and regulations are also applicable to the implementation of the present disclosure.

[0032] As used herein, the term “Harbour” refers to a communication endpoint in Netbula scalable reliable transport (SRT) protocol, including a send queue (SQ) , a receive queue (RQ) , and an inbound read request queue (IRRQ) . SQ, RQ and IRRQ are always created as a triplet and remain that way throughout their lifetime. A Harbour is identified by its Harbour Number.

[0033] The term “send queue (SQ) ” used herein may refer to a work queue that contains descriptors (or work queue elements (WQEs) ) for outbound messages, including RDMA read request, RDMA write messages and send messages, in the order as the descriptors are posted from applications. The term “receive queue (RQ) ” used herein may refer to a work queue that contains descriptors (or WQEs) that specify where to place inbound data. The term “inbound read request queue (IRRQ) ” used herein may refer to a work queue that contains the inbound read request in the order as they arrive at the responder. The term “completion Queue (CQ) ” used herein may refer to a work queue that contains completion queue elements that represent message completion. A CQ can be multiplexed across multiple Harbours. Work Queue may refer to one of SQ, RQ, CQ or IRRQ. The term “work queue element (WQE) ” may refer to an item in the work queue, usually a descriptor for requests, data, or message completion. RQE may refer to receive queue element, same as receive queue WQE.

[0034] The term “requestor / requester” used herein may refer to a Harbour that initiates the RDMA Read, RDMA write and send operations. It sends out the request packets of RDMA read, RDMA write and send operations. It may more broadly represent the thread, process, network interface card (NIC) or the host that this Harbour belongs to. The term “responder” used herein may refer to a Harbour that accepts request packets of RDMA read, RDMA write and send operations, process the messages, and returns responses. It may more broadly represent the thread, process, NIC or the host that this Harbour belongs to. Requester and responder are usually used as a pair.

[0035] The term “request / request packet” used herein may refer to a packet that requires the receiving endpoint to process them (e.g., do direct memory accesses (DMAs) ) and generate response packets, generated by requesters and received by responders. Request packets include read Request, write Request, send Request. The term “response / response (packet) ” used herein may refer to a packet generated by a responder in response to the reception of request packets. Response packets include acknowledgement packets and read responses. Request and Response are usually used as a pair.

[0036] The term “semantic packet” used herein may refer to a packet that carries semantic meanings, including RDMA read request, RDMA read response, RDMA write request, and send request. The term “acknowledgement packet (ack_pkt) ” used herein may refer to a control packet used by a receiver to acknowledge (positively or negatively) the semantic packets, including acknowledgment (ACK) , negative acknowledgment (NAK) , and selective acknowledgment (SACK) packets. Semantic packet and acknowledgement packet are usually as a pair.

[0037] The term “sender” used herein may refer to the Harbour that sends semantic packets. It will receive acknowledgement packets to ascertain the delivery of semantic packets. Therefore, it is proper to use the phrase “a sender transmits a write request packet and then receives an ACK. ” The term “receiver” used herein may refer to the Harbour that receives semantic packets. It will transmit acknowledgement packets to inform the sender about the arrival of semantic packets. Therefore, it is proper to use the phrase “areceiver receives a write request packet and then transmits an ACK. ”

[0038] The term “ACK” may refer to a positive acknowledgement packet, used to ascertain the arrival of one or more in-order semantic packets (except read responses) , sent by receiver to sender. The term “SACK” used herein may refer to a selective acknowledgment packet, used to selectively ascertain the arrival of both in-order and out-of-order semantic packets (except read responses) . The term “NAK” used herein may refer to a negative acknowledgement packet, used to explicitly inform the sender that one semantic packet (except read responses) has been dropped, possibly dropped by a switch or a receiver (due to insufficient resource) .

[0039] The term “ACK_RRsp” used herein may refer to a positive acknowledgement packet, used to ascertain the arrival of one or more read response packets, sent by receiver to sender. The term “SACK_RRsp” used herein may refer to a selective acknowledgement packet for read responses. The term “NAK_RRsp” used herein may refer to a negative acknowledgement packet, used to explicitly inform the sender of read responses that one read response packet has been dropped, possibly dropped by a switch or a receiver (due to insufficient resource) .

[0040] The term “PSN” refers to Packet Sequence Number, a monotonically increasing sequence number assigned to semantic packets by senders. The term “ePSN” stans for expected PSN, the PSN of the next in-order semantic packet that a receiver expects to receive, i.e., the PSN up to which (exclusive) all the previous packets have been received. This indicates that the packet of ePSN must not have been received, and PSN's larger than ePSN may have been received. The term “unaPSN” refers to unacknowledged PSN, the PSN maintained on the sender before which all packets have been cumulatively acknowledged.

[0041] The term “MSN” refers to message Sequence Number, a monotonically increasing sequence number assigned to messages. The assigner can be requester (for send, write and read request messages) or responder (for read response messages) . The term “eMSN” refers to expected MSN, the MSN associated with the ePSN, also means the MSN up to which (exclusive) all the previous messages have been received by a receiver. The term “unaMSN” refers to unacknowledged MSN, the MSN maintained on the sender before which all packets have been cumulatively acknowledged. The term “RQAMSN” stands for receive queue aligned message sequence number, a monotonically increasing sequence number assigned to messages that consume a receive WQE. The assigner is requester (for Send, Send-with-ImmDt and Write-with-ImmDt) . The term “eRQAMSN” refers to expected RQAMSN, which means the RQAMSN up to which (exclusive) all the previous RQE has been consumed. The term unaRQAMSN” refers to unacknowledged RQAMSN, the RQAMSN maintained on the sender before which all packets have been cumulatively acknowledged.

[0042] Fig. 1 illustrates an example communication environment 100 in which example embodiments of the present disclosure can be implemented. In the communication environment 100, two devices, including a first device 110, and a second device 120 can communicate with each other. In the example of Fig. 1, the first device 110 may act as a received, and the second device 120 may act as a sender.

[0043] It is to be understood that the number of apparatuses and their connections shown in Fig. 1 are only for the purpose of illustration without suggesting any limitation. The communication environment 100 may include any suitable number of apparatuses configured to implementing example embodiments of the present disclosure.

[0044] As mentioned above, RDMA read is a widely-used operation in high-performance transport protocols that enable a requester to read a virtually contiguous block of memory on a responder. Fig. 2 shows an example diagram of RDMA write read operation.

[0045] The requester 210 may assign a packet sequence number (PSN) and a message sequence number (MSN) to a read request and sends a read request packet to the responder . The Read Request packet contains PSN, MSN, and the memory address information of the data on the responder 220. For example, as shown in Fig. 2, the PSN of the read request is 100 and the MSN of the read request is 3.

[0046] After receiving the read request, the responder 220 may start to generate the read response packets with the data. If the data size is larger than a maximum transmission unit (MTU) of the network, the read response needs to be disassembled into multiple packets. The read response packets share the same PSN space as the read request packet, meaning that the PSN of the read response packet starts with the same PSN of the read request. For example, as shown in Fig. 2, the responder 220 generates 3 read responses with PSN 100, 101, and 102.

[0047] The requester 210 may calculate the number of expected read response packets and reserve the corresponding PSNs for the read responses. The message following the read request will not use these PSNs. In the example, as shown in Fig. 2, the requester 210 sends a RDMA write request message with PSN = 102 after the read Request. After receiving the write request packet, the responder 220 needs to finish generating the read responses before processing the write request.

[0048] However, such RDMA Read design has several drawbacks. For example, the RDMA read operation may block the write operation on the responder side. The data in the write operation needs to be cached on the network interface card (NIC) until all the preceding Read Responses are generated. Such a mechanism is very memory consuming and may even lead to packet drops. Further, the retransmissions of read responses are not efficient. The reliability of semantic packets such as write is guaranteed by the acknowledgement packet. The read responses do not have corresponding acknowledgement packets. Hence, the packet drops of read responses can be solely detected by the read request timeout on the requestor side. The retransmission of read responses can only be achieved by the requestor constructing a new read request. Moreover, using one PSN space for both read request and responses may complicate the reliability mechanism for multipath transport protocols.

[0049] In addition, multipath transmission is an emerging technique in high-performance transport protocols. It involves distributing the packets of a connection across multiple network paths to balance the network load. This can lead to packets arriving out-of-order due to varying latencies on different paths. Fig. 3 demonstrates an example of network re-ordering in a multipath transmission scenario. For example, the sender may transmit packets 301, 302 and 303 in sequence. The packets 301, 302 and 303 are transmitted across different network paths (such as, network part 1, network part 2 and network path 3) . Due to different latencies on different paths, the packets may arrive out-of-order. For example, the receiver may first receive the packet 302, then the packet 303 and the packet 301.

[0050] To record out-of-order packet arrivals, the responder maintains a PSN bitmap, each bit mapped a data packet from the sender. The bitmap is also used for other reliability functions, such as message completion detection and slow path detection. If the read request and responses uses one PSN space, a read request would be mapped to N bits in the bitmap where N is the number of corresponding read response packets. Subsequently, other reliability functions that utilize the bitmap need to mark the bitmap segments that mapped to read requests and perform special processes on such segments. This complicated reliability mechanism design.

[0051] The RDMA read operation in current transport protocols may block processing the other messages and is not efficient to retransmit the read response. Moreover, the shared PSN space between read request and responses may make the reliable transmission and completion detection mechanisms in multipath transport protocols very complex. Hence, a new RDMA read operation that can address the above issues is needed.

[0052] According to implementations of the present disclosure, a read operation mechanism is proposed. Specifically, a requester sends an acknowledgement packet for read responses. Further, the Harbour maintains two PSN spaces that separate read Response and other semantic packets. In this way, it enables the reliable transmission of read response packets with simple and efficient reliability mechanisms.

[0053] Example implementations of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0054] Reference is made to Fig. 4 which illustrates a signaling flow of read workflow mechanism for multipath transport protocols. For the purpose of discussion, the signaling flow 400 will be discussed with reference to Fig. 1, for example, by using the first device 110 and the second device 120. The first device 110 may be a requester and the second device 120 may be a responder.

[0055] For the ease of description, implementations of the present disclosure have the following assumptions for the transport protocol. The first device 110 assigns each semantic packet a monotonically increasing packet sequence number (PSN) and each message a monotonically increasing message sequence number (MSN) . The second deice 120 maintains an inbound read request queue (IRRQ) that contains the inbound read request in the order as they arrive at the second device 120. RDMA READ operations enable the first device 110 to read a virtually contiguous block of memory on the second device 120. Prior to issuing an RDMA READ request, the second device 120 may grant permission to the first device 110 to access its memory by providing the first device 110 with a virtual address, length, and remote key (R_key) . Also, the first device 110 may communicate a virtual address and R_key to the second device 120 to offer memory access permission for data placement of read responses. These items may be included in a read request.

[0056] The first device 110 transmits (4005) a message for a read request that includes a read request packet to the second device 120. That is, the second device 120 receives (4005) the message for the read request. The read request can read from zero to 231 bytes (inclusive) of data for reliable connection. As shown in Fig. 5, the read request 510 may include a fundamental transport header (FTH) 511. The first device 110 may place its current PSN in FTH. PSN field of the read request packet. During connection establishment, the transport layer's client programs the next PSN to any value between zero and 4, 294, 967, 295. The initial ePSN value on the second device 120 side may be loaded with the same value. The first device 110 may increment the current PSN (curPSN) value by one for each request packet it generates. The FTH 511 may include the following fields: Opcode, round trip time (RTT) request, packet spray codepoint (PS) , solicited event (SE) , retransmission (Re) , ACK request, pad count (Pad) , packet trimming codepoint (Trim) , connection type (Conn) , transport header version (TVer) , source Harbour, destination Harbour, PSN, MSN, in message packet order (PO) . Table 1 below shows fields in the FTH 511. Table 1

[0057] The read request 510 may also include a read request extended transport header (RReqETH) 512. The RReqETH 512 may include a virtual address field and an R_key field. Table 2 below shows fields in the RReqETH 512. Table 2

[0058] The read request 510 may further include an RDMA extended transport header (RETH) 513 and a cyclic redundancy check (CRC) 514. The RETH 513 may include a virtual address (VA) field, an R_key field and a message length (MsgLen) field. Table 3 below shows fields in the RETH 513. Table 3

[0059] The first device 110 may assign a current MSN (curMSN) to WQEs newly posted to the Send Queue. The curMSN increases monotonically, starting from 0. The first device 110 using reliable connection service may initialize its curMSN value to 0. One SQ WQE may create one or more request packets; especially, a Read Request creates exactly one packet. The position of a packet inside the message it belongs to may be referred to as In-message Packet Order, and it is carried by each request in the FTH. PO field. The first device 110 may calculate this value for a request packet by subtracting the starting PSN of the message from the packet's PSN, so the In-message Packet Order is in range Each packet may also carry the message size, measured in bytes, in the MsgLen field located in either RETH or receive queue aligned extended transport header (RQAETH) . This field, in combination with the In-message Packet Order, enables the second device 120 to verify whether all packets pertaining to a particular message have been successfully received.

[0060] The second device 120 may generate (4008) a first acknowledgement for the read request. The first acknowledgment may be used to inform the first device 110 of the arrival of the read request packet. The first acknowledgement may include a first ePSN that is based on a PSN of the read request packet. The PSN field of the FTH of the first acknowledgment may be populated with ePSN for the read request packet. For example, the second device 120 may determine the first ePSN by increasing the PSN of the read request packet by a predetermined number (such as, 1) . For example, if the PSN of the read request packet is 100, the ePSN for the first acknowledgement is 101. The first acknowledgement may include an MSN that is based on an MSN of the message for the read request. The MSN field of the FTH of the first acknowledgement may be populated with eMSN for the read request packet. For example, the second device 120 may determine an MSN for the first acknowledgement by increasing an MSN of the message for the read request by the predetermined number (such as, 1) . For example, if the MSN of the message for the read request is 3, the MSN for the first acknowledgement is 4.

[0061] The second device 120 transmits (4010) the first acknowledgement for the read request to the first device 110. That is, the first device 110 receives (4010) the first acknowledgement for the read request from the second device 120. The first acknowledgement may not signal the completion of the read request, but may be an ascertainment that the read request has been received by the second device 120.

[0062] The second device 120 may enqueue (4015) the read request to the IRRQ. The IRRQ may be a dedicated queue for inbound uncomplete read requests. The read requests may be enqueued in the order as they arrive at the second device 120. The second device 120 may assign the read request with cMSN_RRsp which increases monotonically, starting from 0. The order of enqueueing (4015) the read request and the generation (4008) and transmission (4010) of the first acknowledgement shown in Fig. 4 is only an example not limitation.

[0063] The second device 120 may generate (4020) the read response message. As shown in Fig. 5, the read response 520 may include FTH 521, RETH 522, read response extended transport header (RRspETH) 523, payload 524 and CRC 525. Fields in FTH 521, RETH 522 are shown in Tables 1 and 3. The RRspETH 523 may include a read request message sequence number echo (MSN_RReq_Echo) field, a status field and reserved field. Table 4 shows fields in RRspETH. Table 4

[0064] In some implementations of the present disclosure, the second device 120 may assign (4025) an MSN to the read response message. The MSN assigned to the read response message may be in an MSN space which is different from an MSN used for a send queue. For example, the FTH. MSN in the read response message may be populated with the MSN_RRsp.

[0065] In some implementations of the present disclosure, the read response message further includes an MSN of the message for the read request. For example, the RRspETH. MSN_RReq_echo field in the read response message is populated with the MSN of its associated Read Request. By way of example, if the MSN of the message for the read request is 3, the MSN included in the read response message may also be 3.

[0066] The second device 120 may generate (4030) one or more read response packets. For example, the second device 120 may generate the one or more read response packets for the read response message based on a size of MTU and a size of the read response message. For example, the read response message may be segmented into the one or more read response packets based on the size of MTU and the size of the read response message.

[0067] The second device 120 may assign (4035) a PSN to each of the one or more read response packets. In some implementations of the present disclosure, the second device 120 may assign curPSN_RRsp for each read response packet. The curPSN_RRsp may increase monotonically, starting from an initial value negotiated during connection establishment. The PSN for read responses and the PSN for Send / Write ack_pkts are in different PSN spaces. For example, the PSN assigned to each read response packet may be in a different PSN space from that of the read request packet. Alternatively, or in addition, the PSN assigned to each read response packet is in a PSN space which is different from a PSN space used for a send queue. In this way, it prevents the RDMA read from blocking other messages on the second device 120.

[0068] The second device 120 transmits (4040) the one or more read response packets to the first device 110. That is, the first device 110 receives (4040) the one or more read response packets from the second device 120. The first device 110 may process the inbound read response packets. The PSN for read responses may be recorded in a separate PSN bitmap for read responses.

[0069] In some implementations of the present disclosure, the read response packets may first go through a validation process to make sure that they are valid. Afterwards, their PSN's are recorded in a PSN bitmap, in which each bit represents a packet's arrival or not. The starting PSN of the response PSN bitmap is ePSN, and the end of it is ePSN plus its length minus 1. Arriving read response packets with PSN larger than the bitmap's end PSN may be dropped silently.

[0070] In some implementations of the present disclosure, for Send and Write-with-ImmDt request packets, the first device 110 may identify their corresponding RQE, which contains the address for the data placement. The first device 110 may locate the RQE by matching the RQAETH. RQAMSN with the sequence number in the Receive Queue. If the number of RQE is insufficient, the first device 110 may be obliged to discard the packet and respond with an RNR-NAK.

[0071] The first device 110 may generate (4045) a second acknowledgment (also referred to as ack_pkts) for the one or more read response packets. The second acknowledgment may be used to inform the second device 120 of the arrival of the read response packets. The second acknowledgment may include a second ePSN that is based on a largest PSN of the one or more read response. The second acknowledgment may also include an expected message sequence number (eMSN) that is based on the message sequence number of the read response message. FTH. MSN and FTH. PSN fields for second acknowledgment may be populated with the eMSN_RRsp and ePSN_RRsp on the second device 120. The ePSN_RRsp and eMSN_RRsp are maintained in the same way as ePSN and eMSN. In some implementations of the present disclosure, the first device 110 may determine a second ePSN for the second acknowledgment by increasing a largest PSN of the one or more read response packets by a predetermined number (such as, 1) . For example, if the largest PSN of the read response packet is 202, the second ePSN for the second acknowledgment may be 203. In some implementations of the present disclosure, the first device 110 may determine an eMSN for the second acknowledgment by increasing the message sequence number of the read response message by the predetermined number (such as, 1) . For example, if the MSN_RRsp is 1 in the read response message, the eMSN in the second acknowledgement may be 2. The second acknowledgment (i.e., ack_pkts) for read response packets may use ACK_RRsp Opcode, to be distinguished from the ACK Opcode.

[0072] The first device 110 transmits (4050) the second acknowledgement for the one or more read response packets to the second device 120. That is, the second device 120 receives (4050) the second acknowledgement from the first device 110. In this way, it enables reliable transmission of read response packets.

[0073] The first device 110 may complete (4055) the read request, if all read response packets associated with the read request are received. In some implementations of the present disclosure, the first device 110 may verify if read response packets of the read request have all been received. This may resume the SQ completion process. For example, the first device 110 can determine that messages with a MSN smaller than the eMSN returned by ack_pkts have been completed. Consequently, the increase in eMSN from new ack_pkts means the number of WQEs that the first device 110 can retire from the corresponding Harbour's SQ.

[0074] In some implementations of the present disclosure, when there are outstanding read request WQEs in the SQ, the first device may only complete outstanding WQEs up to either the first outstanding RDMA READ request, or the WQE of which MSN matches the new eMSN, whichever comes first. Therefore, when a read request WQE is encountered during the completion process, the first device 110 may verify that this read request has been fully responded to before marking it as completed.

[0075] In some implementations of the present disclosure, the second device 120 may determine (4060) whether the eMSN in the second acknowledgment is larger than a last received Emsn. In this case, if the eMSN in the second acknowledgment is larger than the last received eMSN, the second device 120 may dequeue (4065) a number of read requests from the IRRQ. For example, the second device 120 may determine that read response messages with an MSN smaller than the eMSN_RRsp returned by ack_pkts have been completed. Consequently, the increase in eMSN from new ack_pkts corresponds to the number of read requests that the second device 120 can remove from the IRRQ.

[0076] Reference is made to Fig. 6 which illustrates a signaling flow of read workflow mechanism for multipath transport protocols. For the purpose of discussion, the signaling flow 600 will be discussed by using the requester 610 and the responder 620. For example, the requestor 610 may be implemented at the first device 110 and the second responder 620 may be implemented at the second device 120.

[0077] The requester 610 may send (6005) a read request packet to the responder 620. The PSN of the read request packet may be 100 and the MSN of the read request packet may be 3.

[0078] Upon receiving the read request, the responder 620 may reply (6010) an ACK to the requester 610. This ACK does not signal the completion of the read request, but is an ascertainment that the read request has been received by the responder 620. The ACK may include an ePSN which is equal to 101 and an MSN which is equal to 4.

[0079] The responder 620 may maintain an SQ 650 and an IRRQ 660. The responder 610 may enqueue (6015) the read request to the IRRQ 660, which is a dedicated queue for inbound uncompleted read requests. Then the responder 620 may generate a read response message for each read request in the IRRQ 660, and assign an MSN to each read response message, i.e., MSN_RRsp. The MSN_RRsp increases monotonically, starting from 0.

[0080] The responder 620 may send out (6020-1, 6020-2, 6020-3) read response packets as instructed by the read requests in the IRRQ 660. For one read request, the responder 620 may generate multiple read response packets based on the message size and MTU. Each of the read response packet may carrier data that is requested by the requester 610. For example, as shown in Fig. 6, a first segment (i.e., a first read response packet) may include a PSN which is equal to 200, an MSN_RRsp (i.e., assigned by the responder 620) which is equal to 1, and an MSN_RReq_Echo which is equal to 3 (i.e., same as the MSN in the request packet) , a second segment (i.e., a second read response packet) may include a PSN which is equal to 201, an MSN_RRsp which is equal to 1, and an MSN_RReq_Echo which is equal to 3, and a third segment (i.e., a third read response packet) may include a PSN which is equal to 202, an MSN_RRsp which is equal to 1, and an MSN_RReq_Echo which is equal to 3. The packets from the Harbour's IRRQ and packets from the same Harbour's SQ are in separate PSN spaces.

[0081] The requester 610 may receive (6020-1, 6020-2, 6020-3) the read response packets and reply (6025) ack_pkts to acknowledge their arrival. When the received read response packets fill some "holes"in the PSN range, the ePSN and eMSN may be able to advance, and they are returned to the responder 620 via acknowledgement packets. For example, the ack_pkts may include PSN=203 and MSN= 2. The ack_pkts for read response packets may use ACK_RRsp Opcode, to be distinguished from the ACK Opcode. After all the read response packets associated with the read request are received, the requester 610 may be able to complete the RDMA read request.

[0082] The responder 620 may receive (6025) the ack_pkts. When the eMSN in the ack_pkts has advanced compared with the last received eMSN, the responder 620 may dequeue (6030) a number of read requests from the IRRQ 660. And the number is new eMSN -old eMSN.

[0083] In some implementations of the present disclosure, a Harbour's outbound packets are in two separate PSN spaces, each for SQ and IRRQ. There is no relationship between the PSNs used by the send queue and IRRQ of a Harbour, or between different connections. Similarly, there is no relationship between the MSN used by a Harbour's SQ and MSN_RRsq used by its IRRQ. Fig. 7 illustrates a signaling chart of outbound packets according to implementations of the present disclosure. For the purpose of discussion, the signaling flow 700 will be discussed by using the Harbour 710. For example, the Harbour 710 may be implemented at the first device 110 or the second device 120.

[0084] The Harbour 710 may maintain an SQ 720 and an IRRQ 730. The Harbour 710 may transmit three packets for the request 7 in SQ 720. The PSNs for the three packets of the request 7 may be from SQ PSN space. For example, the PSNs for the packets are 100, 101 and 102. The MSN for the response message for the request 7 may be from SQ MSN space. For example, the MSN for the response message may be 7.

[0085] The Harbour 710 may transmit two packets for the request 3 in IRRQ 730. The PSNs for the two packets of the request 3 in IRRQ 730 may be from IRRQ PSN space. For example, the PSNs for the packets are 15 and 16. There is not relationship between the PSNs for the two packets of the request 3 in IRRQ 730 and the PSNs for three packets for the request 7 in SQ 720. The MSN for the response message for the request 3 may be from IRRQ MSN space. For example, the MSN for the response message may be 3.

[0086] The Harbour 710 may transmit three packets for the request 8 in SQ 720. The PSNs for the three packets of the request 8 in SQ 720 may be from SQ PSN space which is also used for the packets for the request 7. For example, the PSNs for the packets are 103, 104 and 105. The MSN for the response message for the request 8 may be from SQ MSN space. For example, the MSN for the response message may be 8.

[0087] According to implementations of the present disclosure, a method is provided for read workflow mechanism. Reference will be made to Fig. 8 for more details about the method, where Fig. 8 illustrates an example flowchart of a method 800 according to implementations of the present disclosure. At block 810, transmitting, to a second device, a message for a read request comprising a read request packet. At block 820, receiving a first acknowledgement for the read request packet from the second device. At block 830, receiving, from the second device, one or more read response packets corresponding to a read response message that is for the read request. At block 840, transmitting, to the second device, a second acknowledgement for the read response message.

[0088] In some implementations of the present disclosure, the read response message comprises a message sequence number assigned by the second device, and the message sequence number assigned to the read response message is in a message sequence number space which is different from a message sequence number space used for a send queue.

[0089] In some implementations of the present disclosure, the read response message further comprises a message sequence number of the message for the read request.

[0090] In some implementations of the present disclosure, each of the one or more read response packets comprises a packet sequence number that is in a different packet sequence number space from that of the read request packet.

[0091] In some implementations of the present disclosure, the read response message is segmented into the one or more read response packets based on a size of maximum transmission unit and a size of the read response message.

[0092] In some implementations of the present disclosure, the first acknowledgment comprises a first expected packet sequence number that is based on a packet sequence number of the read request packet and a message sequence number that is based on a message sequence number of the message for the read request.

[0093] In some implementations of the present disclosure, the method 800 further includes determining a second expected packet sequence number for the second acknowledgment by increasing a largest sequence number of the one or more read response packets by a predetermined number; and determining an expected message sequence number for the second acknowledgment by increasing the message sequence number of the read response message by the predetermined number.

[0094] In some implementations of the present disclosure, the method 800 further includes in response to that all read response packets associated with the read request are received, completing the read request.

[0095] Reference will be made to Fig. 9 for more details about the method, where Fig. 9 illustrates an example flowchart of a method 900 according to implementations of the present disclosure. At block 910, receiving, from a first device, a message for a read request comprising a read request packet. At block 920, transmitting a first acknowledgement for the read request packet to the first device. At block 930, transmitting, to the first device, one or more read response packets corresponding to a read response message that is for the read request. At block 940, receiving, from the first device, a second acknowledgement for the read response message.

[0096] In some implementations of the present disclosure, the method 900 further includes enqueueing the read request to an inbound read request queue; generating the read response message for the read request; and assigning a message sequence number to the read response message.

[0097] In some implementations of the present disclosure, the message sequence number assigned to the read response message is in a message sequence number space which is different from a message sequence number space used for a send queue.

[0098] In some implementations of the present disclosure, the method 900 further includes generating the one or more read response packets for the read response message based on a size of maximum transmission unit and a size of the read response message; and assigning a packet sequence number to each of the one or more read response packets.

[0099] In some implementations of the present disclosure, the packet sequence number assigned to each read response packet is in a packet sequence number space which is different from a packet sequence number space used for a send queue.

[0100] In some implementations of the present disclosure, the read response message further comprises a message sequence number of the message for the read request.

[0101] In some implementations of the present disclosure, the method 900 further includes determining a first expected packet sequence number for the first acknowledgment by increasing a packet sequence number of the read request packet by a predetermined number; and determining a message sequence number for the first acknowledgement by increasing a message sequence number of the message for the read request by the predetermined number.

[0102] In some implementations of the present disclosure, the second acknowledgment comprises a second expected packet sequence number that is based on a largest packet sequence number of the one or more read response packets and an expected message sequence number that is based on the message sequence number of the read response message.

[0103] In some implementations of the present disclosure, the method 900 further includes determining whether the expected message sequence number in the second acknowledgment is larger than a last received expected message sequence number; and in response to determining that the expected message sequence number in the second acknowledgment is larger than the last received expected message sequence number, dequeuing a number of read requests from the inbound read request queue.

[0104] According to implementations of the present disclosure, an apparatus 1000 is provided for read workflow. The apparatus comprises: a first transmitting module 1010 configured to transmit, to a second device, a message for a read request comprising a read request packet; a first receiving module 1020 configured to receive a first acknowledgement for the read request packet from the second device; a second receiving module 1030 configured to receive, from the second device, one or more read response packets corresponding to a read response message that is for the read request; and a second transmitting module 1040 configured to transmit, to the second device, a second acknowledgement for the read response message. Further, the apparatus may comprise other modules for implementing other steps in the method 800.

[0105] According to implementations of the present disclosure, an apparatus 1100 is provided for read workflow. The apparatus comprises: a first receiving module 1110 configured to receive, from a first device, a message for a read request comprising a read request packet; a first transmitting module 1120 configured to transmit a first acknowledgement for the read request packet to the first device; a second transmitting module 1130 configured to transmit, to the first device, one or more read response packets corresponding to a read response message that is for the read request; and a second receiving module 1140 configured to receive, from the first device, a second acknowledgement for the read response message. Further, the apparatus may comprise other modules for implementing other steps in the method 900.

[0106] According to implementations of the present disclosure, an electronic device is provided for implementing the method 800. The electronic device comprises: a computer processor coupled to a computer-readable memory unit, the memory unit comprising instructions that when executed by the computer processor implements a method. The method comprises: transmitting, to a second device, a message for a read request comprising a read request packet; receiving a first acknowledgement for the read request packet from the second device; receiving, from the second device, one or more read response packets corresponding to a read response message that is for the read request; and transmitting, to the second device, a second acknowledgement for the read response message.

[0107] In some implementations of the present disclosure, the read response message comprises a message sequence number assigned by the second device, and the message sequence number assigned to the read response message is in a message sequence number space which is different from a message sequence number space used for a send queue.

[0108] In some implementations of the present disclosure, the read response message further comprises a message sequence number of the message for the read request.

[0109] In some implementations of the present disclosure, each of the one or more read response packets comprises a packet sequence number that is in a different packet sequence number space from that of the read request packet.

[0110] In some implementations of the present disclosure, the read response message is segmented into the one or more read response packets based on a size of maximum transmission unit and a size of the read response message.

[0111] In some implementations of the present disclosure, the first acknowledgment comprises a first expected packet sequence number that is based on a packet sequence number of the read request packet and a message sequence number that is based on a message sequence number of the message for the read request.

[0112] In some implementations of the present disclosure, the method further includes determining a second expected packet sequence number for the second acknowledgment by increasing a largest sequence number of the one or more read response packets by a predetermined number; and determining an expected message sequence number for the second acknowledgment by increasing the message sequence number of the read response message by the predetermined number.

[0113] In some implementations of the present disclosure, the method further includes in response to that all read response packets associated with the read request are received, completing the read request.

[0114] According to implementations of the present disclosure, an electronic device is provided for implementing the method 900. The electronic device comprises: a computer processor coupled to a computer-readable memory unit, the memory unit comprising instructions that when executed by the computer processor implements a method. The method comprises: receiving, from a first device, a message for a read request comprising a read request packet; transmitting a first acknowledgement for the read request packet to the first device; transmitting, to the first device, one or more read response packets corresponding to a read response message that is for the read request; and receiving, from the first device, a second acknowledgement for the read response message.

[0115] In some implementations of the present disclosure, the method further includes enqueueing the read request to an inbound read request queue; generating the read response message for the read request; and assigning a message sequence number to the read response message.

[0116] In some implementations of the present disclosure, the message sequence number assigned to the read response message is in a message sequence number space which is different from a message sequence number space used for a send queue.

[0117] In some implementations of the present disclosure, the method further includes generating the one or more read response packets for the read response message based on a size of maximum transmission unit and a size of the read response message; and assigning a packet sequence number to each of the one or more read response packets.

[0118] In some implementations of the present disclosure, the packet sequence number assigned to each read response packet is in a packet sequence number space which is different from a packet sequence number space used for a send queue.

[0119] In some implementations of the present disclosure, the read response message further comprises a message sequence number of the message for the read request.

[0120] In some implementations of the present disclosure, the method further includes determining a first expected packet sequence number for the first acknowledgment by increasing a packet sequence number of the read request packet by a predetermined number; and determining a message sequence number for the first acknowledgement by increasing a message sequence number of the message for the read request by the predetermined number.

[0121] In some implementations of the present disclosure, the second acknowledgment comprises a second expected packet sequence number that is based on a largest packet sequence number of the one or more read response packets and an expected message sequence number that is based on the message sequence number of the read response message.

[0122] In some implementations of the present disclosure, the method further includes determining whether the expected message sequence number in the second acknowledgment is larger than a last received expected message sequence number; and in response to determining that the expected message sequence number in the second acknowledgment is larger than the last received expected message sequence number, dequeuing a number of read requests from the inbound read request queue.

[0123] According to implementations of the present disclosure, a computer program product, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by an electronic device to cause the electronic device to perform the method 800 or 900.

[0124] Fig. 12 illustrates a block diagram of a computing device 1200 in which various implementations of the present disclosure can be implemented. It would be appreciated that the computing device 1200 shown in Fig. 12 is merely for purpose of illustration, without suggesting any limitation to the functions and scopes of the present disclosure in any manner. The computing device 1200 may be used to implement the above method 1200 in implementations of the present disclosure. As shown in Fig. 12, the computing device 1200 may be a general-purpose computing device. The computing device 1200 may at least comprise one or more processors or processing units 1210, a memory 1220, a storage unit 1230, one or more communication units 1240, one or more input devices 1250, and one or more output devices 1260.

[0125] The processing unit 1210 may be a physical or virtual processor and can implement various processes based on programs stored in the memory 1220. In a multi-processor system, multiple processing units execute computer executable instructions in parallel so as to improve the parallel processing capability of the computing device 1200. The processing unit 1210 may also be referred to as a central processing unit (CPU) , a microprocessor, a controller, or a microcontroller.

[0126] The computing device 1200 typically includes various computer storage medium. Such medium can be any medium accessible by the computing device 1200, including, but not limited to, volatile and non-volatile medium, or detachable and non-detachable medium. The memory 1220 can be a volatile memory (for example, a register, cache, Random Access Memory (RAM) ) , a non-volatile memory (such as a Read-Only Memory (ROM) , Electrically Erasable Programmable Read-Only Memory (EEPROM) , or a flash memory) , or any combination thereof. The storage unit 1230 may be any detachable or non-detachable medium and may include a machine-readable medium such as a memory, flash memory drive, magnetic disk, or another other media, which can be used for storing information and / or data and can be accessed in the computing device 1200.

[0127] The computing device 1200 may further include additional detachable / non-detachable, volatile / non-volatile memory medium. Although not shown in Fig. 12, it is possible to provide a magnetic disk drive for reading from and / or writing into a detachable and non-volatile magnetic disk and an optical disk drive for reading from and / or writing into a detachable non-volatile optical disk. In such cases, each drive may be connected to a bus (not shown) via one or more data medium interfaces.

[0128] The communication unit 1240 communicates with a further computing device via the communication medium. In addition, the functions of the components in the computing device 1200 can be implemented by a single computing cluster or multiple computing machines that can communicate via communication connections. Therefore, the computing device 1200 can operate in a networked environment using a logical connection with one or more other servers, networked personal computers (PCs) or further general network nodes.

[0129] The input device 1250 may be one or more of a variety of input devices, such as a mouse, keyboard, tracking ball, voice-input device, and the like. The output device 1260 may be one or more of a variety of output devices, such as a display, loudspeaker, printer, and the like. By means of the communication unit 1240, the computing device 1200 can further communicate with one or more external devices (not shown) such as the storage devices and display device, with one or more devices enabling the user to interact with the computing device 1200, or any devices (such as a network card, a modem, and the like) enabling the computing device 1200 to communicate with one or more other computing devices, if required. Such communication can be performed via input / output (I / O) interfaces (not shown) .

[0130] In some implementations of the present disclosure, instead of being integrated in a single device, some, or all components of the computing device 1200 may also be arranged in cloud computing architecture. In the cloud computing architecture, the components may be provided remotely and work together to implement the functionalities described in the present disclosure. In some implementations of the present disclosure, cloud computing provides computing, software, data access and storage service, which will not require end users to be aware of the physical locations or configurations of the systems or hardware providing these services. In various implementations, the cloud computing provides the services via a wide area network (such as Internet) using suitable protocols. For example, a cloud computing provider provides applications over the wide area network, which can be accessed through a web browser or any other computing components. The software or components of the cloud computing architecture and corresponding data may be stored on a server at a remote position. The computing resources in the cloud computing environment may be merged or distributed at locations in a remote data center. Cloud computing infrastructures may provide the services through a shared data center, though they behave as a single access point for the users. Therefore, the cloud computing architectures may be used to provide the components and functionalities described herein from a service provider at a remote location. Alternatively, they may be provided from a conventional server or installed directly or otherwise on a client device.

[0131] The functionalities described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs) , Application-specific Integrated Circuits (ASICs) , Application-specific Standard Products (ASSPs) , System-on-a-chip systems (SOCs) , Complex Programmable Logic Devices (CPLDs) , and the like.

[0132] Program code for carrying out the methods of the subject matter described herein may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general-purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely or partly on a machine, executed as a stand-alone software package partly on the machine, partly on a remote machine, or entirely on the remote machine or server.

[0133] In the context of this disclosure, a machine-readable medium may be any tangible medium that may contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium would include 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 disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0134] Further, while operations are illustrated in a particular order, this should not be understood as requiring that such operations are performed in the particular order shown or in sequential order, or that all illustrated operations are performed to achieve the desired results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the subject matter described herein, but rather as descriptions of features that may be specific to particular implementations. Certain features that are described in the context of separate implementations may also be implemented in combination in a single implementation. Rather, various features described in a single implementation may also be implemented in multiple implementations separately or in any suitable sub-combination.

[0135] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter specified in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

[0136] From the foregoing, it will be appreciated that specific implementations of the presently disclosed technology have been described herein for purposes of illustration, but that various modifications may be made without deviating from the scope of the disclosure. Accordingly, the presently disclosed technology is not limited except as by the appended claims.

[0137] Implementations of the subject matter and the functional operations described in the present disclosure can be implemented in various systems, digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible and non-transitory computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term “data processing unit” or “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0138] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document) , in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code) . A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0139] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0140] It is intended that the specification, together with the drawings, be considered exemplary only, where exemplary means an example. As used herein, the use of “or” is intended to include “and / or” , unless the context clearly indicates otherwise.

[0141] While the present disclosure contains many specifics, these should not be construed as limitations on the scope of any disclosure or of what may be claimed, but rather as descriptions of features that may be specific to particular implementations of particular disclosures. Certain features that are described in the present disclosure in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

[0142] Similarly, while operations are illustrated in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Moreover, the separation of various system components in the implementations described in the present disclosure should not be understood as requiring such separation in all implementations. Only a few implementations and examples are described and other implementations, enhancements and variations can be made based on what is described and illustrated in the present disclosure.

Claims

1.A method implemented at a first device, comprising:transmitting, to a second device, a message for a read request comprising a read request packet;receiving a first acknowledgement for the read request packet from the second device;receiving, from the second device, one or more read response packets corresponding to a read response message that is for the read request; andtransmitting, to the second device, a second acknowledgement for the read response message.2.The method of claim 1, wherein the read response message comprises a message sequence number assigned by the second device, and the message sequence number assigned to the read response message is in a message sequence number space which is different from a message sequence number space used for a send queue.3.The method of claim 1 or 2, wherein the read response message further comprises a message sequence number of the message for the read request.4.The method of any of claims 1-3, wherein each of the one or more read response packets comprises a packet sequence number that is in a different packet sequence number space from that of the read request packet.5.The method of any of claims 1-4, wherein the read response message is segmented into the one or more read response packets based on a size of maximum transmission unit and a size of the read response message.6.The method of any of claims 1-5, wherein the first acknowledgment comprises a first expected packet sequence number that is based on a packet sequence number of the read request packet and a message sequence number that is based on a message sequence number of the message for the read request.7.The method of any of claims 1-6, further comprising:determining a second expected packet sequence number for the second acknowledgment by increasing a largest sequence number of the one or more read response packets by a predetermined number; anddetermining an expected message sequence number for the second acknowledgment by increasing the message sequence number of the read response message by the predetermined number.8.The method of any of claims 1-7, further comprising:in response to that all read response packets associated with the read request are received, completing the read request.9.A method implemented at a second device, comprising:receiving, from a first device, a message for a read request comprising a read request packet;transmitting a first acknowledgement for the read request packet to the first device;transmitting, to the first device, one or more read response packets corresponding to a read response message that is for the read request; andreceiving, from the first device, a second acknowledgement for the read response message.10.The method of claim 9, further comprising:enqueueing the read request to an inbound read request queue;generating the read response message for the read request; andassigning a message sequence number to the read response message.11.The method of claim 10, wherein the message sequence number assigned to the read response message is in a message sequence number space which is different from a message sequence number space used for a send queue.12.The method of any of claims 9-11, further comprising:generating the one or more read response packets for the read response message based on a size of maximum transmission unit and a size of the read response message; andassigning a packet sequence number to each of the one or more read response packets.13.The method of claim 12, wherein the packet sequence number assigned to each read response packet is in a packet sequence number space which is different from a packet sequence number space used for a send queue.14.The method of any of claims 9-13, wherein the read response message further comprises a message sequence number of the message for the read request.15.The method of any of claims 9-14, further comprising:determining a first expected packet sequence number for the first acknowledgment by increasing a packet sequence number of the read request packet by a predetermined number; anddetermining a message sequence number for the first acknowledgement by increasing a message sequence number of the message for the read request by the predetermined number.16.The method of any of claims 9-15, wherein the second acknowledgment comprises a second expected packet sequence number that is based on a largest packet sequence number of the one or more read response packets and an expected message sequence number that is based on the message sequence number of the read response message.17.The method of any of claims 9-16, further comprising:determining whether the expected message sequence number in the second acknowledgment is larger than a last received expected message sequence number; andin response to determining that the expected message sequence number in the second acknowledgment is larger than the last received expected message sequence number, dequeuing a number of read requests from the inbound read request queue.18.An electronic device, comprising a computer processor coupled to a computer-readable memory unit, the memory unit comprising instructions that when executed by the computer processor implements the method of any of claims 1-8.19.An electronic device, comprising a computer processor coupled to a computer-readable memory unit, the memory unit comprising instructions that when executed by the computer processor implements the method of any of claims 9-17.20.A first device, comprising:a first transmitting module configured to transmit, to a second device, a message for a read request comprising a read request packet;a first receiving module configured to receive a first acknowledgement for the read request packet from the second device;a second receiving module configured to receive, from the second device, one or more read response packets corresponding to a read response message that is for the read request; anda second transmitting module configured to transmit, to the second device, a second acknowledgement for the read response message.21.A second device, comprising:a first receiving module configured to receive, from a first device, a message for a read request comprising a read request packet;a first transmitting module configured to transmit a first acknowledgement for the read request packet to the first device;a second transmitting module configured to transmit, to the first device, one or more read response packets corresponding to a read response message that is for the read request; anda second receiving module configured to receive, from the first device, a second acknowledgement for the read response message.22.A non-transitory computer program product, the non-transitory computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by an electronic device to cause the electronic device to perform a method of any of claims 1-8 or any of claims 9-17.