CN114448970A

CN114448970A - Data transmission method, device and equipment

Info

Publication number: CN114448970A
Application number: CN202111617248.9A
Authority: CN
Inventors: 陈美琦; 李�杰; 林建波
Original assignee: Tianyi Cloud Technology Co Ltd
Current assignee: Tianyi Cloud Technology Co Ltd
Priority date: 2021-12-27
Filing date: 2021-12-27
Publication date: 2022-05-06

Abstract

The application discloses a data transmission method, a data transmission device and data transmission equipment, which are used for improving the stability of TFTP transmission. The method comprises the following steps: after receiving a request for requesting a first file from a client device, the server parses the request through the lua TFTP plug-in to obtain first information. Wherein the first information comprises at least one of: file name, mode, opcode, optional. And the server sends a first data packet to the client equipment through the TFTP according to the first information. Wherein one or more data packets are used to transmit the first file, the one or more data packets including the first data packet. By the method, the server realizes TFTP through the lua TFTP plug-in, so that a TFTP protocol of a non-blocking I/O model based on Openresty can be realized, port blockage can be avoided, and the TFTP transmission stability is improved.

Description

Data transmission method, device and equipment

Technical Field

The present application relates to the field of information technologies, and in particular, to a data transmission method, apparatus, and device.

Background

The TFTP (simple file transfer protocol) is a protocol used for simple file transfer between a server and a client in a transmission control protocol/internet protocol (TCP/IP) protocol cluster. TFTP has the characteristics of simple operation, suitability for transmitting small-sized files, and the like, but compared with a File Transfer Protocol (FTP), TFTP cannot realize functions such as identity authentication, file directory query, and the like.

TFTP is a connectionless protocol based on the User Datagram Protocol (UDP) that operates with UDP port 69 (i.e., 69 port) defined by the TFTP standard. TFTP is often used to first guide a pre execution environment (PXE) link to acquire resources related to Network boot loader (Network boot loader), or to guide a device such as a diskless workstation or a router that needs to be booted based on a Network.

Currently, TFTP is typically implemented based on a traditional blocking communication model. Although the model can realize the TFTP protocol, the model has the defects of high resource overhead, low performance and the like. In addition, the model adopts multiple processes to process the concurrent requests, and under the condition of higher concurrent pressure, system resources may need to be frequently created and deleted, so that the data request failure of the client device is caused by insufficient or nonexistent system resources, and the stability of TFTP transmission is further influenced. This low processing capacity under high concurrent pressure has a high risk in real production life. For example, when a large number of physical servers make PXE requests, if the servers create and delete system resources frequently, the PXE requests will be affected, and in severe cases, the PXE requests will fail. Moreover, the server frequently creates and deletes system resources, which also causes the failure of automated management of a large amount of hardware resources, thereby affecting the normal work flow.

Therefore, a method capable of improving TFTP transmission stability is required.

Disclosure of Invention

The application provides a data transmission method, a data transmission device and data transmission equipment, which are used for improving TFTP transmission stability.

In a first aspect, an embodiment of the present application provides a data transmission method. The method may be applied to the system shown in fig. 1 below. The method comprises the following steps:

after receiving a request for requesting a first file from a client device, the server may parse the request through the lua TFTP plug-in to obtain first information. Wherein the first information may comprise at least one of: file name, mode, opcode, optional. The server sends the first data packet to the client device through the TFTP according to the first information. Wherein the one or more data packets are used to transmit the first file, the one or more data packets comprising the first data packet. By the method, the server realizes TFTP through the lua TFTP plug-in, so that a TFTP protocol based on an open residual (OpenResty) non-blocking input/output (I/O) model can be realized, port blockage can be avoided, and the stability of TFTP transmission is improved.

In one possible design, after receiving the response from the client device, the server sends a second packet to the client device via TFTP using the third port as the source port and the second port as the destination port, where the one or more packets include the second packet. Wherein the response is used to indicate that the client device received the first data packet.

In this design, the server sends the next data packet to the client device after receiving a response indicating that the client device received the first data packet; if the server does not receive the response within the predetermined time, the server will resend the first data packet to the client device. Through the design, the client device can be ensured to receive the data packet of the first file as much as possible, so that the reliability of TFTP transmission is improved.

