Data packet sending method and device, electronic equipment and storage medium

Abstract

The application discloses a data packet sending method and device, electronic equipment and storage medium, and relates to the technical field of communication. The method comprises the following steps: determining the bandwidth quota of the data stream sent by a source cross-domain communication device to each first cross-domain communication device to generate a token table, wherein the source cross-domain communication device has access permission of the first cross-domain communication device, and the sum of the bandwidth quotas of the data streams sent by the multiple cross-domain communication devices having the access permission of the first cross-domain communication device to the first cross-domain communication device is not greater than the maximum data bandwidth of the first cross-domain communication device; determining a target cross-domain communication device based on a to-be-sent data packet, and then determining the total number of first tokens possessed by the data stream sent by the source cross-domain communication device to the target cross-domain communication device; and if the number of tokens required by the to-be-sent data packet is not greater than the total number of first tokens, the to-be-sent data packet is sent to the target cross-domain communication device. The technical effect of avoiding congestion and improving overall communication efficiency is achieved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to data packet transmission methods, apparatus, electronic devices, and storage media. Background Technology

[0002] In high-speed serial computer expansion bus standard (Peripheral Component Interconnect express, PCIe) multi-host systems based on Non-Transparent Bridge (NTB) technology, each host domain pairs with NT endpoint devices in other host domains through its non-transparent (NT) endpoint devices to achieve cross-domain communication. When multiple NT endpoint devices (source devices) simultaneously send data to the same NT endpoint device (target device), congestion may occur at the target device's ingress point due to insufficient target receiving bandwidth. Related technologies typically employ backpressure mechanisms at the target device's ingress point to prevent data loss by blocking upstream links and source devices, thus balancing data traffic. However, this approach not only blocks the communication path that causes congestion but also affects communication between other NT endpoint devices on the same bus, resulting in wasted system bandwidth and reduced overall communication efficiency. Summary of the Invention

[0003] This application provides a data packet sending method, apparatus, electronic device, and storage medium to at least solve the problem of wasted system bandwidth and reduced overall communication efficiency caused by using a backpressure mechanism to solve congestion at the target device's entry point in related technologies.

[0004] This application provides a data packet sending method applied to a source cross-domain communication device, including: Determine the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices, wherein the source cross-domain communication device has access to the first cross-domain communication devices, and the sum of the bandwidth quotas of the data streams sent by the multiple cross-domain communication devices with access to the first cross-domain communication devices to the first cross-domain communication devices is not greater than the maximum data bandwidth of the first cross-domain communication device; A token table is generated based on the bandwidth quota of the data stream sent from the source cross-domain communication device to each of the multiple first cross-domain communication devices. Based on the data packets to be sent, identify the target cross-domain communication device; Based on the target cross-domain communication device and the token table, determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device; If the number of tokens required to send the data packet is no greater than the total number of tokens in the first batch, the data packet to be sent will be sent to the target cross-domain communication device.

[0005] This application also provides a data packet sending apparatus, including: The first determining module is used to determine the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices, wherein the source cross-domain communication device has access rights to the first cross-domain communication devices, and the sum of the bandwidth quotas of the data streams sent by the multiple cross-domain communication devices with access rights to the first cross-domain communication devices to the first cross-domain communication devices is not greater than the maximum data bandwidth of the first cross-domain communication device. The generation module is used to generate a token table based on the bandwidth quota of the data stream sent from the source cross-domain communication device to each of the multiple first cross-domain communication devices. The second determining module is used to determine the target cross-domain communication device based on the data packet to be sent; The third determining module is used to determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target cross-domain communication device and the token table; The sending module is used to send the data packet to the target cross-domain communication device when the number of tokens required for the data packet to be sent is not greater than the total number of first tokens.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described data packet transmission methods.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described data packet sending methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described data packet sending methods.

