JP7427464B2 - Communication devices, communication methods and programs - Google Patents

Description

The present invention relates to a communication device, a communication method, and a program.

BACKGROUND ART In TCP/IP (Transmission Control Protocol/Internet Protocol) protocol processing, there is a need to reduce processing by a CPU (Central Processing Unit) and speed up communication. In order to meet such demands, a technique for generating packets using a packet generation offloader, which is hardware, is sometimes adopted. In this technology, the packet generation offloader simultaneously performs a process of transferring specified user data to a network buffer and a checksum calculation for each call of a socket API (Application Programming Interface). Then, data sizes smaller than MSS (Maximum Segment Size) are packetized one by one by CPU processing using the checksum value calculated in advance.

Further, a technique is used in which a packet generation offloader executes processing of chunking segments of transmission data and processing of converting the chunked segments into IP packets. This technology is realized by a TSO (TCP Segmentation Offload) function. The TSO function is generally implemented by a packet generation offloader such as a NIC (Network Interface Card). By using the TSO function, instead of sending application data in MSS units, it is possible to send a transmission request to the packet generation offloader in data units larger than MSS, chunk it in MSS units, and continuously transmit it to the network. .

By increasing the specs of the CPU or using a packet generation offloader, the packet generation process may become faster than the transmission process of the communication interface (hereinafter referred to as network I/F). In this case, a phenomenon occurs in which all the data transmitted using the socket API cannot be transmitted or a transmission error occurs, and the application needs to periodically call the socket API to check whether data can be transmitted.

Patent Document 1 discloses a communication adapter having a transmission buffer and a bus control section. After confirming that the transmission buffer has been handed over from the buffer management section, the bus control section uses the transmission buffer to store the transmission data when data transmission is requested from the ATM.

Japanese Patent Application Publication No. 6-342410

However, if you periodically call the socket API to check whether it is possible to send, even if the protocol stack and network I/F become ready to send, the state will not be ready for sending until the confirmation time interval has elapsed. cannot be detected. For this reason, there is a possibility that the packet transmission efficiency will decrease.

Furthermore, in the technology disclosed in Patent Document 1, when data transmission is requested from the ATM after confirming that the transmission buffer has been handed over, the bus control unit stores the transmission data in the transmission buffer, and stores the transmission data in the transmission buffer. is sent to the network. Therefore, in the technology disclosed in Patent Document 1, even if the transmission buffer is handed over, the transmission data is not sent to the network unless the ATM requests data transmission. Therefore, depending on the timing of the request for data transmission from the ATM, there is a possibility that the transmission efficiency will decrease.

In view of the above problems, the present invention aims to improve packet transmission efficiency.

A communication device according to one aspect of the present invention includes a storage means for storing a packet including transmission data in a buffer, a transmission means for transmitting the packet stored in the storage means, and a transmission means for transmitting the packet by the transmission means. and a notification means for notifying the release of the buffer when the buffer is released by the release means.

According to the present invention, packet transmission efficiency can be improved.

1 is a block diagram showing an example of a hardware configuration of a communication device according to a first embodiment; FIG. 1 is a block diagram showing an example of a functional configuration of a communication device according to a first embodiment. FIG. 5 is a flowchart showing data transmission processing of the communication device according to the first embodiment. 7 is a flowchart showing data transmission completion processing of the communication device according to the first embodiment. 7 is a flowchart showing data transmission processing of the communication device according to the second embodiment.

Embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Note that the following embodiments do not limit the present invention, and not all combinations of features described in the embodiments are essential to the solution of the present invention. The configuration of the embodiment may be modified or changed as appropriate depending on the specifications of the device to which the present invention is applied and various conditions (conditions of use, environment of use, etc.). The technical scope of the present invention is determined by the claims, and is not limited by the following individual embodiments.