In one possible design, the server may determine the configuration information from the first information via the lua TFTP plug-in before sending the first packet to the client device via TFTP; the server may then send the configuration information to the client device. Wherein the configuration information comprises at least one of: the size of the data block, the size of a time window for sending the data packet by the server, the timeout time for sending the data packet by the server and the size of the first file.

With this design, the server transmits configuration information for transmitting a packet to the client device in advance. In this way, the client device may receive the data packet according to the configuration information, for example, the data packet is received at the time window size of the data packet sent by the server, and the data packet does not need to be received at all times, so that the energy consumption of the client device may be saved. And, the configuration information is determined according to the first information obtained from the request, so that the parameters can be flexibly modified and configured during the TFTP transmission process.

In one possible design, when the first information includes a data block size requested by the client device, the server may determine, through the lua TFTP plug-in, a size of the data block in the configuration information according to the data block size requested by the client device. That is, the lua TFTP plug-in the server determines the size of the data block in the configuration information according to the size of the data block requested by the client device.

In one possible design, the server may send the first packet to the client device using the size of the block of data in the configuration information.

In one possible design, the first information further includes an address and a port of the client device, so that the server may send the first packet to the client device through TFTP according to the address and the port of the client device.

In one possible design, the server may also randomly select a port for transmitting the first packet before transmitting the first packet to the client device via TFTP.

In one possible design, before sending the first packet to the client device via TFTP, the server may initialize the following parameters: the size of the data block, the size of a time window for sending the data packet by the server, the timeout time for sending the data packet by the server and the size of the first file.

In a second aspect, an embodiment of the present application provides a data transmission apparatus, including a unit configured to perform each step in any one of the above aspects.

In a third aspect, an embodiment of the present application provides a data transmission device, including at least one processing element and at least one storage element, where the at least one storage element is used to store programs and data, and the at least one processing element is used to read and execute the programs and data stored by the storage element, so that the method provided in any one of the above aspects of the present application is implemented.

In a fourth aspect, an embodiment of the present application provides a data transmission system, including: the server and the client device for executing the method provided by the first aspect, wherein the client device can execute the operation of the client device in the method provided by the first aspect.

The technical effects achieved by any one of the second to fourth aspects can be described with reference to any one of the possible designs of the first aspect, and the repetition is not discussed.

Drawings

FIG. 1 is a block diagram of a system according to an embodiment of the present disclosure;

fig. 2 is a flowchart of a data transmission method according to an embodiment of the present application;

fig. 3 is a schematic diagram of a structure of a data packet provided in an embodiment of the present application;

fig. 4 is a flowchart of another data transmission method according to an embodiment of the present application;

fig. 5 is a flowchart of another data transmission method provided in the embodiment of the present application;

fig. 6 is a structural diagram of a data transmission device according to an embodiment of the present application;

fig. 7 is a structural diagram of a data transmission device according to an embodiment of the present application.

Detailed Description

The application provides a data transmission method, a data transmission device and data transmission equipment, which are used for improving the stability of TFTP transmission. The method, the device and the equipment are based on the same technical conception, and because the principles of solving the problems are similar, the implementation of the device, the equipment and the method can be mutually referred, and repeated parts are not described again.

According to the scheme provided by the embodiment of the application, after receiving the request for requesting the first file from the client device, the server analyzes the request through the lua TFTP plug-in to obtain the first information. Wherein the first information comprises at least one of: file name, mode, opcode, optional. And the server sends a first data packet to the client equipment through the TFTP according to the first information. Wherein one or more data packets are used to transmit the first file, the one or more data packets including the first data packet. By the method, the server realizes TFTP through the lua TFTP plug-in, so that a TFTP protocol of a non-blocking I/O model based on Openresty can be realized, port blockage can be avoided, and the TFTP transmission stability is improved.

The following describes an implementation process of the present application with reference to the drawings.

FIG. 1 is a schematic diagram of a system to which embodiments of the present application are applicable. As shown in fig. 1, the server may be connected via a network with one or more client devices (e.g., client device 1, client device 2, client device 3 in the figure).

Wherein, the server is a server capable of realizing TFTP. The server stores the data packet. The data packet may be transmitted to the client device through TFTP upon request of the client device.