[0009] This application determines the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices, wherein the source cross-domain communication device has access permissions to the first cross-domain communication devices, and the sum of the bandwidth quotas of the data streams sent by the multiple cross-domain communication devices with access permissions to the first cross-domain communication devices to the first cross-domain communication devices is not greater than the maximum data bandwidth of the first cross-domain communication device; a token table is generated based on the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices; a target cross-domain communication device is determined based on the data packet to be sent; the total number of first tokens possessed by the data stream sent by the source cross-domain communication device to the target cross-domain communication device is determined based on the target cross-domain communication device and the token table; and the data packet to be sent is sent to the target cross-domain communication device when the number of tokens required for the data packet to be sent is not greater than the total number of first tokens. By setting the total bandwidth quota of data streams sent to the first cross-domain communication device by multiple cross-domain communication devices with access rights to the first cross-domain communication device to not exceed the maximum data bandwidth of the first cross-domain communication device, system congestion caused by the sum of the sending bandwidth of multiple cross-domain communication devices with access rights to the first cross-domain communication device exceeding the receiving bandwidth of the first cross-domain communication device is avoided. Moreover, when system congestion occurs, it can ensure that the first cross-domain communication device reaches its maximum data bandwidth without affecting the data path between other cross-domain communication devices. Therefore, it can solve the technical problem of wasted system bandwidth and decreased overall communication efficiency caused by the use of backpressure mechanisms to solve congestion at the target device entry point in related technologies, and achieve the technical effect of avoiding system congestion, reducing system bandwidth waste, and improving overall communication efficiency. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of cross-domain communication based on non-transparent bridge technology in related technologies; Figure 2 A flowchart illustrating a data packet sending method provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the bandwidth quota for the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices, as provided in an embodiment of this application. Figure 4 A schematic diagram of a token table provided in an embodiment of this application; Figure 5A schematic diagram illustrating the use of a token table provided in an embodiment of this application; Figure 6 A flowchart illustrating yet another data packet sending method provided in an embodiment of this application; Figure 7 A schematic diagram illustrating the organization of a token table into a target queue, provided for an embodiment of this application; Figure 8 A schematic diagram illustrating target queue updates provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a data packet sending device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] Non-transparent bridging technology is a common PCIe cross-domain communication technology. It implements a special endpoint device, or NT endpoint device, under two host domains. These two NT endpoint devices form a non-transparent bridge to implement address translation and ID translation functions required for cross-host domain communication. These NT endpoint devices are generally physically connected through an internal interconnect bus and can achieve cross-domain communication by logically pairing them. Figure 1 This is a schematic diagram illustrating cross-domain communication based on non-transparent bridge technology in related technologies, such as... Figure 1As shown, hosts 0, 1, and 2 each have one NT endpoint device. The NT endpoint device on host 0 can form a pair with an NT endpoint device on host 1 to implement NTB functionality, and simultaneously, the NT endpoint device on host 0 can also form another pair with an NT endpoint device on host 2 to implement NTB functionality. Similarly, the NT endpoint device on host 1 can form a pair with an NT endpoint device on host 2 to implement NTB functionality. Therefore, each host's NT endpoint device may receive data from NT endpoint devices on other hosts. This can lead to a potential problem: if multiple NT endpoint devices (source devices) simultaneously send data to the same NT endpoint device (target device), congestion may occur at the target device's ingress point because the data source bandwidth is much higher than the target device's receiving bandwidth. Figure 1 As shown, when host 1 and host 2 simultaneously send data to the NT endpoint device under host 0 through their respective NT endpoint devices, congestion occurs at the entry point of the NT endpoint device under host 0.

[0016] In related technologies, to address the congestion issue at the target device's input, backpressure processing is typically implemented at the target device's input. This means that when there is insufficient output bandwidth, the input port is blocked to prevent data loss. This backpressure is propagated cascaded to the source device. For example, when backpressure is generated at the target device's input port, it causes the NT interconnect bus's internal buffer to exceed a certain threshold, triggering backpressure from the NT interconnect bus onto the source device.

[0017] This backpressure mechanism can control the output flow of the source device, achieving a balanced final data flow. However, once backpressure occurs, congestion will inevitably occur within the NT interconnect bus and the entire system, affecting communication between other NT endpoint devices. For example, when the NT endpoint device of host 0 generates backpressure, the path between the NT endpoint device of host 1 and the NT interconnect bus will be blocked. In this case, the path between the NT endpoint devices of host 1 and host 2 will also be unable to transmit data normally, resulting in a waste of system bandwidth and a reduction in overall communication efficiency.

[0018] To address the aforementioned issues, this application provides a data packet sending method, apparatus, electronic device, and storage medium. The method is applied to a source cross-domain communication device and includes: determining the bandwidth quota of a data stream sent from the source cross-domain communication device to each of a plurality of first cross-domain communication devices, wherein the source cross-domain communication device has access permissions to the first cross-domain communication devices, and the sum of the bandwidth quotas of the data streams sent from the plurality of cross-domain communication devices with access permissions to the first cross-domain communication devices to the first cross-domain communication devices is not greater than the maximum data bandwidth of the first cross-domain communication device; generating a token table based on the bandwidth quota of the data streams sent from the source cross-domain communication device to each of the plurality of first cross-domain communication devices; determining a target cross-domain communication device based on the data packet to be sent; determining the total number of first tokens possessed by the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target cross-domain communication device and the token table; and sending the data packet to be sent to the target cross-domain communication device when the number of tokens required for the data packet to be sent is not greater than the total number of first tokens. The method provided by the above solution avoids system congestion caused by the sum of the sending bandwidth of multiple cross-domain communication devices with access rights to the first cross-domain communication device exceeding the receiving bandwidth of the first cross-domain communication device by setting the total bandwidth quota of the data stream sent to the first cross-domain communication device to be no greater than the maximum data bandwidth of the first cross-domain communication device. Moreover, when system congestion occurs, it can ensure that the first cross-domain communication device reaches its maximum data bandwidth without affecting the data path between other cross-domain communication devices. Therefore, it can solve the technical problem of wasted system bandwidth and decreased overall communication efficiency caused by the use of backpressure mechanisms to solve congestion at the target device entry point in related technologies, and achieve the technical effect of avoiding system congestion, reducing system bandwidth waste, and improving overall communication efficiency.

[0019] The embodiments of this application provide a data packet sending method applied to a source cross-domain communication device, which can be an NT endpoint device under any host in a PCIe multi-host system based on non-transparent bridge technology. Figure 2 This is a flowchart illustrating the data packet sending method provided in an embodiment of this application, as shown below. Figure 2 As shown, the data packet sending method includes the following steps: Step S201: Determine the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices, wherein the source cross-domain communication device has access rights to the first cross-domain communication devices, and the sum of the bandwidth quotas of the data streams sent by the multiple cross-domain communication devices with access rights to the first cross-domain communication devices to the first cross-domain communication devices is not greater than the maximum data bandwidth of the first cross-domain communication device.