<Embodiment 1>
FIG. 1 is a block diagram showing an example of the hardware configuration of a communication device according to the first embodiment.
Among the functional modules of the communication device 1 shown in FIG. 1, for functions realized by software, a program for providing the functions of each functional module is stored in a memory such as a ROM (Read Only Memory). The program is then read out to RAM (Random Access Memory) and executed by the CPU. As for the functions to be realized by hardware, for example, a predetermined compiler may be used to automatically generate a dedicated circuit on the FPGA from a program for realizing the functions of each functional module. FPGA is an abbreviation for Field Programmable Gate Array. Further, a Gate Array circuit may be formed in the same manner as an FPGA and realized as hardware. Alternatively, it may be realized by an ASIC (Application Specific Integrated Circuit). Note that the configuration of the functional blocks shown in FIG. 1 is an example, and multiple functional blocks may constitute one functional block, or any functional block may be divided into blocks that perform multiple functions. Good too.

In FIG. 1 , a communication device 1 is connected to a communication partner device 3 via a network 2 . The communication device 1 is capable of communicating with a communication partner device 3 via the network 2 . The communication device 1 may be, for example, a personal computer with a communication function, a tablet terminal, a smartphone, a camera, a printer, or a projector project, but is not limited thereto.

In this embodiment, an example will be described in which the communication device 1 uses TCP/IP as the communication protocol. In TCP/IP protocol processing, the communication device 1 uses a network buffer (transmission buffer) for packetization and retransmission processing of transmission data. In the TCP/IP packet transmission process, the communication device 1 transfers the transmission data (user data) specified by the socket API send( ) to the transmission buffer, and chunks it in the maximum transmission unit MTU. MTU is an abbreviation for Maximum Transmission Unit. Then, the communication device 1 calculates a checksum of the chunked data and the pseudo header, and generates a TCP/IP packet to which a TCP header and an IP header are added. When the transmission path is Ethernet (registered trademark), the communication device 1 generates an Ethernet frame to which an Ethernet header is added in addition to these headers, and transmits it to the communication partner device 3 via the network 2.

Furthermore, in packet communication, in order to guarantee the reliability of communication, a communication system is used in which a receiving side that receives a packet transmitted from a transmitting side uses an acknowledgment called an ACK (Acknowledgment). For example, in TCP/IP, the sending side chunks transmission data into segments, packetizes them, and transmits them, and the receiving side manages segments in octet units using sequence numbers, and responds with the sequence number of the received segment as an ACK. do.

At this time, in the TCP/IP protocol processing, window control is performed using a predetermined window size in order to avoid a decrease in communication speed due to the receiving side transmitting an ACK every time the transmitting side sends a packet. In TCP/IP window control, the receiving side sends an ACK with the window size set to the remaining size of the receive buffer, and the sending side can send data without waiting for an ACK until the window size is reached. . Furthermore, in TCP/IP window control, a sliding window is used to further improve communication speed. In a sliding window, the receiver sends an ACK every time it receives a packet, and the sender slides the window when it receives the first ACK and continuously sends the window size of data without waiting for an ACK. It becomes possible to do so.

The communication device 1 includes a RAM (Random Access Memory) 101, a CPU 102, a ROM (Read Only Memory) 103, a recording medium 105, and a communication section 113. The communication device 1 also includes a buffer management section 106, a data transfer section 107, a frame generation section 108, a packet generation section 109, a checksum calculation section 110, a timer management section 104, a buffer release notification section 111, and a notification setting section 112. .

The RAM 101 stores various data and is used as a work memory (work area). The RAM 101 has a memory area 101a for storing and managing transmitted and received data. A packet storage buffer 101b for storing packets containing transmission data is allocated to the memory area 101a.
The CPU 102 operates each function of the communication device 1 by executing various programs stored in the ROM 103 or the recording medium 105 using the RAM 101 as a work memory. CPU 102 may be a single-core processor or a multi-core processor.
The ROM 103 stores various programs executed by the CPU 102.
The recording medium 105 is a program storage unit such as a hard disk or an SSD (Solid State Drive).

The communication unit 113 includes a MAC (Media Access Control) module 113a and a PHY (Physical Layer) module 113b, and communicates with the communication partner device 3 via a network 2 such as Ethernet (registered trademark). When data is transmitted and received by the communication device 1, the network driver is executed by the CPU 102, and the MAC module 113a is controlled in accordance with this execution. Note that in this embodiment, the communication unit 113 communicates via Ethernet (registered trademark); It is also possible to communicate via.