The client device may be an electronic device. The electronic device may be a computer device with a processor, such as a desktop computer, a personal computer, a server, or the like. The electronic device may also be a portable electronic device with a processor, such as a mobile phone, a tablet computer, a wearable device (e.g., a smart watch) with a wireless communication function, an in-vehicle device, and the like. Exemplary embodiments of the portable electronic device include, but are not limited to, a mount

Or other operating system.

The scheme provided by the application is explained in the following with reference to the attached drawings.

The embodiment of the present application provides a communication method, which can be applied to the communication system shown in fig. 1. The flow of the method will be described in detail with reference to the flow chart shown in fig. 2.

S201: the client device sends a request for a first file (hereinafter referred to as a first request) to the server.

The destination port of the first request sent to the server by the client device is a first port of the server, and the source port is a second port of the client.

The first port may be pre-configured (e.g., by the server or network management device after pre-configuring it to the client device) or may be protocol-specific. For example, the first port is a 69 port of the server. When the first port is the 69 port of the server, the server uses the 69 port to passively open the connection.

The second port is randomly selected by the client device. When the client device needs to request the first file from the server, the client device may actively open a connection, randomly selecting one port (i.e., the second port) on the client device.

In some possible implementations, the first request may include at least one of: filename (filename), mode (mode), operation code (op code), options (options).

In addition, the first request further includes: an address of the client device and a second port.

Optionally, the first request may be an RRQ packet (also referred to as an RRQ packet) or an RRQ request.

The format of the RRQ packet may be as shown in a in fig. 3. The RRQ packet may include at least one of: file name, mode, opcode, optional. The file name may indicate a name of a packet (hereinafter, referred to as a first file) requested to be acquired by the client device. The pattern may be netascii or binary (binary). The opcode may occupy two bytes. For example, when the operation code is 1, it indicates that the packet is an RRQ packet. Options include: the option name and the option value. The selectable items may be used to indicate capabilities of the client device. For example, at which time periods the client device may receive the data packets, the client device may receive a range of sizes of the data packets. Therefore, the server can determine corresponding configuration information for the client device according to the information, and the reliability of the client device for receiving the data packet is improved.

S202: the server parses the first request through a lua TFTP plug-in (plugin), and obtains first information.

Wherein the first information may comprise at least one of: file name, mode, opcode, optional.

Optionally, the first information further includes: an address of the client device and a second port.

S203: and the server sends a first data packet to the client equipment through the TFTP according to the first information.

When the server needs to send the first file to the client device, the server may send the first file via one or more data packets. The one or more data packets comprise a first data packet.

After the server receives the first request, the server actively opens the connection and randomly selects one port (i.e. the third port) of the server. The server may then send the first packet to the client device via TFTP using the third port as a source port and the second port as a destination port.

The server may send one or more DATA packets of the first file via a file (DATA) DATA packet (which may also be referred to as a DATA packet or DATA request). The format of the DATA packet may be as shown at B in fig. 3. The DATA packet may contain at least one of: op code (which may occupy 2 bytes), block number (i.e., the number of a packet, which may be represented by a block and may occupy 2 bytes), data. For example, a DATA packet may include: op code 3, block 1, 1024 bits of data.

Optionally, in S203, before sending the first data packet to the client device through TFTP, the server may further initialize the following parameters: the size of the data block, the size of a time window for sending the data packet by the server, the timeout time for sending the data packet by the server and the size of the first file.

In some possible implementations, the method shown in fig. 2 further includes:

s204: the client device sends an Acknowledgement (ACK) (which may also be referred to as an ACK request) to the server. Wherein the response is used for indicating that the client device receives the first data packet;

the response may include indication information of the first packet, such as the number of the first packet. The size of the acknowledgment may be 4 bytes. For example, the ACK includes: the op code is 4, and the block is 1.

Optionally, if the server receives an Error (ERR) packet or does not receive the response within a predetermined time, the server may repeatedly send the first packet to the client device.

The format of the ERR packet may be shown as D in fig. 3. The ERR packet may include at least one of: op code (which may occupy 2 bytes), error information. The op code of the ERR packet is 5.

After S204, S203-S204 may be repeatedly performed, except that the first data packet is changed to other data packets (e.g., second data packets) of the first file, until the server successfully transmits all data packets of the first file to the client device.