[0020] Specifically, (N-1) token buckets are prepared for each source cross-domain communication device to control bandwidth. N equals the number of all NT endpoint devices in the PCIe multi-host system based on non-transparent bridge technology. It should be noted that this description assumes that each NT endpoint device can access all other NT endpoint devices. If some NT endpoint devices can only access some other NT endpoint devices, then the number of token buckets prepared for that NT endpoint device only needs to be greater than or equal to the total number of NT endpoint devices that the NT endpoint device can access.

[0021] Each token bucket represents the bandwidth of the data stream sent from the source cross-domain communication device (i.e., the source NT endpoint device) to a first cross-domain communication device. Each token bucket corresponds one-to-one with a first cross-domain communication device. When the number of tokens required for a data packet exceeds the number of tokens in the corresponding token bucket, the source cross-domain communication device is not allowed to send that data packet, but it can send data packets corresponding to other NT endpoint devices to other NT endpoint devices (provided that tokens for sending to other NT endpoint devices can be obtained). In this embodiment, the initial number of tokens in the token bucket is 0, and the token increment of the token bucket is determined based on the bandwidth quota of the data stream sent from the source cross-domain communication device to its corresponding first cross-domain communication device.

[0022] Figure 3 This is a schematic diagram illustrating the bandwidth quota for determining the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices provided in this application embodiment, as shown below. Figure 3 As shown, taking the example where each NT endpoint device can access other NT endpoint devices, the bandwidth quota for data streams sent to NT1, NT2, NT3, ..., NTx is determined when the source cross-domain communication device is NT0. When the source cross-domain communication device is NT1, the bandwidth quota for data streams sent to NT0, NT2, NT3, ..., NTx is determined. When the source cross-domain communication device is NT2, the bandwidth quota for data streams sent to NT0, NT1, NT3, ..., NTx is determined. And so on, determining the bandwidth quota for data streams sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices. It can be understood that... Figure 3 The matrix-style bandwidth quota allocation method shown includes multiple bandwidth quota parameters for each source cross-domain communication device, each corresponding one-to-one with the first cross-domain communication device. The first cross-domain communication device needs to allocate bandwidth quotas to each possible source cross-domain communication device, ensuring that the sum of the allocated bandwidth quotas does not exceed its corresponding maximum data bandwidth.

[0023] The allocation of bandwidth quotas must meet the following principles: 1. For any source NT endpoint device, the total bandwidth quota is determined based on the bandwidth quota of the data stream sent from the source NT endpoint device to each of the multiple first cross-domain communication devices. This total bandwidth quota must be equal to the maximum data bandwidth of the source NT endpoint device. It should be noted that if the total bandwidth quota is not equal to the maximum data bandwidth, it will not cause functional problems, but it will reduce the bandwidth utilization of the source NT endpoint device or the first cross-domain communication device. 2. For any first cross-domain communication device, the total bandwidth quota of the data stream sent from multiple cross-domain communication devices with access rights to the first cross-domain communication device to the first cross-domain communication device must be equal to the maximum data bandwidth of the first cross-domain communication device. It should be noted that it is not allowed for the total bandwidth quota of the data stream sent from multiple cross-domain communication devices with access rights to the first cross-domain communication device to be greater than the maximum data bandwidth of the first cross-domain communication device, as this will cause system congestion; while it is allowed for it to be less, but it will reduce the bandwidth utilization of the first cross-domain communication device.

[0024] It is understandable that when determining the bandwidth quota for the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices, the condition that must be met is that the sum of the bandwidth quotas for the data streams sent by the multiple cross-domain communication devices that have access to the first cross-domain communication device to the first cross-domain communication device does not exceed the maximum data bandwidth of the first cross-domain communication device. The specific method for determining the bandwidth quota for the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices is not specifically restricted here.

