Multi-connection transmission method based on super Ethernet, computer readable storage medium, electronic device and computer program product

Abstract

The embodiment of the invention provides a multi-connection transmission method based on a super Ethernet, a computer readable storage medium, an electronic device and a computer program product, and the method comprises the steps: splitting a service flow into a plurality of message delivery context PDC connections; according to the embodiment of the invention, the service flow is transmitted through the plurality of PDC connections, so that the problems of uneven load, low bandwidth utilization rate and inaccurate congestion control encountered in single connection transmission in related technologies can be at least solved, and the overall performance and reliability of network communication are improved.

Description

Technical Field

[0001] Embodiments of the present application relate to the field of communication technology, and in particular, to a multi-connection transmission method based on Super Ethernet, a computer-readable storage medium, an electronic device, and a computer program product. Background Art

[0002] In the current Ultra Ethernet Consortium (UEC) protocol specifications and technologies, service flows are mainly transmitted through a single connection. In a single connection transmission model, the efficiency and reliability of network transmission may be limited by many factors, leading to problems such as uneven load, low bandwidth utilization, and inaccurate congestion control. Summary of the invention

[0003] The embodiments of the present application provide a multi-connection transmission method based on Super Ethernet, a computer-readable storage medium, an electronic device and a computer program product to at least solve the problems of uneven load, low bandwidth utilization and inaccurate congestion control encountered in single connection transmission in the related art.

[0004] According to an embodiment of the present application, a multi-connection transmission method based on Super Ethernet is provided, comprising:

[0005] Split the service flow into multiple Packet Delivery Context (PDC) connections;

[0006] The service flow is transmitted through multiple PDC connections.

[0007] According to another embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when run.

[0008] According to another embodiment of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0009] According to another embodiment of the present application, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0010] Through the above-mentioned embodiments of the present application, the business flow is split into multiple message delivery context PDC connections; transmitting the business flow through multiple PDC connections can at least solve the problems of uneven load, low bandwidth utilization, and inaccurate congestion control encountered in single connection transmission in related technologies, thereby improving the overall performance and reliability of network communications. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 It is a schematic diagram of the structure of the application layer and the transport layer in the related technology;

[0012] Figure 2 It is a schematic diagram of the hierarchical relationship between the service flow, PDC and CCC in the related technology;

[0013] Figure 3 is a flowchart of a multi-connection transmission method based on Super Ethernet according to an embodiment of the present application;

[0014] Figure 4 is a flowchart of a multi-connection transmission mechanism based on the UET transport layer protocol according to an embodiment of the present application;

[0015] Figure 5 It is a schematic diagram of service flow splitting in the UET protocol according to an embodiment of the present application;

[0016] Figure 6 This is a schematic diagram of multi-connection transmission according to an embodiment of the present application. Figure 1 ;

[0017] Figure 7 This is a schematic diagram of multi-connection transmission according to an embodiment of the present application. Figure 2 ;

[0018] Figure 8 This is a schematic diagram of multi-connection transmission according to an embodiment of the present application. Figure 3 ;

[0019] Fig. 9 This is a schematic diagram of multi-connection transmission according to an embodiment of the present application. Figure 4 ;

[0020] Fig.10 This is a schematic diagram of multi-connection transmission according to an embodiment of the present application. Figure 5 ;

[0021] Fig.11 is a schematic diagram of a PDS layer processing flow according to an embodiment of the present application;

[0022] Fig.12 This is a schematic diagram of the message extension format according to the embodiment of the present application. Figure 1 ;

[0023] Fig.13This is a schematic diagram of the message extension format according to the embodiment of the present application. Figure 2 ;

[0024] Fig.14 is a schematic diagram of allocating entropy labels according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] The embodiments of the present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0027] In the current Ultra Ethernet Consortium (UEC) protocol specifications and technologies, there is a lack of definition of a multi-connection mechanism. Since UEC is a connectionless design, the application layer does not perceive and maintain the connection status. Figure 1 It is a schematic diagram of the structure of the application layer and the transport layer in the related technology, such as Figure 1 As shown in the figure, the UEC transport layer is called UET (UECTransport), which is divided into two sublayers: SES (Semantic Sublayer) and PDS (Packet Delivery Sublayer). The PDS sublayer is responsible for establishing a connection, called a PDC (Packet Delivery Context) connection. The application layer only interacts directly with the SES layer and is not aware of the connection status. At the same time, the PDS sublayer does not provide multi-connection transmission function.