The buffer management unit 106 acquires management information associated with a buffer that stores a header or a packet.
Data transfer section 107 transfers data stored in RAM 101 to frame generation section 108 and packet generation section 109 using DMA (Direct Memory Access). The data transfer unit 107 is, for example, a DMA controller that performs DMA. Note that the data transfer unit 107 does not necessarily need to transfer data by DMA transfer, and may be controlled by the CPU 102 when transferring data.

Frame generation section 108 determines the size of transmission data to be transmitted, and performs header information generation processing to generate transmission data of the determined size and header information for the transmission data.
The packet generation unit 109 segments the transmission data and generates a header based on the transmission data of the size determined by the frame generation unit 108 and the header information, and generates a packet from the segments and headers.
The checksum calculation unit 110 calculates a checksum for data stored in the RAM 101.

After the communication unit 113 completes transmission of the packet, the buffer release notification unit 111 notifies the release of the packet storage buffer 101b used for storing the packet. For example, assume that after the communication unit 113 completes sending a packet to the network 2 under the control of the network driver, the network driver releases the packet storage buffer 101b used to store the packet. At this time, the buffer release notification unit 111 notifies the CPU 102 of the release of the packet storage buffer 101b by the network driver.

The timer management unit 104 manages the predetermined time required for packet transmission.
The notification setting unit 112 sets whether or not to cause the buffer release notification unit 120 to notify the release of the packet storage buffer 101b. The notification setting unit 112 can enable and disable notifications using a sending application. For example, if the socket API is returning a return value normally, the notification setting unit 112 sets the notification to invalid and does not notify that the buffer is released. On the other hand, if the socket API has not been able to transmit all the transmission data or a transmission error has occurred, the notification setting unit 112 sets the notification to valid and notifies the buffer release. Furthermore, when the socket API returns to a state in which all transmission data can be transmitted, the notification setting unit 112 sets the notification to be invalid and does not notify that the buffer is released.
The notification setting unit 112 may switch between valid and invalid notifications based on the protocol. For example, in TCP/IP protocol processing, if a packet for retransmission can be stored in a transmission buffer, the notification is set to invalid and notification of buffer release is not notified because the packet can be retransmitted from the transmission buffer.
Note that the packet described below is a unit of data transmitted and received over IP communication. Any method can be used to assemble the packets, and the description thereof will be omitted.

FIG. 2 is a block diagram showing an example of the functional configuration of the communication device according to the first embodiment.
In FIG. 2, the communication device 1 includes an application 21, a protocol stack 22, a packet generation section 23, a communication I/F control section 24, a communication I/F 25, and a notification section 26. The protocol stack 22 includes a network buffer management section 221, a segment processing section 225, a communication protocol processing section 226, a connection management section 222, a window control section 223, and a congestion control section 224. The packet generation unit 23 includes a packet generation completion notification unit 231, a data transfer unit 232, a header generation unit 233, and a packet generation unit 234. The notification unit 26 includes a buffer release notification unit 261 and a notification setting unit 262.

Application 21 is a user application. The application 21 inputs application data of an arbitrary size to be transmitted to the protocol stack 22 as transmission data.

The protocol stack 22 uses the network buffer management unit 221 to manage transmission data input from the application 21 (transmission buffer (not shown) allocated to the memory area 101a of the RAM 101). The network buffer management unit 221 corresponds to the buffer management unit 106 in FIG. The network buffer management unit 221 stores headers or packets in a buffer allocated to the memory area 101a of the RAM 101. Further, the network buffer management unit 221 manages the size of transmission data stored in the memory area 101a.

The connection management unit 222 manages communication connections of the communication device 1. For example, the connection management unit 222 manages connection information such as MSS in a communication connection to the application 21.
The window control unit 223 acquires the transmission window size of the TCP connection from the confirmation response received via the communication I/F control unit 24 and manages it.