[0025] Bandwidth quota allocation should be completed during the address mapping establishment phase. This phase is a crucial process for NTB (Network Transaction Builder). Because cross-domain data transmission is required, address translation between the two domains is necessary (since each host domain's address is independently encoded, an address from one host domain cannot be directly used in another). Generally, before using NTB, a mapping relationship needs to be established to describe how to translate an address from one host domain to another; this process is called address mapping establishment. The specific implementation of this process is not limited here. In this embodiment, the bandwidth quota allocation process can be performed during address mapping establishment. This is because there is no data communication before address mapping is established; and the address mapping establishment process requires information exchange between the two domains, which is the same as the subsequent bandwidth quota allocation step.

[0026] For example, the bandwidth quota allocation can be implemented as follows: First, the source NT endpoint device should calculate the bandwidth quota request to be sent to each of the first cross-domain communication devices based on its maximum data bandwidth and information such as the number of first cross-domain communication devices it can access. Then, the source NT endpoint device sends the aforementioned bandwidth quota request to the first cross-domain communication devices. Next, the first cross-domain communication device determines the total bandwidth quota based on the bandwidth quota requests sent by the multiple cross-domain communication devices with which it has access, and checks whether the total bandwidth quota meets the requirements. If it does, it sends an authorization response to the multiple cross-domain communication devices with which it has access. If it does not, it calculates the bandwidth that can be authorized to the multiple cross-domain communication devices with access according to a certain algorithm and returns it to the multiple cross-domain communication devices with access. After receiving the authorized bandwidth quotas from all the first cross-domain communication devices, the source NT endpoint device can end the bandwidth quota negotiation process, or it can further calculate to obtain a better bandwidth quota allocation and repeat the above steps to initiate negotiation with the first cross-domain communication devices again.

[0027] Bandwidth quotas are typically implemented using the token bucket mechanism described above. This token bucket replenishes itself with tokens periodically. When a data packet needs to be sent, it must first retrieve the corresponding number of tokens from the token bucket. If there are insufficient tokens, the user must wait. The number of tokens replenished periodically is determined by the bandwidth quota. Each period can be a specific time interval, which is configured by technical personnel and is not specifically limited here. The depth of the token bucket is greater than the number of tokens corresponding to the bandwidth quota; this is also configured by technical personnel.

[0028] Step S202: Generate a token table based on the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices.

[0029] The method of preparing multiple token buckets for bandwidth control for each source cross-domain communication device requires a functional logic circuit and a storage circuit for each token bucket. Therefore, when the number of token buckets is large, this method becomes very costly. Therefore, in this embodiment, the core logic of the token bucket is implemented based on a token table. Only one table and one set of logic circuits are needed to implement multiple token buckets. Moreover, the table can usually be implemented using Static Random Access Memory (SRAM), which is low-cost.

[0030] Figure 4 A schematic diagram of the token table provided in the embodiments of this application, as shown below. Figure 4As shown, the token table has several rows. Each row functions as a token bucket for the data stream sent from the source cross-domain communication device to a first cross-domain communication device. Specifically, each row represents the token information corresponding to the data stream sent from the source cross-domain communication device to a first cross-domain communication device. Each row includes three fields: update time, remaining tokens, and token increment. The update time indicates the time when the remaining token field was last updated. The remaining tokens describe the maximum length of the allowed data packet, serving the same purpose as the token quantity in a traditional token bucket. The token increment describes the number of tokens needed to be replenished per unit of time, and is determined based on the bandwidth quota of the data stream sent from the source cross-domain communication device to each of the multiple first cross-domain communication devices.

[0031] Step S203: Based on the data packet to be sent, determine the target cross-domain communication device.

[0032] Step S204: Based on the target cross-domain communication device and the token table, determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device.

[0033] Step S205: If the number of tokens required for the data packet to be sent is not greater than the total number of first tokens, the data packet to be sent is sent to the target cross-domain communication device.

[0034] The token table requires a configuration control / update logic for maintenance. Figure 5 This is a schematic diagram illustrating the use of a token table provided in an embodiment of this application, as shown below. Figure 5 As shown, when the data processing module in the source cross-domain communication device receives the data packet to be sent, it sends a command to the quota control / update module requesting a quota. The quota control / update module extracts three fields from the token table corresponding to the target cross-domain communication device: update time, remaining tokens, and token increment. Then, it calculates the total number of tokens required for the data stream from the source cross-domain communication device to the target cross-domain communication device. After obtaining the total number of tokens, it needs to determine the relationship between the total number of tokens and the number of tokens required for the data packet to be sent. If the number of tokens required for the data packet to be sent is not greater than the total number of tokens, the quota control / update module performs the following operations: it writes the current time into the update time field corresponding to the target cross-domain communication device; it writes the value obtained by subtracting the number of tokens required for the data packet from the total number of tokens into the remaining token field corresponding to the target cross-domain communication device. Then, the quota control / update module grants the data processing module a number of tokens equal to the number of tokens required for the data packet to be sent. The data processing module then sends the data packet to the target cross-domain communication device based on the granted number of tokens.

[0035] It is understandable that while sending the data packet to be sent to the target cross-domain communication device, the token table is updated, that is, the current time is written into the update time field corresponding to the target cross-domain communication device; and the value obtained by subtracting the number of tokens required for the data packet to be sent from the total number of first tokens is written into the remaining token field corresponding to the target cross-domain communication device.

[0036] The data packet sending method provided in this application avoids system congestion caused by the sum of the bandwidth quotas of data streams sent to the first cross-domain communication device by multiple cross-domain communication devices with access permissions to the first cross-domain communication device not exceeding the maximum data bandwidth of the first cross-domain communication device. Furthermore, when system congestion occurs, it ensures that the first cross-domain communication device reaches its maximum data bandwidth without affecting the data paths between other cross-domain communication devices. Therefore, it solves the technical problem of wasted system bandwidth and decreased overall communication efficiency caused by using a backpressure mechanism to resolve congestion at the target device's entry point in related technologies. This achieves the technical effect of avoiding system congestion, reducing system bandwidth waste, and improving overall communication efficiency.

[0037] Embodiments of this application provide a data packet sending method applied to a source cross-domain communication device. Figure 6 This is a flowchart illustrating the data packet sending method provided in an embodiment of this application, as shown below. Figure 6 As shown, the data packet sending method includes the following steps: Step S601: Determine the bandwidth quota for the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices. The source cross-domain communication device has access permissions to the first cross-domain communication devices, and the sum of the bandwidth quotas for the data streams sent by the multiple cross-domain communication devices with access permissions to the first cross-domain communication devices to the first cross-domain communication devices does not exceed the maximum data bandwidth of the first cross-domain communication device. For details, please refer to [link to details]. Figure 2 Step S201 of the illustrated embodiment will not be described again here.

[0038] Step S602: Generate a token table based on the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices. See details below. Figure 2 Step S202 of the illustrated embodiment will not be described again here.

[0039] Step S603: Based on the data packet to be sent, determine the target cross-domain communication device. For details, please refer to [link to relevant documentation]. Figure 2 Step S203 of the illustrated embodiment will not be described again here.

[0040] Step S604: Based on the target cross-domain communication device and the token table, determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device.

[0041] Specifically, step S604 includes: Step S6041: Based on the target cross-domain communication device and the token table, determine the target token information corresponding to the data stream sent from the source cross-domain communication device to the target cross-domain communication device.

[0042] Step S6042: Based on the target token information, determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device.

[0043] Step S605: If the number of tokens required for the data packet to be sent is not greater than the total number of the first set of tokens, the data packet to be sent is sent to the target cross-domain communication device. For details, please refer to [link to relevant documentation]. Figure 2 Step S205 of the illustrated embodiment will not be described again here.

[0044] The data packet sending method provided in this application embodiment realizes accurate real-time bandwidth checking for specific communication targets, thereby proactively and independently preventing systemic congestion that may be caused by overloading data transmission to a single target at the data transmission source.

[0045] In some optional implementations, the target token information includes the target update time, the target remaining tokens, and the target token increment. Step S6042 above includes: Step a1: Determine the current time based on the counter.

[0046] Step a2: Based on the first formula, determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device. The first formula is:

[0047] in, For the current time, Update time for target Increment the target token. Remaining tokens for the target.

[0048] In some optional implementations, the token information also includes a next field, which indicates the number of the next row in ascending order of update time. The above data packet sending method also includes: Step b1: Based on the next field in the token information represented by each row of the token table, the data in the head pointer register, and the data in the tail pointer register, organize the token table into a target queue arranged in order of update time from earliest to latest. The head pointer register records the number of the row with the earliest update time, and the tail pointer register records the number of the row with the latest update time.

[0049] If the source NT endpoint device does not send data packets to a certain first cross-domain communication device for an extended period, the corresponding entry in the token table will not be updated for a long time. If, during this period, the counter used to record the current time (the current moment) has already toggled and wrapped around, an error will occur when accessing that entry again, resulting in an incorrect calculation of the total number of tokens. To solve this problem, the traditional method is to periodically read and refresh the token table, but this takes a long time, affects data bandwidth, and most entries should not need to be refreshed. Therefore, this embodiment adds a next field to the token table, which represents the number of the next entry in the order of update time, i.e., the number of the next row after each row. It should be noted that the number of each row is the identifier of the corresponding first cross-domain communication device. A head pointer register and a tail pointer register are also added to record the numbers of the earliest and latest updated entries, respectively.

[0050] The purpose of the next field, head pointer register, and tail pointer register is to organize the token table into a queue that sorts each row in the table in chronological order of its update time. That is, the first element in the queue is the row with the earliest update time, the second element is the row with the second earliest update time, and so on.

[0051] Figure 7 This is a schematic diagram illustrating the organization of a token table into a target queue, as provided in an embodiment of this application. Figure 7 As shown, assuming the order arranged by update time is NT5, NT2, NT10, NT0, NT1, ..., then the head pointer register is set to 5 (pointing to NT5), then the next field of NT5 is set to 2 (pointing to NT2), then the next field of NT2 is set to 10 (pointing to NT10), and so on. The token table is organized into the target queue based on the data in the head pointer register, the data in the tail pointer register, and each next field.

[0052] Step b2: Calculate the absolute value of the difference between the update time of the first element of the target queue and the current time.

[0053] Step b3: If the absolute value is greater than the preset timeout duration, update the update time in the first element of the queue to the current time, then move the first element to the tail of the target queue, and modify the data in the head pointer register and the tail pointer register accordingly. Then return to the step of calculating the absolute value of the difference between the update time in the first element of the target queue and the current time; the preset timeout duration is less than the counter's counting period.

[0054] If the absolute value is not greater than the preset timeout duration, the target queue will not be updated. This can be understood as updating an element in the target queue, which means updating the corresponding row in the token table.

[0055] It should be noted that steps b2 and b3 are executed periodically.

[0056] To prevent incorrect calculations caused by the counter's flip-around, a preset timeout period is set. This preset timeout period must be less than the counter's counting cycle, i.e., less than the time it takes for the counter to flip back from 0. The specific timeout period is set by technical personnel and is not limited here. When the update time exceeds the preset timeout period, a forced refresh of the update time is required.

[0057] Since the target queue is sorted by update time, it is only necessary to check if the head element has timed out. For a forced refresh, after updating the update time of the head element to the current time, the corresponding element needs to be moved from the head to the tail. Assuming the head element is NT5, the second element is NT2, and the tail element is NT29, if the head element triggers a forced refresh, the following operations are performed: 1. Change the data in the head pointer register to the value of the next field after NT5, i.e., 2; 2. Change the value of the next field of the element pointed to by the tail pointer register (i.e., NT29) to 5; 3. Change the data in the tail pointer register to 5.

[0058] It is understandable that while sending the data packet to be sent to the target cross-domain communication device, it is necessary to update the data of the target element in the target queue, move the target element to the tail of the target queue, and modify the data in the tail pointer register.

[0059] For example, Figure 8 This is a schematic diagram of target queue updates provided in an embodiment of this application, as shown below. Figure 8As shown, when the target cross-domain communication device is NT10, while sending the data packet to be sent to NT10, the update time field and remaining token field of the row corresponding to the target element (NT10) in the target queue are updated. Then, the target element is moved to the tail of the target queue, the data in the tail pointer register is updated to 10, pointing to NT10, and then the value of the next field of the row corresponding to NT2 is updated from 10 to 0 (i.e., the value of the next field of NT10). After the above operations are completed, it is equivalent to placing the latest updated NT10 at the very end of the queue.

[0060] Performing the above operations ensures that the target queue is always sorted by update time. Therefore, by only checking the update time of the first element, it can be guaranteed that no element in the target queue will have an incorrect value calculated due to timestamp wrap-around.

[0061] The data packet sending method provided in this application organizes all entries in the token table into a logical queue according to their update time order, and continuously monitors only the element at the head of the queue. Once an update time exceeding a preset timeout threshold is detected, its timestamp is immediately forcibly refreshed and it is moved to the tail of the queue, and then the new head of the queue is checked cyclically. By ensuring that the update time field of no token bucket expires due to counter wraparound, errors in token count calculation caused by update time errors are fundamentally eliminated, thereby guaranteeing the correctness and reliability of data packet sending.

[0062] In some optional implementations, the above data packet sending method further includes: Step c1: If the number of tokens required to send the data packet is greater than the total number of first tokens, the data packet to be sent is truncated into a first data packet and a second data packet to be sent, based on the total number of first tokens.

[0063] Step c2: Send the first data packet to the target cross-domain communication device.

[0064] Step c3: Determine the first waiting time for sending the second data packet to be sent.

[0065] Step c4: After the first waiting time is reached, based on the target cross-domain communication device and the token table, determine the total number of second tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device; if the number of tokens required to send the second data packet is not greater than the total number of second tokens, send the second data packet to be sent to the target cross-domain communication device.

[0066] When the number of tokens required for the data packet to be sent exceeds the total number of tokens in the first batch, the quota control / update module grants the data processing module an amount of tokens equal to the total number of tokens in the first batch. It then updates the update time field (target update time) of the target cross-domain communication device to the current time and updates the remaining token field (target remaining tokens) of the target cross-domain communication device to 0. Based on the granted number of tokens, the data processing module determines the maximum data packet length that can be sent and truncates the data packet to be sent into a first data packet that can be sent directly and a second data packet to be sent. Based on the granted number of tokens, the first data packet is sent to the target cross-domain communication device. The number of tokens required for the data packet to be sent is determined according to the length of the data packet to be sent.

[0067] The method for determining the first waiting time for sending the second data packet is similar to the method for determining the second waiting time described below, and will not be repeated here. It is understood that the token table is updated once each time the source cross-domain communication device successfully completes communication. Therefore, after the first waiting time has elapsed, it is necessary to re-determine the total number of second tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target cross-domain communication device and the token table, and then re-determine whether the number of tokens required to send the second data packet is not greater than the total number of second tokens.

[0068] It should be noted that if the number of tokens required to send the second data packet is greater than the total number of second tokens, the process returns to the step of determining the first waiting time for sending the second data packet.

[0069] The data packet sending method provided in this application embodiment can achieve partial real-time data transmission when the token (i.e., bandwidth quota) is insufficient, thereby maximizing the use of the currently available bandwidth, reducing overall communication latency, and avoiding long-term idle communication connections due to waiting.

[0070] In some optional implementations, the above data packet sending method further includes: Step d1: If the number of tokens required for the data packet to be sent is greater than the total number of tokens in the first step, determine the second waiting time for sending the data packet based on the number of tokens required for the data packet to be sent.

[0071] If the number of tokens required for the data packet to be sent is greater than the total number of tokens in the first round, the quota control / update module may also choose not to grant tokens to the data processing module. If the data processing module does not receive the granted number of tokens, it will determine the second waiting time for sending the data packet based on the number of tokens required for the data packet to be sent.

[0072] Step d2: After the second waiting time is reached, based on the target cross-domain communication device and the token table, determine the total number of third tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device; if the number of tokens required for the data packet to be sent is not greater than the total number of third tokens, send the data packet to be sent to the target cross-domain communication device.

[0073] After the second waiting time for transmission is reached, the data processing module attempts to send the data packet again, that is, the data processing module sends a command to the quota control / update module to request quota again.

[0074] The data packet sending method provided in this application ensures that data packets can be sent in a complete and unfragmented form at once when the bandwidth is momentarily insufficient. This avoids the additional overhead and processing complexity at the receiving end that may be caused by data packet fragmentation, and guarantees the atomicity and efficiency of data transmission.

[0075] In some optional implementations, step d1 above includes: Step d11: Based on the target cross-domain communication device and the token table, determine the target token information corresponding to the data stream sent from the source cross-domain communication device to the target cross-domain communication device; the target token information includes the target remaining token and the target token increment.

[0076] Step d12: Based on the second formula, determine the second waiting time for sending the data packet to be sent. The second formula is:

[0077] in, This is the second waiting time for the data packet to be sent. Remaining tokens for the target The number of tokens required to send the data packet. Increment the target token.

[0078] In some optional implementations, the above data packet sending method further includes: Step e1: If the number of tokens required for the data packet to be sent is not greater than the total number of first tokens, and the data packet to be sent to the target cross-domain communication device is not successfully sent, then the step of sending the data packet to the target cross-domain communication device is re-executed.

[0079] Step e2: If the number of times the step of re-executing the step of sending the data packet to be sent to the target cross-domain communication device reaches a preset threshold, and the data packet to be sent to the target cross-domain communication device is still not successfully sent, an alarm is issued.

[0080] The data packet sending method provided in this application improves the final success rate of single data transmission by using a limited number of automatic retry mechanisms when transmission fails due to momentary abnormalities, and triggers an alarm after a retry failure, thereby enhancing the system's fault tolerance and maintainability.

[0081] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0082] Embodiments of this application also provide a data packet sending device, such as... Figure 9 As shown, the data packet sending device includes: The first determining module 901 is used to determine the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices, wherein the source cross-domain communication device has access rights to the first cross-domain communication devices, and the sum of the bandwidth quotas of the data streams sent by the multiple cross-domain communication devices with access rights to the first cross-domain communication devices to the first cross-domain communication devices is not greater than the maximum data bandwidth of the first cross-domain communication device.