[0028] In RoCEv2, each QP connection corresponds to a five-tuple, which is described by {source IP address, destination IP address, protocol field, source UDP port, destination UDP port}. Different QP connections are load balanced through flow-level hashing. In the protocol design of UET, each PDC connection does not correspond to a unique IP five-tuple. This is because multiple PDC connections are bound to a CCC (Congestion Control Context), and each CCC allocates source UDP ports internally. Therefore, multiple PDC connections belonging to the same CCC may have the same five-tuple. Figure 2 It is a schematic diagram of the hierarchical relationship between the service flow, PDC and CCC in the related technology, such as Figure 2As shown, the current UEC has made many improvements in the overall architecture design compared to RoCEv2, but it does not provide a multi-connection transmission design. At the same time, since the UEC application layer adopts a connectionless design, a multi-connection transmission method similar to RoCEv2 cannot be directly transplanted to UEC. In response to the above problems, this application proposes a multi-connection transmission improvement mechanism based on the existing UEC technology.

[0029] In this embodiment, a multi-connection transmission method based on Super Ethernet running on the above architecture is provided. Figure 3 is a flow chart of a multi-connection transmission method based on Super Ethernet according to an embodiment of the present application, such as Figure 3 As shown, the process includes the following steps:

[0030] Step S302, splitting the service flow into multiple message delivery context PDC connections;

[0031] Step S304: Transmit the service flow through multiple PDC connections.

[0032] The embodiments of the present application can significantly improve the efficiency and reliability of data transmission, especially in scenarios with high bandwidth requirements, such as internal communications in data centers, cloud computing resource scheduling, large-scale video streaming transmission, etc., and can fully utilize the multipath and high-bandwidth characteristics of Super Ethernet to achieve efficient data transmission.

[0033] In one implementation of the present application, the above step S302 may specifically include: extending the programming interface of the application layer, wherein the programming interface is used to indicate the use of multi-connection transmission; splitting the service flow into multiple sub-service flows through the application layer, and allocating them to multiple PDC connections of the transport layer; or splitting the service flow into multiple sub-service flows through the transport layer based on the indication of the application layer, and allocating them to multiple PDC connections. In an optional embodiment, the above step S302 may also include: splitting the service flow into multiple sub-service flows through the application layer, and allocating them to multiple PDC connections of the transport layer; then splitting the service flow into multiple sub-service flows through the transport layer based on the indication of the application layer, and allocating them to multiple PDC connections. This implementation enables the application layer to directly control the connection allocation of the transport layer, improves the flexibility of the transmission strategy, and is suitable for scenarios where the transmission path or number of connections needs to be dynamically adjusted, such as path switching and load balancing during network congestion.

[0034] In one embodiment, the programming interface of the extended application layer may specifically include: adding a flow identifier flow-id field in the programming interface, and indicating that the transport layer adopts multi-connection transmission through the flow-id field, wherein sub-service flows with the same flow-id field belong to the same service flow. The flow-id field can ensure that sub-flows belonging to the same service flow are correctly identified and processed at the transport layer, which is crucial for services that require data reorganization and sequence control across connections, such as real-time video conferencing, online games, etc.

[0035] In one embodiment of the present application, the service flow is split into multiple sub-service flows through the application layer, and the multiple PDC connections allocated to the transport layer include: splitting the service flow into multiple sub-service flows at the application layer, and sending PDC connection allocation requests corresponding to the multiple sub-service flows to the SES sublayer of the transport layer respectively, wherein one sub-service flow corresponds to one PDC connection allocation request, and the PDC connection allocation requests corresponding to the multiple sub-service flows all carry the flow-id of the service flow; when the SES sublayer of the transport layer receives the PDC connection allocation request, the message identifier msg-id is allocated to the PDC connection allocation request; when the PDS sublayer of the transport layer receives the PDC connection allocation request of the SES sublayer, the multiple sub-service flows are allocated to the multiple PDC connections according to the msg-id and flow-id carried in the PDC connection allocation request, wherein the flow-id is used to identify the service flow, and the msg-id is used to identify the sub-service flow. This sub-flow allocation mechanism can effectively support multi-connection transmission while ensuring the integrity and sequentiality of the data, and is suitable for scenarios that require high reliability and order-preserving transmission, such as financial transactions, telemedicine, etc.