In this way, the server sends the next data packet to the client device after receiving a response indicating that the client device received the first data packet; if the server does not receive the response within the predetermined time, the server will resend the first data packet to the client device. Therefore, the client device can be ensured to receive the data packet of the first file as much as possible, and the reliability of TFTP transmission is improved.

In some possible implementations, before S203, the method shown in fig. 2 further includes:

s205: the server determines the configuration information according to the first information via the lua TFTP plugin.

Wherein the configuration information may comprise at least one of: the size of the data block, the size of a time window for sending the data packet by the server, the timeout time for sending the data packet by the server and the size of the first file.

Optionally, when the first information includes the size of the data block requested by the client device, the server may determine, by the lua TFTP plug-in, the size of the data block in the configuration information according to the size of the data block requested by the client device. For example, the first information may include a data block size requested by the client device of 1024 bytes, the server may support transmission of 1024 bytes, and the server may determine that the data block size in the configuration information is 1024 bytes.

S206: the server sends configuration information to the client device.

Alternatively, the server may request to send the configuration information to the client device through an Option Acknowledgement (OACK). For example, the OACK request includes: op code 6 and blksize 1024. Wherein the unit of blksize may be bytes.

After receiving the configuration information, the client device may set the corresponding option value to the value in the configuration information, so that the option value of the client is consistent with the server.

After S206, the method may further include: s207: the client device sends an ACK request to the server.

The ACK request includes an ACK packet (also referred to as an ACK packet). The format of the ACK packet may be as shown by C in fig. 3. The ACK packet may include at least one of: op code (which may occupy 2 bytes), block number (i.e., the number of a packet, which may be represented by a block, which occupies 2 bytes). For example, the ACK request includes: op code is 4 and block is 0. Wherein the unit of blksize may be bytes.

Optionally, in S203, the server may send the first data packet according to the configuration information. For example, when the size of the data block in the configuration information is 1024 bytes, the data block size of the first data packet is 1024 bytes.

In this way, the server sends configuration information for sending data packets to the client device in advance. In this way, the client device may receive the data packet according to the configuration information, for example, the data packet is received at the time window size of the data packet sent by the server, and the data packet does not need to be received at all times, so that the energy consumption of the client device may be saved.

Optionally, in the method shown in fig. 2, there may be a lua plug-in of Openresty (also referred to as a lua TFTP plug-in) in the server, and the operation of the server in the method shown in fig. 2 may be performed by the lua TFTP plug-in. The OpenResty is a mature network platform, the lua is a small script language, and can be embedded into an application program to provide flexible expansion and customization functions for the application program. In this way, TFTP may be implemented based on the openrestty lua plug-in.

In the method, S201, S206 and S207 may be a protocol negotiation section, and S203 to S204 may be a data transmission section.

Compared with the prior art, the method has the advantages that the non-blocking I/O model is adopted, the management capability of the cluster can be greatly improved, the expansion capability of the TFTP server is improved, and high availability is realized. In addition, the method can realize high data throughput while effectively solving the high concurrency problem in the super-large scale cluster, breaks through the limitation of high resource overhead under the traditional model, and provides a reliable and stable basic component for the super-large scale resource pool.

The embodiment of the present application further provides a communication method, which can be applied to the communication system shown in fig. 1. The flow of the method will be described in detail with reference to the flow chart shown in fig. 4.

S401: the client device sends a RRQ request to openreserve.

The specific content of the RRQ request may refer to the first request in the method shown in fig. 2, which is not described herein again. The RRQ request may comprise an RRQ packet. The opcode in the OACK request is 1.

Openresty may be installed in the server.

S402: OpenResty sends an RRQ packet (package) to the lua TFTP plug-in (i.e., the plug-in FIG. 4).

The format and content of the RRQ packet can refer to the method shown in fig. 2, and are not described herein again.

In this application, the lua TFTP plug-in may be installed in the server.

S403: and the lua TFTP plug-in analyzes the RRQ data packet to obtain the file name, the mode, the operation code and the optional items in the RRQ data packet.

S404: the lua TFTP plug-in may obtain the address and port of the client device according to the RRQ request.

S405: the lua TFTP card randomly selects a port.