The congestion control unit 224 manages congestion control in TCP connections. For example, the congestion control unit 224 manages a congestion window (congestion window size) in a communication connection to the application 21.
The segment processing unit 225 is managed by the network buffer management unit 221. The segment processing unit 225 determines the size of the transmission data based on the size of the transmission data, MSS, transmission window size, congestion window size, etc. At this time, the size of the transmission data is stored in the transmission buffer, the MSS is managed by the connection management section 222, the transmission window size is managed by the window control section 223, and the congestion window size is managed by the congestion control section 224. be done.
The communication protocol processing unit 226 generates a TCP header, a UDP header, and an IP header of a TCP segment, performs processing such as checksum calculation, and generates a packet.

The packet generation unit 23 is an offload processing unit (hardware). As the offload processing unit, a packet generation offloader specialized for packet processing can be used. By using the TSO function, the packet generation offloader chunks application data requested to be transmitted in units of data larger than the MSS in units of MSS, and enables continuous transmission to the network. The packet generation completion notification unit 231 selects whether to notify the completion of the packetization processing by the data transfer unit 232, header generation unit 233, and packet generation unit 234 by using an interrupt or by polling.
The data transfer unit 232 corresponds to the data transfer unit 107 in FIG. 1, and has a data chunking function, a checksum calculation function, and a data transfer function. The chunk function chunks transmission data into predetermined units (for example, MSS units) when transferring data. The checksum calculation function corresponds to the checksum calculation section 110 in FIG. The checksum calculation function performs checksum calculation for each piece of data chunked into predetermined units.

The header generation unit 233 generates a TCP/IP header, a UDP/IP header, and an Ethernet header using the transmission buffer managed by the network buffer management unit 221 based on predetermined header information.
The packet generation unit 234 performs packetization processing using the data output from the data transfer unit 232 and the header generation unit 233.

In this embodiment, the communication protocol processing unit 226 or the packet generation unit 23 generates a packet using the transmission buffer managed by the network buffer management unit 221 according to the size of the transmission data determined by the segment processing unit 225. . The packet generation method will be described later using FIG. 3.

The packets generated by the communication protocol processing unit 226 or the packet generation unit 23 are input to the communication I/F control unit 24. The communication I/F control unit 24 exchanges data and information between the protocol stack 22 and the communication I/F 25. The communication I/F 25 corresponds to the MAC module 113a and the PHY module 113b in FIG. 1, and performs communication via the network 2. The packet may be transmitted when the timer management unit 104 notifies that a certain period of time or more has elapsed.

When the network buffer management unit 221 releases a buffer in which a packet is stored, the buffer release notification unit 261 notifies the application 21 of the release of the buffer. At this time, after the communication I/F control unit 24 transmits the packet from the communication I/F 25 to the network 2, the buffer release notification unit 261 notifies the application 21 of releasing the buffer in which the packet is stored. The buffer release notification unit 261 corresponds to the buffer release notification unit 111 in FIG.

The notification setting unit 262 sets the notification by the buffer release notification unit 261 to be invalid or valid. The processing of the notification setting unit 262 is realized by a callback function, and when the notification is registered as valid by the application 21, the buffer release is notified, and when the notification is not registered as valid, the buffer release is not notified. Good too. The notification setting section 262 corresponds to the notification setting section 112 in FIG.

Next, data transmission processing performed by the communication device 1 of FIG. 1 will be described with reference to FIGS. 3 and 4. In FIG. 3, data transmission processing using the socket API send() is taken as an example. Note that the same processing as in FIG. 3 can be used in the case of data transmission processing using sendto(), sendmsg(), and sendmmsg(). In FIG. 4, a packet storage buffer release notification process will be described after the data transmission process using the socket API send( ) is completed.
In this embodiment, in data transmission processing using a protocol using a window size, after the transmission of a packet to the network 2 is completed, the application 21 is notified of the release of the packet storage buffer 101b.