[0036] In one implementation of the present application, allocating multiple sub-service flows to multiple PDC connections according to the msg-id and flow-id carried in the PDC connection allocation request includes: if the flow-id already exists, allocating different PDC connections for different msg-ids belonging to the flow-id. This mechanism can ensure that even in the same service flow, different data sub-flows can be transmitted through different connections, thereby avoiding single point failures and improving the stability and efficiency of transmission.

[0037] In one implementation of the present application, the method further includes: maintaining a mapping relationship among flow-id, msg-id, and PDC-id in the PDS sublayer, wherein the PDC-id is used to identify the PDC connection; associating a sub-PDC on the PDC connection, wherein the sub-PDC is used to identify whether the PDC connection is a sub-connection. By maintaining these mapping relationships, refined management of multi-connection transmission can be achieved, facilitating troubleshooting and performance optimization in a complex network environment.

[0038] In another embodiment, extending the programming interface of the application layer may include: adding a parameter PDC-num in the programming interface, wherein PDC-num is used to indicate the number of PDC sub-connections established for the service flow. The addition of such a parameter enables the application layer to directly control the number of connections of the transport layer, thereby enhancing the flexibility and controllability of the transmission strategy, and is suitable for scenarios where the number of connections needs to be dynamically adjusted according to network conditions, such as live webcasting, online education, etc.

[0039] In one embodiment of the present application, through the transport layer, the service flow is split into multiple sub-service flows based on the indication of the application layer, and allocated to multiple PDC connections, including: adding PDC-num in the interface from the SES sublayer to the PDS sublayer, and when the SES sublayer of the transport layer receives a transmission request for the service flow, allocating msg-id to the transmission request; establishing an MC-PDC connection through the interface request between the SES sublayer and the PDS sublayer; when the PDS sublayer receives a request to create multiple PDC connections, the service flow is split into multiple sub-service flows, and a PDC multi-connection is created based on PDC-num, wherein the PDC multi-connection includes multiple PDC sub-connections, and each sub-service flow corresponds to a PDC sub-connection. This multi-connection creation mechanism based on PDC-num can realize the intelligent splitting and reorganization of service flows, improve the efficiency and reliability of data transmission, and is suitable for scenarios requiring high throughput and low latency, such as high-definition video on demand and large data transmission.

[0040] In one implementation of the present application, creating a PDC multi-connection based on PDC-num includes: maintaining a mapping relationship between msg-id and a virtual connection; creating multiple PDC connections based on PDC-num, and maintaining a mapping relationship between multiple PDC connections and virtual connections. By maintaining these mapping relationships, dynamic adjustment and optimization of multi-connection transmission can be achieved, improving the utilization of network resources, and is suitable for scenarios that require real-time adjustment of transmission strategies, such as real-time data processing, dynamic network optimization, etc.

[0041] In one embodiment, the method further includes: the extended message carries MC-PDC, and the MC-PDC is used to instruct the target end to establish a reverse MC-PDC connection. This extended message mechanism enables the target end to automatically establish multiple connections according to the instructions of the source end, simplifies the configuration and management of multi-connection transmission, improves the degree of automation of transmission, and is suitable for large-scale network deployment and automated operation and maintenance scenarios, such as cloud computing, the Internet of Things, etc.

[0042] In another embodiment, if the service type of the transmission request is the original service order-preserving ROD mode, multiple PDC connections are provided with order-preserving through the transport layer; or the messages corresponding to the multiple PDC connections carry the parent PSN number of the service flow, wherein the parent PSN number is used to reassemble the messages received by multiple connections at the transport layer of the target end and transmit them to the application layer. This order-preserving mechanism can ensure that even in the case of multi-connection transmission, the data can reach the application layer in the correct order, which is crucial for services that require strict order control, such as online transactions, real-time communications, etc.

[0043] In one embodiment of the present application, transmitting a service flow through multiple PDC connections includes: assigning different entropy labels to multiple PDC connections through an extended congestion control context CCC interface; and transmitting the service flow based on different entropy labels. This entropy label-based transmission mechanism can effectively avoid network congestion, improve the stability and efficiency of transmission, and is suitable for scenarios that require efficient data transmission in complex network environments, such as cross-regional data synchronization, large-scale data distribution, etc.