For the first file, the lua TFTP plug-in initially randomly selects a port (e.g., the third port) of the server to communicate with the client device through the selected port. For example, the lua TFTP plug uses UDP protocol to specify ports through socket functions.

S406: the lua TFTP plug-in determines the server support for the alternatives.

When the RRQ packet contains a selectable option, the selectable option may act as a server and client device to negotiate information. The server may determine the following parameter information according to the options: the size of the data block (blksize, which may also be referred to as the size of the data block), the size of the time window (window size, which may be used for the server to send the data packet), the timeout time (timeout, which may be the timeout time for the server to send the data packet), the size of the first file (tsize, which may also be referred to as the size of the file to be written or the size of the file to be transmitted). The data packets are one or more data packets in the first file. These parameter information may also be referred to as configuration information.

For example, an option is that the client device may receive a size of a block of data (e.g., 1024 bytes), and the server may set the parameter blksize to 1024 bytes if it supports sending a data packet of 1024 bytes.

S406 is an optional step, and when the RRQ packet contains an optional item, S406 may be performed, otherwise, the method may not contain S406.

S407: the lua TFTP plug-in initializes the parameters.

For example, the lua TFTP plug-in may initialize the following parameters to 0: blksize, block, tsize, timeout.

S408: the lua TFTP plug sends an OACK packet to OpenResty.

The OACK packet includes the parameter information determined in S406.

S409: openness sends an OACK request (which may also be referred to as an OACK) to the client device.

Wherein the OACK request comprises an OACK packet. The opcode in the OACK request is 6.

S410: the client device sends an ACK request (which may also be referred to as an ACK) to openreserve.

Wherein, the ACK request comprises an ACK data packet; the operation code of the ACK packet is 4 and block is 0.

After receiving the OACK packet, the client device may set the corresponding option value as the parameter information in the OACK packet, so that the option value of the client is consistent with that of the server.

S411: OpenResty sends an ACK packet to the lua TFTP plugin.

S412: the lua TFTP plug-in reads the first file and sends a data packet of the first file to the client device through OpenResty.

The server may begin transmitting packets of the first file after receiving the ACK packet, each data block having a size of blksize determined in S406.

The lua TFTP plug-in may request sending of a DATA packet of the first file via DATA (DATA); the data packet of the first file may also be sent by an ACK request. The following description will take an example in which the lua TFTP plug-in sends a packet of a first file via an ACK request, where the first file includes N packets. Wherein N is a positive integer.

S412 may include A1-A3, described in more detail below.

A1: the lua TFTP plug-in reads a first data packet of the first file and sends an ACK data packet 1 to OpenResty. Wherein ACK packet 1 comprises the first packet. The operation code in the ACK packet 1 is 4, and block is 1. Openness sends an ACK request 1 to the client device, where the ACK request 1 includes an ACK packet 1.

For example, openreserve may send ACK request 1 to the client device with the third port as the source port and the second port as the destination port.

A2: and the lua TFTP plug-in reads a second data packet of the first file and sends an ACK data packet 2 to OpenResty, wherein the ACK data packet 2 comprises the second data packet. The operation code in ACK packet 2 is 4, and block is 2. Openness sends an ACK request 2 to the client device, where the ACK request 2 includes an ACK packet 2.

For example, openreserve may send ACK request 2 to the client device with the third port as the source port and the second port as the destination port.

A3: and in the same way, the lua TFTP plug-in sends the data packets of the first file one by one until all the data packets of the first file are sent. For example, the lua TFTP plug-in reads an nth packet of the first file and sends an ACK packet N to openreserve, where the ACK packet N includes the nth packet. The operation code in the ACK packet N is 4, and block is N. Openness sends an ACK request N to the client device, where the ACK request N includes an ACK packet N. As an example, openreserve may send an ACK request N to the client device with the third port as a source port and the second port as a destination port.

Optionally, after receiving each data packet, the client device may send ACK information to the server, where each ACK information includes a corresponding block value. The server may send the next data packet after receiving the ACK information.

Optionally, when a certain data packet fails to be transmitted, the server may retransmit the data packet. If the transmission is not successful for M times, the entire operation may be interrupted. Where M is an integer greater than 1, e.g., M ═ 3.