Note that each step in FIGS. 3 and 4 is realized by the CPU 102 reading out and executing a program stored in the storage unit of the communication device 1. Furthermore, at least a portion of the flowcharts shown in FIGS. 3 and 4 may be realized by hardware. In the case of implementation using hardware, for example, a dedicated circuit may be automatically generated on the FPGA from a program for implementing each step by using a predetermined compiler. Further, a Gate Array circuit may be formed in the same manner as an FPGA and realized as hardware. Alternatively, it may be realized by ASIC.

In this case, each block in the flowcharts shown in FIGS. 3 and 4 can be regarded as a hardware block. Note that a plurality of blocks may be configured as one hardware block, or one block may be configured as a plurality of hardware blocks.

In S1 of FIG. 3, the CPU 102 of FIG. 1 calls the socket API. More specifically, in response to the CPU 102 executing a predetermined program stored in the ROM 103, the application 21 in FIG. 2 calls send().
When the CPU 102 calls send(), in S2 it determines whether the value specified in send() is correct. If the determination result in S2 is No, the process advances to S3. If the determination result in S2 is Yes, the process advances to S4.

In S3, the CPU 102 sets EALREADY, ENOTCONN, or EFAULT to the error number according to the specified value, sets -1 as the return value, and ends the process.
In S4, the data transfer unit 107 transfers the transmission data from the user buffer (not shown) to the transmission buffer in the RAM 101 which is the data transfer destination, chunks the transmission data, and stores the transmission data in the transmission buffer. , get the buffer for sending data. If zero copy is specified, the data transfer unit 107 specifies the transmission data management buffer, and if zero copy is not specified, the data transfer unit 107 specifies the transmission data buffer, and advances the process to S5.

In S5, the data transfer unit 107 determines whether at least one designated buffer has been secured. If the determination result in S5 is No, the process advances to S6. If the determination result in S5 is Yes, the process advances to S7.
In S6, if no designated buffer has been secured, the data transfer unit 107 sets ENOMEM to the error number, sets -1 as the return value, and advances the process to S19.

In S7, the data transfer unit 107 transfers the transmission data from the user buffer (not shown) to the transmission buffer in the RAM 101, which is the data transfer destination, chunks the data, and stores the chunked data in the transmission buffer. Note that the data transfer unit 107 may store the storage location of the transmission data in the transmission buffer. When send( ) is called with zero copy, the data transfer unit 107 transfers information about the storage location of the user buffer to the send buffer.
The segment processing unit 225 checks whether the size of the transmission data stored in the transmission buffer exceeds the transmission window size managed by the window control unit 223. If the size exceeds, the segment processing unit 225 determines the size of the transmission data stored in the transmission buffer as the size of the transmission data, and if it does not exceed the size, determines the transmission window size as the size of the transmission data, and performs S8. Proceed with the process.

In S8, the frame generation unit 108 generates header information as information for generating a TCP/IP header and an Ethernet header, and proceeds to S9.
In S9, the packet generation unit 109 determines whether at least one packet storage buffer has been secured for storing the packet. If the determination result in S9 is No, the process advances to S10. If the determination result in S9 is Yes, the process advances to S11.
In S10, if no designated buffer has been secured, the packet generation unit 109 sets ENOMEM to the error number, sets -1 as the return value, and advances the process to S19.

In S11, when using the packet generation offloader for packet generation, the protocol stack 22 sets data for packet generation in the packet generation unit 23 and executes it. At this time, in S11, the data transfer unit 232 performs chunking and checksum calculation if the transmission data is not chunked, and performs checksum calculation if it is chunked. Next, in S11, the header generation unit 233 uses the header information generated in S8 to create a TCP/IP header and an Ethernet header (automatically) for each segment obtained by chunking the transmission data in units of MSS. ) generate. If the transmission data is transferred to the transmission buffer in the RAM 101 when send() is called, it is converted into an Ethernet frame by packet generation. Next, in S11, the packet generation unit 234 performs packetization processing using the data output from the data transfer unit 232 and the header generation unit 233.

In S12, the packet generation completion notifying unit 231 determines whether the packet generation offloader process executed in S11 has been completed. If the determination result in S12 is No, the process is repeated to S12 and waits for the process to end. If the determination result in S12 is Yes, the process advances to S13.