[0044] The multi-connection transmission provided by this application can not only make full use of the bandwidth resources of Super Ethernet and improve the efficiency and reliability of data transmission, but also realize the flexible allocation and management of business flows by extending the interfaces of the application layer and the transport layer, thereby enhancing the scalability and adaptability of the system. In addition, by carrying additional identification information in the message, the correct reorganization of the message and the order preservation of the business are ensured, providing strong support for high-demand business transmission. This transmission method is particularly suitable for scenarios that require high bandwidth, low latency, high reliability and order-preserving transmission, such as internal communications in data centers, cloud computing resource scheduling, large-scale video streaming, online transactions, real-time communications, etc., and can significantly improve the performance of data transmission and user experience.

[0045] The embodiment of the present application is based on the architecture design of the UET transport layer protocol and proposes a multi-connection transmission mechanism adapted thereto. First, by improving the processing flow of the SES sublayer and the PDS sublayer, a service flow is split into multiple PDC connections; secondly, by redefining the interfaces of the PDC and CCC, different source user datagram protocol (User Datagram Protocol, referred to as UDP) ports are allocated to different PDC connections, and finally a transmission capability of providing multiple connections to the UEC application layer is realized.

[0046] Figure 4 is a flowchart of a multi-connection transmission mechanism based on the UET transport layer protocol according to an embodiment of the present application, such as Figure 4 As shown, the first part splits the business flow into multiple sub-connections for transmission, and the second part allocates a separate entropy label to each sub-connection by improving the CCC interface and process.

[0047] First, a service flow needs to be split into multiple PDC connections, that is, different parts of the service flow use different PDC connections when transmitted over the network. A PDC connection is identified by {Initiator PDC-id, TargetPDC-id}. Specifically, Figure 3 As shown, the present application proposes two methods of splitting a service flow into multiple PDC connections.

[0048] The embodiments of the present application do not limit the combined use of these two stream disassembly methods. For example, the application layer disassembles the stream first and then instructs the transport layer to continue disassembling the stream. Similar extensions are within the design concept of the embodiments of the present application.

[0049] Method 1: Split and reorganize business flows at the application layer;

[0050] Figure 5 is a schematic diagram of business flow splitting in the UET protocol according to an embodiment of the present application, such as Figure 5 As shown in the figure, when the application layer splits the service flow into sub-flows and initiates data transmission separately, each sub-flow will be assigned a msg-id by SES and delivered to the PDS sub-layer. The PDS sub-layer allocates PDC connections for these sub-flows. The PDS protocol stipulates that a PDC connection can be multiplexed by multiple service flows when resources are sufficient. Since these sub-flows have the same source address, destination address, and traffic priority (TrafficClass, referred to as TC), PDS is likely to allocate the same PDC connection to these sub-flows, so the existing solution cannot guarantee splitting into multiple PDC connections.

[0051] In response to this situation, this application proposes to implement PDC connection allocation that perceives application layer sub-flows by improving the application layer interface and PDS process. First, a flow-id field is added to the interface, and sub-flows carrying the same flow-id field belong to the same parent service flow. Typically, flow-id is allocated by the application. One of the simplest ways is to use the current timestamp as the service flow-id, which ensures uniqueness. There is no restriction on the allocation method of flow-id.

[0052] Figure 6 This is a schematic diagram of multi-connection transmission according to an embodiment of the present application. Figure 1 ,like Figure 6As shown, flow-id is added to the SES sublayer and the PDS interface. When the PDS sublayer receives the PDC connection allocation request from the SES sublayer, it checks the request parameters msg-id and flow-id, where flow-id is used to identify the parent service flow and msg-id is used to identify the child service flow. If flow-id exists, different PDC connections are allocated to different msg-ids belonging to the same flow-id. The mapping relationship maintained by PDS becomes: {flow-id, msg-id}->PDC-id. A 1-bit identifier sub-PDC needs to be associated with the PDC to identify whether the PDC connection is a sub-connection.

[0053] Method 2: Split and reassemble the service flow at the transport layer.