When the server does not receive the ACK information aiming at the data packet within the preset time after the data packet is sent, the server can determine that the data packet transmission fails.

S413: after the client device and the lua TFTP plug-in transmit all the data packets of the first file, the connection and the process corresponding to the first file are closed.

Optionally, openreserve is implemented by a lua TFTP plug-in, and in this case, the interaction between the lua TFTP plug-in and openreserve may be omitted.

Compared with the prior art, the method has the advantages that the non-blocking I/O model is adopted, the management capability of the cluster can be greatly improved, the expansion capability of the TFTP server is improved, and high availability is realized. In addition, the method can realize high data throughput while effectively solving the high concurrency problem in the super-large scale cluster, breaks through the limitation of high resource overhead under the traditional model, and provides a reliable and stable basic component for the super-large scale resource pool. In addition, the method can maintain the stability of the processing capacity while improving the processing efficiency, and can well ensure the smooth operation of the physical server work flow, thereby providing a stable and reliable TFTP solution for the infrastructure such as Internet Data Center (IDC), better completing the subsequent work such as hardware resource automatic management, and improving the efficiency and reliability of the whole product flow.

The embodiment of the present application further provides a communication method, which can be applied to the communication system shown in fig. 1. The embodiment may use the TFTP protocol to transmit the memory image at the time of PXE start, where the requester is a client device in the TFTP protocol, and the image sender is a server (also referred to as a server) in the TFTP protocol. The flow of the method will be described in detail with reference to the flow chart shown in fig. 5.

S501: the client device sends an RRQ request to the server.

The RRQ request comprises an RRQ packet. For details of the RRQ packet, reference may be made to the methods shown in fig. 2 and fig. 4, which are not described herein again.

S502: the server parses the RRQ packet.

By parsing the RRQ packet, the server can obtain information such as an operation code, a file name, a mode, an option, and the like. And the server can also acquire the address and the port of the client device according to the RRQ data packet.

The server may check options. When the RRQ request carries the options, the server determines the parameter values of blksize, tsize, timeout, windowsize and the like according to the support condition of the server to the options, and sends the parameter values to the client device.

Additionally, the server may initially randomly select a port (e.g., a first port) of the server.

S503: the server sends the OACK data packet to the client device.

The OACK packet includes the parameter value determined in S502.

And the client equipment receives the OACK data packet, and the connection establishment between the client equipment and the server is completed.

S504: and the client equipment sets parameters according to the OACK data packet and sends an ACK data packet to the server.

Block in the ACK packet is 0.

S505: the server starts the data transfer.

Wherein the size of the data packet (i.e., data packet) is blksize determined at S502 (i.e., blksize agreed by the server and the client). By setting the size of the data packet, the transmission efficiency can be improved.

S506: after receiving the data packet, the client device sends ACK information (which may be an ACK packet) to the server, where each ACK information carries a corresponding block value, and an initial value is 1.

S505-SS06 are repeated until the data transmission ends.

S507: after the data transfer is complete, the client device and the server are disconnected.

Optionally, in the method shown in fig. 2, there may be a lua plug-in of Openresty (also referred to as a lua TFTP plug-in) in the server, and the lua TFTP plug-in executes the operation of the server in the method shown in fig. 2. The OpenResty is a mature network platform, the lua is a small script language, and can be embedded into an application program to provide flexible expansion and customization functions for the application program. In this way, TFTP may be implemented based on the Lua plug-in of Openresty.

In this embodiment, by applying the TFTP protocol under the openreserve-based non-blocking I/O model, data transmission can be completed with high performance. By adopting the scheme of the embodiment, the efficiency of the transmission process can be improved, and the method has higher flexibility and stability. In addition, parameters during data transmission can be adjusted according to the specific conditions of each project, so that higher flexibility can be realized. In addition, through tests, the TFTP implementation scheme of this embodiment can implement a highly reliable transmission function in an ultra-large-scale cluster environment, and improve system stability while ensuring transmission efficiency, thereby avoiding the influence of transmission failure on instructions such as PXE start-up, effectively solving the problem of low transmission performance under high concurrency scenarios, implementing high data throughput, significantly reducing resource overhead, and improving the performance of the entire system.