In S13, the CPU 101 determines whether the network driver can transmit the packet that has been converted into an Ethernet frame by packet generation. If the determination result in S13 is No, the process advances to S14. If the determination result in S13 is Yes, the process advances to S17.
In S14, the CPU 101 determines whether packets can be added to the transmission queue until the network driver becomes capable of transmission. If the determination result in S14 is No, the process advances to S15. If the determination result in S14 is Yes, the process advances to S16.

In S15, if the packet cannot be added to the transmission queue, the CPU 101 sets the error number to ENOSPC or ENOBUFS, sets -1 as the return value, and advances the process to S19.
In S16, if the packet can be added to the transmission queue, the CPU 101 adds the packet to the transmission queue, and advances the process to S19.
In S17, the communication protocol processing unit 226 transmits the Ethernet frame to the communication I/F control unit 24 using the network driver, and the process proceeds to S18.

In S18, the CPU 101 determines whether the packet generation process has been completed for all packets to be transmitted. If the packet generation processing for all packets to be transmitted has not been completed (S18: Yes), the process returns to S13. If the packet generation process for all packets to be transmitted has been completed (S18: No), the process advances to S19.

In S19, the CPU 101 checks whether all packets to be transmitted (packets queued in the transmission queue in S16) have been transmitted, and whether a transmission error (the transmission errors in S6, S10, and S15 apply) has occurred. judge whether If all packets to be transmitted have been transmitted and no transmission error has occurred (S19: Yes), the process advances to S20. If all the packets to be transmitted have not been transmitted or a transmission error has occurred (S19: No), the process advances to S21.
In S20, the application 21 determines whether there is data to be transmitted. If there is transmission data (S20: Yes), the process returns to the start of the data transmission process in FIG. If there is no data to send (S20: No), the data sending process ends.

In S21, the notification setting unit 262 determines whether to enable (ON) the buffer release notification. The setting to disable the notification is achieved by the application 21 setting the buffer release notification unit 261 to unregister a callback function that sets a buffer release notification. The setting to disable notifications may be implemented by the application 21 through a process of disabling notifications using a callback function. If the notification is not enabled (S21: No), the process returns to the start of the data transmission process. If the notification is set to be enabled (S21: Yes), the process advances to S22.
In S22, the buffer release notification unit 261 waits for notification of release of the buffer storing the packet.

After the network driver transmits the Ethernet frame to the communication I/F control unit 24, the communication unit 113 starts the transmission completion interrupt process shown in FIG.
In FIG. 4, in S231, the network driver releases all buffers storing packets, and advances the process to S232.

In S232, when all the buffers storing packets are released, the buffer release notification unit 261 notifies the application 21 of the buffer release if the buffer release notification function is ON, and the process proceeds to S233. Note that the buffer release notification unit 261 does not notify the application 21 of buffer release when the buffer release notification function is OFF.
In S233, the protocol stack 22 determines whether there are any packets queued in the transmission queue. If there is a packet to be transmitted in the transmission queue (S233: Yes), the process advances to S234. If there is no packet to be transmitted in the transmission queue (S233: No), the process advances to S235.

In S234, if the buffer release notification function is ON, the communication I/F control unit 24 notifies the communication protocol processing unit 226 of transmission completion in response to the transmission completion notification waiting in S24 of FIG. 3, and advances the process to S235. .
In S235, if the buffer release notification function is ON, the buffer release notification unit 261 notifies the application 21 of buffer release in response to the buffer release notification wait in S22 of FIG. 3, and ends the transmission completion interrupt process.

While waiting for the transmission completion notification in S24 of FIG. 3, upon receiving the transmission completion notification from S234 in FIG. 4, the communication protocol processing unit 226 starts the transmission process and advances the process to S13.
While waiting for the buffer release notification in S22 of FIG. 3, upon receiving the buffer release notification from S235 in FIG. 4, the application 21 starts processing and proceeds to S23.
In S23, the notification setting unit 262 sets the buffer release notification to invalid (OFF), and returns to the start of the data transmission process.