[0054] In the existing UEC solution, the PDS sublayer can only establish a single PDC connection. This application proposes another idea to natively support PDC multiple connections in the PDS sublayer, called MC-PDC (Multi Connection PDC). At this time, the application layer programming interface needs to be extended to allow the application layer to instruct the underlying layer to use multiple connections (the application layer still does not perceive the underlying connection status). Typically, the programming interface only needs to add 1 bit of information. For example, MC-PDC=true indicates that the application layer hopes that the underlying layer will use multiple connection transmission. Optionally, a parameter PDC-num is added to indicate how many sub-connections are established for the service flow.

[0055] Figure 7 This is a schematic diagram of multi-connection transmission according to an embodiment of the present application. Figure 2 ,like Figure 7 As shown, in the interface from the SES sublayer to the PDS sublayer, the MC-PDC parameter and PDC-num are also added to transmit application layer requests. When the PDS sublayer receives a request carrying the MC-PDC indication, it creates a PDC multi-connection. The specific method of establishing PDC multi-connections is not limited in this application. Typically, the PDS sublayer first maintains a virtual connection PDC-id, and then creates multiple PDC sub-connections under the virtual connection as needed. Each PDC connection is identified by an {Initiator PDC-id, Target PDC-id}, and the PDS returns the virtual connection identifier to the SES sublayer.

[0056] At this time, two mapping relationships need to be maintained in the PDS sublayer. The first mapping relationship is the existing msg-id->virtual connection PDC-id, and the second mapping is the virtual connection PDC-id->{sub-PDC-id} set. When the PDS sublayer receives the message data from the SES layer, it actively distributes the message message among multiple sub-PDCs. The distribution method may be to distribute in turn according to a certain block size, or it may be other methods, which are not limited in this application.

[0057] Similarly, a 1-bit identifier sub-PDC needs to be associated with the PDC to identify whether the PDC connection is a sub-connection.

[0058] Figure 8 This is a schematic diagram of multi-connection transmission according to an embodiment of the present application. Figure 3 ,like Figure 8 As shown, each PDC connection has its own independent continuous PSN space. Since different sub-PDC connections may take different paths, disorder may occur. If disorder reordering is not required, for example, the application adopts the RUD (Reliable Unordered Delivery) mode, the message format does not need to be extended; if the application layer requires the original service to be in order (for example, the ROD (Reliable Ordered Delivery) mode is adopted), then in addition to the PSN number of the PDC connection itself, the message needs to carry the original service flow parent PSN number. The existing PSN number of the PDC connection is used to ensure transmission reliability, while the parent PSN number is used to reassemble the messages received by multiple connections at the receiving transport layer before delivering them to the application layer.

[0059] This application does not limit the specific extension method of the parent message sequence number (Packet Sequence Number, PSN) in the UEC service message.

[0060] In particular, in UET, for RDMA (Remote Direct Memory Access) Read operations, a separate reverse connection will be established (instead of being bidirectional like a QP connection). The Read operation transfers actual data in the reverse PDC connection. In this case, it is necessary to instruct the reverse transport layer to use multiple connections. At this time, the application layer still only needs to pass in 1 bit of information, and determines whether to establish an MC-PDC connection in the forward or reverse direction based on the operation type (such as Write / Read). For the Read operation, it is necessary to extend the message to carry MC-PDC indication information and optional PDC-num information, so that the other end can follow the MC-PDC process in the reverse direction according to the indication information. Fig. 9 This is a schematic diagram of multi-connection transmission according to an embodiment of the present application. Figure 4 ,like Fig. 9 As shown, other processes such as the actual establishment and interaction of MP-PDC are similar to those of the forward connection and will not be described in detail.

[0061] Through the above two methods, the transport layer provides the application layer with multi-connection transmission capabilities. The application layer only needs to pass in the corresponding request parameters in the programming interface to instruct the transport layer to adopt the corresponding processing flow. That is, if the application layer actively splits the sub-flow, the business flow flow-id identifier is passed in the request parameter; if the application layer wants the underlying transport layer to split into multiple connection transmissions, the mp-PDC identifier is passed in the request parameter, and the PDC-num parameter is optionally passed in.

[0062] The PDC binds to a CCC through an interface request. In existing solutions, multiple PDC connections may be bound to the same CCC, and the CCC is responsible for allocating entropy labels, which are carried in the source UDP port field. Therefore, multiple PDC sub-connections may eventually have the same IP quintuple, which cannot achieve beneficial effects such as load sharing.