The scheme provided by the embodiment of the application is mainly introduced from the perspective of device interaction. It is to be understood that in order to implement the above functions, the network element may include a corresponding hardware structure and/or software modules for performing the respective functions. Those of skill in the art will readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiment of the present application, the data transmission device may be divided into the functional units according to the method example, for example, each functional unit may be divided corresponding to each function, or two or more functions may be integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

In case of integrated units, fig. 6 shows a possible exemplary block diagram of the apparatus involved in the embodiments of the present application. As shown in fig. 6, the apparatus 600 may include: a processing unit 602 and a communication unit 601. The processing unit 602 is configured to control and manage operations of the apparatus 600. The communication unit 601 is used to support communication between the apparatus 600 and other devices. Optionally, the communication unit 601, also referred to as a transceiving unit, may comprise a receiving unit and/or a transmitting unit for performing receiving and transmitting operations, respectively. The apparatus 600 may further comprise a storage unit 601 for storing program code and/or data of the apparatus 600.

The apparatus 600 may be a server in the above embodiments. The processing unit 602 may support the apparatus 600 to perform the actions of the server in the above method examples (such as fig. 2 or fig. 5), or the processing unit 602 may support the apparatus 600 to perform the actions of the openreserve or lua TFTP plug in the above method examples (such as fig. 4), and the communication unit 601 may support communication between the apparatus 600 and other devices.

For example, in one embodiment, processing unit 602 is configured to: receiving a request for requesting a first file from a client device from a first port through a communication unit 601; determining that the port of the client device comprises a second port according to the request; randomly selecting a third port; with the third port as a source port and the second port as a destination port, a first packet is sent to the client device through the communication unit 601 by using TFTP, wherein one or more packets are used for transmitting the first file, and the one or more packets include the first packet.

The apparatus 600 may be a client device in the above embodiments. The processing unit 602 may enable the apparatus 600 to perform the actions of the client device in the above method examples (such as fig. 2, fig. 4, or fig. 5). The communication unit 601 may support communication between the apparatus 600 and other devices.

For example, in another embodiment, the processing unit 602 is configured to: randomly selecting a second port; determining that the port of the server comprises a first port; sending a request for requesting a first file to a server through the communication unit 601 with the second port as a source port and the first port as a destination port; a first data packet sent by the server through TFTP is received from the second port through a communication unit 601, wherein one or more data packets are used for transmitting the first file, and the one or more data packets include the first data packet.

It should be understood that the division of the units in the above apparatus is only a division of logical functions, and the actual implementation may be wholly or partially integrated into one physical entity or may be physically separated. And the units in the device can be realized in the form of software called by the processing element; or may be implemented entirely in hardware; part of the units can also be realized in the form of software called by a processing element, and part of the units can be realized in the form of hardware. For example, each unit may be a processing element separately set up, or may be implemented by being integrated into a chip of the apparatus, or may be stored in a memory in the form of a program, and a function of the unit may be called and executed by a processing element of the apparatus. In addition, all or part of the units can be integrated together or can be independently realized. The processing element described herein may in turn be a processor, which may be an integrated circuit having signal processing capabilities. In implementation, each operation of the above method or each unit above may be implemented by an integrated logic circuit of hardware in a processor element or implemented in a form called by software through the processor element.

In one example, the units in any of the above apparatus may be one or more integrated circuits configured to implement the above method, for example: one or more Application Specific Integrated Circuits (ASICs), or one or more microprocessors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs), or a combination of at least two of these integrated circuit forms. For another example, when a unit in a device may be implemented in the form of a processing element scheduler, the processing element may be a processor, such as a Central Processing Unit (CPU), or other processor capable of invoking a program. As another example, these units may be integrated together and implemented in the form of a system-on-a-chip (SOC).

The above unit for receiving is an interface circuit of the apparatus for receiving signals from other apparatuses. For example, when the device is implemented in the form of a chip, the receiving unit is an interface circuit for the chip to receive signals from other chips or devices. The above unit for transmitting is an interface circuit of the apparatus for transmitting a signal to other apparatuses. For example, when the device is implemented in the form of a chip, the transmitting unit is an interface circuit for the chip to transmit signals to other chips or devices.

Fig. 7 is a schematic structural diagram of a data transmission device according to an embodiment of the present application. The data transmission device 700 may be a server or a client device in the above embodiments, for implementing the functions of the server or the client device in the above embodiments.