As described above, according to the present embodiment, a packet generation process is performed that segments transmission data, generates a TCP/IP header, and converts it into an Ethernet frame, and the network driver transfers the Ethernet frame to the communication I/F control unit. Send to 24th. At this time, the buffer release notification unit notifies the application of the buffer release, so that the application can resume requesting transmission of data as soon as the protocol stack and network driver become ready for transmission. Therefore, even if all the data sent using the socket API cannot be sent or a sending error occurs, the application does not need to periodically call the socket API to check whether data can be sent. As a result, the application can start the transmission process of the transmission data before the time interval for checking whether transmission is possible has elapsed, and the packet transmission efficiency of the communication device 1 can be improved.
Further, according to the embodiment described above, the buffer release completion notification can be set to be enabled or disabled depending on the situation, and when the buffer release completion notification is enabled, the application can receive the buffer release completion notification. Therefore, if the packet is being transmitted normally, the load required for exchanging buffer release completion notifications can be reduced, and the efficiency of the transmission process can be improved.
Note that this embodiment can be applied even when the processing by the hardware of the packet generation unit 23 is executed by software.

In addition, in this embodiment, although the case where there is one communication I/F 25 was taken as an example, this embodiment can be applied also when there are multiple communication I/Fs.
Further, in the embodiment described above, the notification processing of the buffer release notification section 261 and the notification setting section 262 of the notification section 26 uses a callback function, but other methods such as a system call of the operating system (OS) may be used. It is also possible.

<Embodiment 2>
Communication processing by the communication device of the second embodiment will be described below with reference to FIGS. 1, 2, 4, and 5. In the second embodiment, the same configurations and functions as those in the first embodiment are denoted by the same reference numerals, detailed explanation thereof will be omitted, and only the different points will be explained. The difference from the first embodiment is that the second embodiment uses UDP (User Datagram Protocol) as a communication protocol. At this time, the communication protocol processing unit 226 in FIG. 2 generates a UDP/IP header and a UDP/IP packet.

Unlike TCP/IP, UDP is a connectionless protocol that omits handshaking. In UDP data transfer, there is no guarantee of the order of transmitted and received data, and reliability is not guaranteed because there is no acknowledgment from the destination.
However, since UDP requires less cost for communication processing, it is sometimes used in streaming, where there are fewer problems even if data is dropped during the process, and in real-time system communication, which requires reduction in the overhead of communication processing. At this time, the notification setting unit 262 in FIG. 2 can set the buffer release notification to be invalid or valid depending on the type of communication interface that transmits the packet.

FIG. 5 is a flowchart showing data transmission processing of the communication device according to the second embodiment.
The processing in FIG. 5 assumes data transmission processing of multiple data using the socket API. The data transmission process for multiple data is, for example, data transmission using sendmmmsg().
The process in FIG. 5 takes as an example a case where, in a data transmission process in which a plurality of pieces of transmission data are specified at once using the socket API, a packet storage buffer release notification process is performed after the data transmission process is completed.

In the process of FIG. 5, S51 and S53 are executed instead of S21 and S23 of the process of FIG. 3, and the other processes are the same as the process of FIG.
In S51, when the communication interface is a wired LAN, the notification setting unit 262 in FIG. 2 determines whether to enable notification. The setting to disable the notification is achieved by the application 21 setting the buffer release notification unit 261 to unregister a callback function that sets a buffer release notification. The setting to disable notifications may be realized by disabling notifications when the communication interface used for transmission in a callback function is not a wired LAN. If the notification is not enabled (S51: No), the process returns to the start of the data transmission process. If the notification is set to be enabled (S51: Yes), the process advances to S22.
In S53, if the communication interface is a wired LAN, the notification setting unit 262 sets the notification to be invalid, and returns to the start of the data transmission process.