[0063] Fig.10 This is a schematic diagram of multi-connection transmission according to an embodiment of the present application. Figure 5 ,like Fig.10 As shown, a 1-bit identifier sub-PDC is added to the interface between the PDC and CCC of the PDS. When the PDC connection is a sub-connection, sub-PDC is set to true in the interface. When the CCC finds that the request parameter carries the sub-PDC identifier, a new CCC is created and bound to the PDC-id. In this way, different sub-PDC-ids will be independently assigned a CCC, thereby assigning different entropy labels.

[0064] In the interface between PDC and CCC, an optional extension may be provided to indicate flow-id (application layer detachment of sub-flows) or parent PDC-id (transport layer detachment of sub-flows) information to help better allocate CCC-ids.

[0065] It should be noted that when CCC allocates entropy labels, it is randomly selected from a set. At this time, multiple sub-PDCs may still be allocated the same entropy label. When allocating entropy labels, the processing flow can be further specified. For example, when allocating entropy labels to PDCs with sub-PDC identifiers, an incremental method is used, that is, entropy label 1 is allocated to the first sub-PDC, entropy label 2 is allocated to the second sub-PDC, and so on. This application does not limit the specific method of CCC allocating entropy labels.

[0066] This embodiment distributes the service flow to multiple PDC connections by splitting the sub-flows at the application layer. Assume that a service application has the ability to split and reassemble the service flow. The application needs to transmit a set of data and hopes to send the data to be transmitted through three PDC connections. The existing UEC transport layer protocol cannot meet this requirement.

[0067] Based on the improved mechanism described in this application, only the transport layer programming interface needs to be extended to support the incoming flow-id, and the application layer assigns a flow-id = 10000 to the service. The programming interface extension example is as follows:

[0068] ssize_tfi_write(structfid_ep*ep, constvoid*buf, size_tlen,

[0069] void*desc, fi_addr_tdest_addr, void*context, long flowld=10000);

[0070] The application layer divides the data to be transmitted into three parts, and initiates a transmission request for each part through the interface, and each part carries flow-id = 10000. When SES receives the transmission request from the application layer, it assigns a msg-id to each request (a simple example is 1, 2, 3), extracts the parameter flow-id = 10000 in the programming interface, and initiates a request to the PDS sublayer. Fig.11 is a schematic diagram of the PDS layer processing flow according to an embodiment of the present application, such as Fig.11 As shown, including:

[0071] For the first request, msg-id=1, flow-id=10000, then check whether there is a mapping associated with flow-id=10000. If no mapping exists, assign a PDC-id=1 to msg-id=1, mark sub-PDC=true, and establish the relationship {msg-id=1, flow-id=10000}->PDC-id=1. Return PDC-id=1 to the first SES request.

[0072] For the second request, msg-id=2, flow-id=10000, then it searches for a mapping associated with flow-id=10000 and finds that PDC-id=1 is associated with flow-id=10000. Then it assigns a PDC-id=2 to msg-id=2, marks sub-PDC=true, and establishes the relationship {msg-id=2, flow-id=10000}->PDC-id=2. PDC-id=2 is returned to the second SES request.

[0073] For the third request, msg-id=3, flow-id=10000, then when searching whether there is a mapping associated with flow-id=10000, it is found that PDC-id=1, 2 are already associated with flow-id=10000, then a PDC-id=3 is assigned to msg-id=3, sub-PDC=true is marked, and the relationship {msg-id=1, flow-id=10000}->PDC-id=3 is established, and PDC-id=3 is returned to the second SES request.

[0074] This embodiment provides multi-connection services to the application layer by natively supporting the MC-PDC mode at the transport layer. An extension is provided in the transport layer programming interface to support the application layer to instruct the transport layer to adopt the multi-connection mode, and optionally supports the number of multi-connections adopted, as shown below.

[0075] ssize_tfi-write(struotfid_ep*ep, constvoid*buf, size_tlen, void*desc, fi_addr_tdest_addr, void*context, MC-PDC=true, PDC-num=3);

[0076] When the SES sublayer receives a transmission request, it assumes that msg-id=1 is assigned to the request.

[0077] The SES determines that the MC-PDC connection is to be established at the originating end through the operation type of fi_write, and then requests to establish the MC-PDC connection through the interface with the PDS, and the number of PDC connections is 3. The interface standard description between the SES and the PDS is informal, and this embodiment does not provide a specific interface example. When the PDS receives the request to create multiple PDC connections, it creates the PDC connection according to the process as follows:

[0078] PDS maintains a virtual PDC connection according to the existing process, PDC-id = 1;

[0079] The PDS maintains the mapping from msg-id=1 to the virtual connection PDC-id=1, and returns the virtual connection PDC-id=1 to the SES;

[0080] According to PDC-num=3, PDS continues to create three new PDCs, namely PDC-id=2, PDC-id=3 and PDC-id=4, mark sub-PDC=true, and bind the three new PDCs to the virtual PDC. Specifically, a mapping is maintained: PDC-id=1->{PDC-id=2, PDC-id=3, PDC-id=4}.

[0081] If SES finds that the operation type is fi_read, the initiator still requests to establish a normal PDC connection, and uses an extended message to carry MC-PDC to instruct the target to establish an MC-PDC connection in the reverse direction. Fig.12 This is a schematic diagram of the message extension format according to the embodiment of the present application. Figure 1 ,like Fig.12 As shown, PDC-num information can be optionally carried. In the SES semantic header, one reserved bit is used to carry MC-PDC=true, and 3 reserved bits are used to carry PDC-num information. After the target end receives the MC-PDC=1 information in the semantic header, it knows that it needs to request PDS to establish an MC-PDC connection in the reverse direction, and the connection establishment process will not be repeated.

[0082] If the application layer initiates a request requiring the service type to be ROD mode, the transport layer is also required to provide order preservation for multiple connections. As described in the invention, it is necessary to carry the parent PSN number in addition to the PSN of the original PDC connection. The parent PSN number is discontinuous in each child PDC message. Fig.13 This is a schematic diagram of the message extension format according to the embodiment of the present application. Figure 2 ,like Fig.13 As shown, it is carried in the PDS message header.

[0083] This embodiment extends the interface between PDC and CCC so that CCC can sense the PDC connection type, thereby allocating different CCCs to sub-PDC connections. Assume that a service has been split into three PDC connections in the manner described in the first embodiment, with PDC-ids 1, 2, and 3, flow-id = 10000, and maintain variables in PDS indicating these three connection types sub-PDC = true.

[0084] When the PDC requests the CCC module to allocate a CCC-id for it, it needs to extend the interface to support the sub-PDC field and optionally support the flow-id field, as shown below:

[0085] AllocateCCC(bool: sprayed=false, sub-PDC=true, flow-id=10000);

[0086] The CCC module creates a new CCC for the request with sub-PDC=true and returns the corresponding CCC-id. Assume that:

[0087] The CCC module receives a binding request with PDC-id=1 and carries sub-PDC=true, creates CCC-id=1 and binds it;

[0088] The CCC module receives a binding request with PDC-id=2, which carries sub-PDC=true, and creates and binds CCC-id=2.

[0089] The CCC module receives a binding request with PDC-id=3, which carries sub-PDC=true, and creates and binds CCC-id=3.

[0090] Fig.14 is a schematic diagram of allocating entropy labels according to an embodiment of the present application, such as Fig.14 As shown, the CCC module can assign a random entropy label to each CCC-id, which will not be described in detail. In order to strictly ensure uniqueness, the CCC can also optionally maintain a variable entropy_Iabel_for_subPDC, which is initially 0 and increments in the entropy label space. For each new request marked as sub-PDC, the assigned entropy label is the current entropy_Iabel_for_subPDC value.

[0091] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0092] In this embodiment, a multi-connection transmission device based on super Ethernet is also provided, which is used to implement the above embodiments and preferred implementation modes, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable. The device includes:

[0093] A splitting module, used for splitting a service flow into multiple message delivery context PDC connections;

[0094] The transmission module is used to transmit the service flow through multiple PDC connections.

[0095] It should be noted that the above modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0096] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

[0097] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0098] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0099] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0100] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.

[0101] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0102] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A multi-connection transmission method based on Super Ethernet, characterized in that: include: Split the service flow into multiple message delivery context PDC connections; The service flow is transmitted through multiple PDC connections.

2. The method according to claim 1, characterized in that Splitting the traffic flow to multiple PDC connections includes: A programming interface of an extended application layer, wherein the programming interface is used to indicate the use of multi-connection transmission; The service flow is split into multiple sub-service flows through the application layer and allocated to multiple PDC connections of the transport layer; or the service flow is split into multiple sub-service flows through the transport layer based on the indication of the application layer and allocated to the multiple PDC connections.