[0083] The generation module 902 is used to generate a token table based on the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices.

[0084] The second determining module 903 is used to determine the target cross-domain communication device based on the data packet to be sent.

[0085] The third determining module 904 is used to determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target cross-domain communication device and the token table.

[0086] The sending module 905 is used to send the data packet to the target cross-domain communication device when the number of tokens required for the data packet to be sent is not greater than the total number of first tokens.

[0087] In some alternative implementations, the third determining module 904 includes: The first determining unit is used to determine the target token information corresponding to the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target cross-domain communication device and the token table.

[0088] The second determining unit is used to determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target token information.

[0089] In some optional implementations, the second determining unit includes: The third determining unit is used to determine the current time based on the counter.

[0090] The fourth determining unit is used to determine, based on the first formula, the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device, wherein the first formula is:

[0091] in, For the current time, Update time for target Increment the target token. Remaining tokens for the target.

[0092] In some optional embodiments, the above-described data packet sending device further includes: The organization unit is used to organize the token table into a target queue arranged in order of update time from earliest to latest, based on the next field in the token information represented by each row of the token table, the data in the head pointer register, and the data in the tail pointer register. The head pointer register records the number of the row with the earliest update time, and the tail pointer register records the number of the row with the latest update time.

[0093] The calculation unit is used to calculate the absolute value of the difference between the update time of the first element of the target queue and the current time.