As shown in fig. 7, device 700 may include a communication module 701, a processor 702, and a memory 703. The communication module 701, the processor 702, and the memory 703 are optionally connected to each other, and the communication module 701, the processor 702, and the memory 703 are connected to each other through a bus 704. The bus 704 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 7, but this is not intended to represent only one bus or type of bus.

The communication module 701 is configured to receive and send data, so as to implement communication interaction with other devices. For example, the communication module 701 may be implemented by a physical interface, a communication module, a communication interface, and an input/output interface.

The processor 702 may be configured to enable the communication device 700 to perform the processing acts in the above-described method embodiments. When the communication device 700 is configured to implement the above-described method embodiments, the processor 702 may also be configured to implement the functions of the processing unit 602 described above.

The apparatus 700 shown in fig. 7 is capable of implementing various processes involving the apparatus 700 in the method embodiments described above. The operations and/or functions of the respective modules in the apparatus 700 shown in fig. 7 are respectively for implementing the corresponding flows in the above-described method embodiments. Specifically, reference may be made to the description of the above method embodiments, and the detailed description is appropriately omitted herein to avoid redundancy.

The terms "system" and "network" in the embodiments of the present application may be used interchangeably. "at least one" means one or more, "a plurality" means two or more. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a alone, A and B together, and B alone, wherein A and B may be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" or similar expressions refer to any combination of these items, including any combination of the singular or plural items. For example, "at least one of A, B, and C" includes A, B, C, AB, AC, BC, or ABC. And, unless specifically stated otherwise, the embodiments of the present application refer to the ordinal numbers "first", "second", etc., for distinguishing between a plurality of objects, and do not limit the order, sequence, priority, or importance of the plurality of objects.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims

1. A data transmission method is applied to a server and comprises the following steps:

receiving a request from a client device for a first file;

analyzing the request through a TFTP plug-in of the lua common file transfer protocol to obtain first information; wherein the first information comprises at least one of: file name, mode, opcode, optional;

and sending a first data packet to the client device through TFTP according to the first information, wherein one or more data packets are used for transmitting the first file, and the one or more data packets comprise the first data packet.

2. The method of claim 1, wherein after sending the first data packet to the client device over TFTP, the method further comprises:

receiving a response from the client device, the response indicating that the client device received the first data packet;

transmitting a second data packet to the client device over TFTP, wherein the one or more data packets include the second data packet.

3. The method of claim 1 or 2, wherein prior to sending the first data packet to the client device over TFTP, the method further comprises:

determining configuration information according to the first information through a lua TFTP plug-in; wherein the configuration information comprises at least one of: the size of a data block, the size of a time window for sending a data packet by the server, the timeout time for sending the data packet by the server and the size of a first file are calculated;

sending configuration information to the client device.

4. The method of claim 1 or 2, wherein determining configuration information based on the first information when the first information contains a data block size requested by the client device comprises:

and determining the size of the data block in the configuration information according to the size of the data block requested by the client equipment through the lua TFTP plug-in.

5. The method of claim 4, wherein sending a first packet to the client device over TFTP based on the first information comprises:

and sending the first data packet to the client device by using the size of the data block in the configuration information.

6. The method of claim 1 or 2, wherein the first information further comprises an address and a port of the client device,

according to the first information, sending a first data packet to the client device through TFTP, including: and according to the address and the port of the client device, sending a first data packet to the client device through the TFTP.

7. The method of claim 1 or 2, wherein prior to sending the first data packet to the client device over TFTP, the method further comprises:

randomly selecting a port for transmitting the first packet.

8. The method of claim 1 or 2, wherein prior to sending the first data packet to the client device over TFTP, the method further comprises:

the following parameters are initialized: the size of the data block, the size of a time window for sending the data packet by the server, the timeout time for sending the data packet by the server and the size of the first file.

9. A data transmission apparatus, comprising:

a communication unit for receiving and transmitting data;

a processing unit for performing the method of any one of claims 1-8 by means of the communication unit.

10. A data transmission system, comprising:

a server for implementing the method of any one of claims 1-8;

a client device for carrying out the operations of the client device in the method according to any one of claims 1 to 8.