3. The method according to claim 2, characterized in that The programming interfaces of the extended application layer include: A flow identification flow-id field is added to the programming interface, and the flow-id field is used to indicate that the transport layer adopts multi-connection transmission, wherein sub-service flows with the same flow-id field belong to the same service flow.

4. The method according to claim 2, characterized in that: Splitting the service flow into multiple sub-service flows through the application layer and allocating the multiple PDC connections to the transport layer includes: Splitting the service flow into multiple sub-service flows at the application layer, and sending PDC connection allocation requests corresponding to the multiple sub-service flows to the SES sublayer of the transport layer respectively, wherein one sub-service flow corresponds to one PDC connection allocation request, and the PDC connection allocation requests corresponding to the multiple sub-service flows all carry the flow-id of the service flow; When the SES sublayer of the transport layer receives the PDC connection allocation request, assigning a message identifier msg-id to the PDC connection allocation request; When the PDS sublayer of the transport layer receives the PDC connection allocation request of the SES sublayer, the multiple sub-service flows are respectively allocated to the multiple PDC connections according to the msg-id and flow-id carried in the PDC connection allocation request, wherein the flow-id is used to identify the service flow and the msg-id is used to identify the sub-service flow.

5. The method according to claim 4, characterized in that Allocating the multiple sub-service flows to the multiple PDC connections respectively according to the msg-id and flow-id carried in the PDC connection allocation request includes: If the flow-id already exists, different PDC connections are allocated to different msg-ids belonging to the flow-id.

6. The method according to claim 5, characterized in that The method further comprises: Maintaining a mapping relationship among flow-id, msg-id and PDC-id in the PDS sublayer, wherein the PDC-id is used to identify the PDC connection; A sub-PDC is associated with the PDC connection, wherein the sub-PDC is used to identify whether the PDC connection is a sub-connection.

7. The method according to claim 2, characterized in that The programming interfaces of the extended application layer include: A parameter PDC-num is added to the programming interface, wherein the PDC-num is used to indicate the number of PDC sub-connections established for the service flow.

8. The method according to claim 7, characterized in that Splitting the service flow into a plurality of sub-service flows based on an instruction of the application layer through the transport layer, and allocating the sub-service flows to the plurality of PDC connections comprises: Add the PDC-num in the interface from the SES sublayer to the PDS sublayer, and when the SES sublayer of the transport layer receives the transmission request of the service flow, allocate msg-id to the transmission request; Requesting to establish a MC-PDC connection through the interface between the SES sublayer and the PDS sublayer; When the PDS sublayer receives a request to create multiple PDC connections, it splits the service flow into multiple sub-service flows, and creates a PDC multi-connection based on the PDC-num, wherein the PDC multi-connection includes multiple PDC sub-connections, and each sub-service flow corresponds to one PDC sub-connection.

9. The method according to claim 8, characterized in that Creating a PDC multi-connection based on the PDC-num includes: Maintaining the mapping relationship between the msg-id and the virtual connection; A plurality of PDC connections are created based on the PDC-num, and a mapping relationship between the plurality of PDC connections and the virtual connection is maintained.

10. The method according to claim 8, characterized in that The method further comprises: The extended message carries the MC-PDC, and the MC-PDC is used to instruct the target end to establish a MC-PDC connection in the reverse direction.

11. The method according to claim 8, characterized in that The method further comprises: if the service type of the transmission request is the original service order preservation ROD mode, providing order preservation for the multiple PDC connections through the transmission layer; or The messages corresponding to the multiple PDC connections carry the parent PSN number of the service flow, wherein the parent PSN number is used to reassemble the messages received by the multiple connections at the transport layer of the target end and transmit them to the application layer.

12. The method according to claim 1, characterized in that Transmitting the service flow through multiple PDC connections includes: Allocating different entropy labels to the multiple PDC connections by extending the congestion control context CCC interface; The service flow is transmitted based on the different entropy labels.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method described in any one of claims 1 to 11 are implemented.

14. A computer program product, characterized in that The invention comprises a computer program, which implements the steps of the method described in any one of claims 1 to 11 when being executed by a processor.

Images