As described above, according to the present embodiment, a packet generation process that segments transmission data, generates a UDP/IP header, and converts it into an Ethernet frame is performed, and the network driver transfers the Ethernet frame to the communication I/F control unit 24. Send to. At this time, the buffer release notification unit notifies the application of the buffer release, so that the application can resume requesting transmission of data as soon as the protocol stack and network driver become ready for transmission. Therefore, even when UDP is used as the communication protocol, the packet transmission efficiency of the communication device 1 can be improved.
Further, according to the present embodiment, the efficiency of the transmission process can be improved by setting the buffer release completion notification to be enabled or disabled depending on the situation, and when the buffer release completion notification is enabled, the application receives the completion notification.
Note that the present embodiment can be applied even when the processing by the hardware of the packet generation unit 23 is executed by software.

In addition, in this embodiment, although the case where there is one communication I/F25 was taken as an example, this embodiment can be applied also when there are multiple communication I/Fs.
Furthermore, in the embodiment described above, a callback function is used for notification processing by the buffer release notification section 261 and the notification setting section 262 of the notification section 26, but other methods such as a system call of the operating system can also be used. It is.

Further, in the above-described embodiment, in the processing of S51 and S53, the communication interface is a wired LAN, but the communication interface may be a wireless LAN.
Further, the communication interface is not limited to wired LAN or wireless LAN, and whether or not to notify buffer release may be set based on the type of communication interface other than wired LAN or wireless LAN. Furthermore, it may be set whether or not to notify buffer release based on the type of protocol such as TCP and UDP.
Furthermore, in the embodiment described above, the case where "the communication interface is a wired LAN" is taken as an example in the determination condition of S51. In addition to this, it may be "any protocol", "any port number", "any connection", "any destination IP address", or "any source IP address".

<Other embodiments>

In the present invention, a program that implements one or more functions of the embodiments described above may be supplied to a system or device via a network or a storage medium. One or more functions of the above-described embodiments can also be realized by a process in which one or more processors in a computer of the system or device read and execute a program.

1: communication device, 3: communication partner device, 102: CPU, 107: data transfer unit, 108: frame generation unit, 23, 109, 234: packet generation unit, 113a: MAC module placement, 22: protocol stack, 231: Packet generation completion notification unit, 232: Data transfer unit, 260: Notification unit, 261: Buffer release notification unit, 262: Notification setting unit

Claims (12)

storage means for storing packets containing transmission data in a buffer;
a transmitting means for transmitting the packet stored in the storing means;
releasing means for releasing the buffer used to store the packet when the packet is transmitted by the transmitting means;
a setting means for setting whether to notify the release of the buffer;
When the buffer is released by the release means, the release of the buffer is notified if the setting means is set to notify , and the release of the buffer is not notified if the setting is set not to notify. notification means;
A communication device comprising: The communication device according to claim 1, further comprising generation means for generating the packet from the transmission data. 3. The communication device according to claim 2, wherein the generating means generates the packet using an offloader. 4. The communication device according to claim 3, wherein the offloader generates the packet by using a TSO (TCP Segmentation Offload) function. 5. The communication device according to claim 1, wherein the notification means notifies an application that has requested transmission of the transmission data of the release of the buffer. 6. The communication device according to claim 5, wherein the application resumes requesting the transmission of the transmission data when the notification unit notifies the release of the buffer. 7. The device according to claim 1 , wherein the setting means sets whether or not to notify the release of the buffer based on a return value of a socket API (Application Programming Interface). Communication device. 8. The setting means sets whether or not to notify the release of the buffer based on the type of communication protocol by which the transmitting means transmits the packet. The communication device described in . 9. The communication method according to claim 1 , wherein the setting means sets whether or not to notify the release of the buffer based on the type of communication interface that transmits the packet. Device. 10. The communication device according to claim 9 , wherein the type of communication interface includes a wired LAN (Local Area Network) and a wireless LAN. storing the packet containing the transmission data in a buffer;
transmitting the stored packet;
releasing the buffer used to store the packet when the packet has been transmitted;
a step of setting whether or not to notify the release of the buffer;
When the buffer is released, notifying the release of the buffer if the notification is set in the setting step , and not notifying the release of the buffer if the setting is set not to notify ;
A communication method comprising: A program for causing a computer to operate as the communication device according to any one of claims 1 to 10 .

Images