[0094] The movement unit is used to update the update time in the head element of the queue to the current time when the absolute value is greater than the preset timeout duration, then move the head element to the tail of the target queue, modify the data in the head pointer register and the tail pointer register accordingly, and return to the step of calculating the absolute value of the difference between the update time in the head element of the target queue and the current time; the preset timeout duration is less than the counter's counting period.

[0095] In some optional embodiments, the above-described data packet sending device further includes: The interception unit is used to intercept the data packet to be sent into a first data packet and a second data packet to be sent, based on the first total number of tokens, when the number of tokens required for the data packet to be sent is greater than the first total number of tokens.

[0096] The sending unit is used to send the first data packet to the target cross-domain communication device.

[0097] The fifth determining unit is used to determine the first waiting time for sending the second data packet to be sent.

[0098] The sixth determining unit is used to determine the total number of second tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target cross-domain communication device and the token table after the first waiting time for transmission is reached; and to send the second data packet to be sent to the target cross-domain communication device if the number of tokens required to send the second data packet is not greater than the total number of second tokens.

[0099] In some optional embodiments, the above-described data packet sending device further includes: The seventh determining unit is used to determine the second waiting time for sending the data packet based on the number of tokens required for sending the data packet when the number of tokens required for sending the data packet is greater than the total number of first tokens.

[0100] The eighth determining unit is used to determine, after the second waiting time has elapsed, the total number of third tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target cross-domain communication device and the token table; and to send the data packet to be sent to the target cross-domain communication device if the number of tokens required for the data packet to be sent is not greater than the total number of third tokens.

[0101] In some optional implementations, the seventh determining unit includes: The ninth determining unit is used to determine the target token information corresponding to the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target cross-domain communication device and the token table; the target token information includes the target remaining token and the target token increment.

[0102] The tenth determining unit is used to determine the second waiting time for sending the data packet based on the second formula, which is:

[0103] in, This is the second waiting time for the data packet to be sent. Remaining tokens for the target The number of tokens required to send the data packet. Increment the target token.

[0104] For a description of the features in the embodiment corresponding to the data packet sending device, please refer to the relevant description in the embodiment corresponding to the data packet sending method, which will not be repeated here.

[0105] Embodiments of this application also provide an electronic device, such as... Figure 10 As shown, it includes a processor 1001 and a memory 1002, in which a computer program is stored. The processor 1001 is configured to run the computer program to perform the steps in any of the above-described data packet transmission method embodiments.

[0106] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described data packet transmission method embodiments when it is run.

[0107] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0108] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described data packet transmission method embodiments.

[0109] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described data packet transmission method embodiments.

[0110] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0111] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0112] The data packet transmission method, apparatus, electronic device, and storage medium provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A data packet sending method, characterized in that, Applied to source cross-domain communication devices, including: Determine the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices, wherein the source cross-domain communication device has access rights to the first cross-domain communication device, and the sum of the bandwidth quotas of the data streams sent by the multiple cross-domain communication devices with access rights to the first cross-domain communication device to the first cross-domain communication device is not greater than the maximum data bandwidth of the first cross-domain communication device; A token table is generated based on the bandwidth quota of the data stream sent from the source cross-domain communication device to each of the multiple first cross-domain communication devices. Based on the data packets to be sent, identify the target cross-domain communication device; Based on the target cross-domain communication device and the token table, determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device; If the number of tokens required for the data packet to be sent is not greater than the total number of the first tokens, the data packet to be sent is sent to the target cross-domain communication device.

2. The method according to claim 1, characterized in that, Each row of the token table represents the token information corresponding to the data stream sent by the source cross-domain communication device to a first cross-domain communication device; the token information includes update time, remaining tokens, and token increment; the token increment is determined based on the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices; determining the total number of first tokens possessed by the data stream sent by the source cross-domain communication device to the target cross-domain communication device based on the target cross-domain communication device and the token table includes: Based on the target cross-domain communication device and the token table, determine the target token information corresponding to the data stream sent from the source cross-domain communication device to the target cross-domain communication device; Based on the target token information, determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device.

3. The method according to claim 2, characterized in that, The target token information includes the target update time, the target remaining tokens, and the target token increment. Determining the total number of first tokens possessed by the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target token information includes: Determine the current time based on the counter; Based on the first formula, the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device is determined. The first formula is: in, For the current time, Update time for target Increment the target token. Remaining tokens for the target.

4. The method according to claim 2, characterized in that, The token information also includes a next field, which represents the number of the next row in ascending order of update time; the method further includes: Based on the next field in the token information represented by each row of the token table, the data in the head pointer register, and the data in the tail pointer register, the token table is organized into a target queue arranged in order of update time from earliest to latest. The head pointer register records the number of the row with the earliest update time, and the tail pointer register records the number of the row with the latest update time. Calculate the absolute value of the difference between the update time of the first element of the target queue and the current time; If the absolute value is greater than the preset timeout duration, the update time in the head element of the queue is updated to the current time, then the head element is moved to the tail of the target queue, and the data in the head pointer register and the tail pointer register are modified accordingly. Then, the process returns to the step of calculating the absolute value of the difference between the update time in the head element of the target queue and the current time; the preset timeout duration is less than the counter's counting period.

5. The method according to claim 1, characterized in that, The method further includes: If the number of tokens required for the data packet to be sent is greater than the total number of the first tokens, the data packet to be sent is truncated into a first data packet and a second data packet to be sent, based on the total number of the first tokens. Send the first data packet to the target cross-domain communication device; Determine the first waiting time for the second data packet to be sent; After the first waiting time is reached, based on the target cross-domain communication device and the token table, the total number of second tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device is determined; if the number of tokens required to send the second data packet is not greater than the total number of second tokens, the second data packet to be sent is sent to the target cross-domain communication device.

6. The method according to claim 1, characterized in that, The method further includes: If the number of tokens required for the data packet to be sent is greater than the total number of the first tokens, a second waiting time for sending the data packet to be sent is determined based on the number of tokens required for the data packet to be sent. After the second waiting time is reached, based on the target cross-domain communication device and the token table, the total number of third tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device is determined; if the number of tokens required for the data packet to be sent is not greater than the total number of third tokens, the data packet to be sent is sent to the target cross-domain communication device.

7. The method according to claim 6, characterized in that, Determining the second waiting time for sending the data packet based on the number of tokens required for the data packet to be sent includes: Based on the target cross-domain communication device and the token table, the target token information corresponding to the data stream sent from the source cross-domain communication device to the target cross-domain communication device is determined; the target token information includes the target remaining token and the target token increment; Based on the second formula, the second waiting time for sending the data packet to be sent is determined. The second formula is: in, The second waiting time for sending the data packet to be sent. Remaining tokens for the target The number of tokens required for the data packet to be sent. Increment the target token.

8. A data packet sending device, characterized in that, include: The first determining module is used to determine the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices, wherein the source cross-domain communication device has access rights to the first cross-domain communication device, and the sum of the bandwidth quotas of the data streams sent by the multiple cross-domain communication devices with access rights to the first cross-domain communication device to the first cross-domain communication device is not greater than the maximum data bandwidth of the first cross-domain communication device. The generation module is used to generate a token table based on the bandwidth quota of the data stream sent by the source cross-domain communication device to each of the multiple first cross-domain communication devices; The second determining module is used to determine the target cross-domain communication device based on the data packet to be sent; The third determining module is used to determine the total number of first tokens in the data stream sent from the source cross-domain communication device to the target cross-domain communication device based on the target cross-domain communication device and the token table; The sending module is configured to send the data packet to be sent to the target cross-domain communication device when the number of tokens required for the data packet to be sent is not greater than the total number of the first tokens.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the data packet transmission method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the data packet transmission method as described in any one of claims 1 to 7.

Images