JP2007142582A - Data communication device, data communication method, program, and storage medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a data communication technology having superior flexibility and expandability. <P>SOLUTION: A data communication device comprises a universal processor for controlling the execution of a software module; a communication control processor for controlling communication; a determination section for determining whether a preset management source can process a protocol required for data communication; and a switch for changing the management source of a protocol control block generated for controlling the processing of the protocol, when the determination section determines that the management source cannot execute the processing of the protocol. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a data communication technique performed via a network.

  As a network protocol centering on the Internet, the Internet protocol (IP), the transport control protocol (TCP), etc. are used. Here, IP indicates Internet Protocol, and TCP indicates Transmission Control Protocol. A series of these protocols is called TCP / IP.

  TCP / IP is often implemented as a software module on a general-purpose processor and incorporated in an operating system. In recent years, a TOE (TCP / IP Offload Engine) has been used as a hardware module that specializes in TCP / IP protocol processing.

  The TOE is often configured as dedicated hardware or dedicated processor and firmware, but can be considered the same in terms of an alternative to software processing on a general purpose processor. There is not only TCP / IP but also hardware that handles higher-level protocol processing, but these are collectively referred to as a communication offload engine.

  When the TOE is used, a mechanism suitable for TCP / IP protocol processing such as checksum calculation is provided, so that high performance can be obtained at a relatively low cost. Furthermore, by reducing the processing load of the general-purpose processor, heavy processing such as image processing can be performed as an application, and the function of the system can be enhanced. On the other hand, in the conventional TOE, the upper limit of the number of connections may be limited in advance, or the TCP / IP parameter adjustment range may be limited. For this reason, there is a problem that flexibility and expandability are poor compared to software modules on a general-purpose processor, and as a result, the application range is limited.

Patent Document 1 discloses that a program is switched according to a connected device so that a plurality of devices having different communication protocols can be connected.
JP 7-254946 A

  That is, the conventional communication offload engine including the TOE is less flexible and expandable than the software module on the general-purpose processor. In particular, there is a problem that a complicated protocol having an internal state such as TCP cannot be used together with a software module on a general-purpose processor.

  SUMMARY OF THE INVENTION An object of the present invention is to provide a data communication technology excellent in flexibility and expandability in order to solve the above-described problems in the prior art. TCP / IP protocol processing is dynamically selected according to communication contents while using a software module on a general-purpose processor and a communication offload engine in combination. Accordingly, an object of the present invention is to provide a data communication technique that realizes selection of an optimal processing system according to communication contents while ensuring high flexibility and expandability.

In order to achieve the above object, a data communication apparatus according to the present invention provides:
A data communication apparatus having a general-purpose processor for controlling execution of a software module and a communication control processor for controlling communication,
A determination means for determining whether or not a protocol processing required in data communication is possible at a preset management source;
And switching means for switching the management source of the protocol control block generated to control the protocol processing when the processing of the protocol cannot be executed by the management source as determined by the determination means. And

Alternatively, the data communication method according to the present invention includes:
A data communication method in a data communication apparatus having a general-purpose processor for controlling execution of a software module and a communication control processor for controlling communication,
A determination step of determining whether or not a protocol process required in data communication is possible at a preset management source;
A switching step of switching the management source of the protocol control block generated to control the protocol processing when the processing of the protocol cannot be executed by the management source due to the determination of the determination step. And

  According to the present invention, it is possible to select an optimum processing system while ensuring high flexibility and expandability by selecting a general-purpose processor or a communication control processor that controls communication according to the contents of data communication. Become.

(First embodiment)
Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram showing a configuration of a data communication apparatus according to an embodiment of the present invention. A general-purpose processor (CPU) 101, an offload engine (TOE) 102 that is a dedicated communication control processor, a ROM 103, a RAM 104, and a network interface (NIC) 105 for connecting to a network 107 are connected by a bus 106.

  For example, the general-purpose processor 101 operates a general-purpose operating system such as Unix (registered trademark), and the offload engine 102 operates an embedded operating system. Both operating systems each include a software module that performs processing based on TCP / IP (TCP / IP processing). These software module groups are recorded in the ROM 103 and can operate using the RAM 104 as a work area. However, the offload engine 102 may be configured as hardware that does not include a software module. The following description can be similarly applied to the offload engine 102 configured by hardware.

  Further, the network interface 105 is not necessarily connected to the bus 106 independently, and may be integrated with the offload engine 102.

  For example, in the case of a network interface built in as standard, such as Ethernet (registered trademark), it is possible to reduce the load on the bus if it is configured integrally with the offload engine 102 including a transmission / reception buffer. On the other hand, in the case of an external connection type network interface such as a USB device or a PC card in a wireless LAN or the like, the configuration shown in FIG. 1 is often used.

  The data communication apparatus according to the present embodiment can perform data transmission and reception processing via the network 107. The data communication apparatus selects a general-purpose processor (CPU 101) that controls execution of the software module or a communication control processor (hereinafter referred to as offload engine (TOE)) 102 that controls communication according to the contents of data communication.

  Here, the data communication apparatus includes a setting unit, a determination unit, a switching unit, a specifying unit, and a comparison unit in cooperation with the general-purpose processor 101, the offload engine 102, and the software module.

  The setting unit sets either the general-purpose processor 101 or the offload engine 102 as a management source of a protocol control block (PCB) generated to control protocol processing.

  The determination unit determines whether or not processing of a protocol required in data communication is possible based on the presence / absence of a protocol control block (whether or not it is under management) in each management source.

  If it is determined by the determination unit that the protocol processing cannot be executed by the set management source, the switching unit switches the management source of the protocol control block. That is, the switching unit determines whether or not there is a protocol control block that can be processed by both the general-purpose processor 101 and the offload engine 102 (whether it should be offloaded). If offloading is possible, the management source of the protocol control block that can be processed by both is switched in order to execute processing of the protocol that cannot be executed by the management source.

  The specifying unit specifies the content of the received data processing request (HTTP request). That is, it is specified whether the data to be processed is data with a large processing capacity (for example, transmission of video data) or data with a small processing capacity (for example, control data for a camera).

  The comparison unit compares the communication load of the protocol control block with a set threshold, and issues an offload start command or an offload start command for switching the management source of the protocol control block according to the comparison result.

  FIG. 2 is a diagram schematically showing a configuration of a protocol control block (PCB) for controlling TCP / IP internal processing. An IP PCB 201, a TCP PCB 202, etc. are used corresponding to each protocol. Furthermore, in the case of performing encrypted communication using transport level security (TLS), a TLS connection PCB 203, a TLS session PCB 204, or the like is used as a higher-level PCB. A series of PCBs are created in accordance with a protocol set by an application, correlated with each other, and then referred to from a socket 205 which is an application interface.

  FIG. 3 is a diagram showing a schematic content of the TCP PCB 202. The TCP PCB 202 includes a state variable and state flag for controlling communication, a communication rate indicating a communication load, a sequence number used for transmission and reception control, and a transmission and reception window. Further, the TCP PCB 202 includes a buffer for temporarily storing data, buffer management information, flow control information such as a congestion window, and a timer used for transmission such as retransmission and delayed ACK.

  The contents of the reception buffer 301 and the transmission buffer 302 are managed by corresponding windows and sequence numbers, respectively. The contents held in other PCBs are different for each protocol. For example, the IP PCB 201 includes address information and path information, the TLS connection PCB 203 includes an encryption key and an encryption state, and the TLS session PCB 204 includes session identification information, a certificate, and an encryption algorithm.

  A structural feature regarding the PCB is that the PCB is shared by the general-purpose processor 101 and the offload engine 102, and further holds information ("management source" in FIG. 3) for identifying which is under management. It is a point. That is, the PCB (201 to 204) is a data structure held on the RAM 104. Then, the PCBs (201 to 204), or the PCBs (201 to 204) and the socket 205 refer to each other using addresses in the memory space. It is desirable that the address space of the general-purpose processor 101 and the address space of the offload engine 102 are the same.

  Whether each PCB (201 to 204) is placed under the management of the general-purpose processor 101 or the management of the offload engine 102 is set by the application.

  For example, the TCP PCB 202 includes a passive open that accepts a connection from a client as a server and an active open that establishes a connection to a server as a client. In the former case, for example, a port for HTTP is created and a connection request is received (listen), and a new PCB is created when a connection request by a SYN packet is received. If a reception port is created on the general-purpose processor 101 side, a PCB corresponding to a new connection is also created on the general-purpose processor 101 side. Conversely, if a reception port is created on the offload engine 102 side, a PCB corresponding to a new connection is also created on the offload engine 102 side. When creating a listening port from an application, it is possible to set which management is to be placed in the socket creation command. Even after the reception port is created, the management source can be switched by an offload start command or an offload stop command described later. The offload start instruction or the offload stop instruction can be applied in the same manner to a PCB created by passive open or a PCB created by active open.

  Further, when performing cipher communication by TLS, a TLS connection PCB 203 and a TLS session PCB 204 are provided as shown in FIG. For each PCB, offload start and offload end can be set individually. In other words, the management source can be set for each protocol in the socket creation command, and the management source can be switched by setting the protocol after the creation.

  FIG. 4 is a diagram illustrating a configuration example of protocol stacks of the general-purpose processor (CPU) 101 and the offload engine (TOE) 102. The general-purpose processor 101 executes an application and performs communication control via an API. The general-purpose processor 101 has protocol processing functions corresponding to TCP, user datagram protocol (UDP), and TLS handshake protocol (TLSH). On the offload engine 102 side, there are protocol processing functions corresponding to IP, TCP and UDP, and TLS record protocol (TLS R).

  In this example, protocol processing functions corresponding to TCP and UDP are incorporated in both the general-purpose processor 101 and the offload engine 102. Therefore, for TCP and UDP, the PCB management source can be switched by using an offload start command or an offload stop command.

  On the other hand, protocol processing functions corresponding to the TLS handshake protocol (TLS H) and the TLS record protocol (TLS R) are incorporated only in the general-purpose processor 101 side and the offload engine 102 side, respectively. Therefore, for these protocol processes, the management source of the PCB is determined at the time of creating the socket, and therefore the management source cannot be switched by a subsequent offload start instruction / offload stop instruction. That is, in order to apply the offload start instruction and the offload stop instruction, it is necessary to incorporate a protocol stack element having a common protocol processing function on both the general-purpose processor 101 side and the offload engine 102 side. For example, if a protocol stack element corresponding to TLS R is incorporated in both the general-purpose processor 101 and the offload engine 102, the management source of the PCB can be switched by an offload start / stop instruction.

  FIG. 5 is a flowchart showing a procedure for switching the PCB management source between the general-purpose processor 101 and the offload engine 102. An instruction to switch from the general-purpose processor 101 to the offload engine 102 is referred to as an offload start instruction. An instruction for switching from the offload engine 102 to the general-purpose processor 101 is referred to as an offload stop instruction. Since both processing procedures are the same, in the following description, an offload start instruction will be described.

  In step S500, the application sets the socket and protocol and issues an offload start command. In step S501, it is confirmed whether or not the initially set socket exists. If the socket exists (S501-YES), the process proceeds to step S502, and it is confirmed whether there is a PCB corresponding to the set protocol. In step S503, it is determined whether the PCB is under the control of the general-purpose processor 101 and a protocol stack element corresponding to the protocol set on the offload engine 102 side is incorporated (offload is possible). . If it is determined that offloading is possible, in step S504, it is deleted from the management of the general-purpose processor 101, and in step S505, it is added under the management of the offload engine 102 side, and the processing is completed.

  On the other hand, if the socket does not exist (S501-NO), the PCB does not exist (S502-NO), and the protocol stack element is not incorporated (S503-NO), error processing is performed in step S506.

  The processing contents of steps S504 and S505 are determined by the combination of the general-purpose processor 101 and the offload engine 102. In general, since the PCB structure is different between the general-purpose processor 101 side and the offload engine 102 side, it is necessary to convert the structure and perform related additional processing, for example, movement of a TCP timer. Specifically, it is only necessary to create a destination PCB by referring to the source PCB, update the cross-reference relationship between the PCBs, and then delete the source PCB. Needless to say, the packet transmission / reception process is suspended during this process.

  Next, operations of the general-purpose processor 101 and the offload engine 102 in transmission processing and reception processing will be described based on the protocol stack shown in FIG.

(Packet transmission processing)
First, a case where a packet is transmitted using TCP on the general-purpose processor 101 side will be described. When the application performs data transmission processing, the socket is searched in the operating system on the general-purpose processor 101 side, and the TCP PCB managed by the general-purpose processor 101 is taken out as the highest-level PCB. As a result, TCP on the general-purpose processor 101 side is activated, and after the transmission data is stored in the empty area of the transmission buffer, a TCP header is created.

  Next, the general-purpose processor 101 performs IP processing, which is a lower-level protocol, but the IP is not on the general-purpose processor 101 side but on the offload engine 102 side. Therefore, the offload engine 102 is requested to perform IP processing that cannot be executed by the management source (general processor 101 side) via a TCP PCB that can be processed by both the general processor 101 and the offload engine 102. The general-purpose processor 101 requests the offload engine 102 to perform transmission processing to the IP together with the TCP header and the transmission buffer. Specifically, an interrupt request is made to the offload engine 102 or writing to the control register of the offload engine 102 is performed.

  When a request for transmission processing is received by the offload engine 102, the management source of transmission processing below TCP is switched. The offload engine 102 that has received the request for the transmission process creates an IP header or the like as the IP process, and sends the packet through the communication interface.

  When a packet is transmitted using TCP on the offload engine 102 side, the uppermost PCB taken out from the socket is under the control of the offload engine 102. In this case, the TCP of the general-purpose processor 101 is not activated, and the transmission processing below the TCP is requested to the TCP of the offload engine 102 by interruption or writing to a register. The offload engine 102 performs TCP processing and IP processing, and then transmits a packet via the communication interface. During this time, the general-purpose processor 101 is not involved in any communication processing with the offload engine 102.

(Packet reception processing)
Next, packet reception processing will be described. When the network interface 105 receives the packet, the network interface 105 transfers the received data to the memory (RAM 104), and then notifies the offload engine 102 of the reception of the packet by an interrupt or the like.

  The offload engine 102 analyzes the IP header and searches for the PCB of the upper protocol. If the upper protocol PCB is on the offload engine 102 side, the upper protocol processing is performed as it is. If there is no higher-level protocol PCB on the offload engine 102 side and the general-purpose processor 101 side, the general-purpose processor 101 is requested to process the higher-level protocol by an interrupt. Thereafter, this process is repeated, and when there is no higher protocol, the received data is provided to the application using the socket.

  The above processing is directly applied to encryption communication using TLS. That is, when an application creates a TLS connection, a series of TLS handshake messages starting from ClientHello are transmitted and received. In this case, after the TLS handshake protocol (TLS H) is processed on the general-purpose processor 101 side and the TLS record protocol (TLS R) is processed on the offload engine 102 side, transmission processing below TCP is performed.

  In the above processing, the protocol processing related to the TCP internal processing is collectively managed by the general-purpose processor 101, thereby reducing the burden on the offload engine 102 and effectively using limited resources of the offload engine 102. It can also be used. For example, the TCP disconnection process is performed by exchanging FIN packets that mean “end of connection”. If the TCP PCB is under the control of the offload engine 102 when the FIN packet is transmitted or received, switching may be performed under the control of the general-purpose processor 101 regardless of the application offload start / stop command.

  In general, there is a possibility that the period until the PCB is discarded after the cutting process is started may be long. However, it is rare to perform a large amount of communication during this time, and the offload engine 102 can be concentrated on a large amount of data transmission / reception processing by handling the protocol processing on the general-purpose processor 101 side.

(Application configuration example)
As an application configuration example, an operation of a server that performs video transmission and camera control using a hypertext transfer protocol (HTTP) will be described. Here, it is assumed that TCP of the offload engine 102 is used for video transmission and TCP of the general-purpose processor 101 is used for camera control. It is assumed that HTTP processing is performed by an application operating on the operating system on the general-purpose processor 101 side, and that the HTTP port is created as a PCB on the general-purpose processor 101 side.

  When there is an HTTP connection request from the client, the connection request is processed by TCP on the general-purpose processor 101 side, an HTTP connection is established at the application level, and a new PCB is created on the general-purpose processor 101 side.

  When the HTTP connection is established, the client transmits an HTTP request. The content of the HTTP request to be transmitted is, for example, a video transmission request or a camera control request. When the HTTP request is received, the HTTP request is processed by TCP of the general-purpose processor 101 in accordance with the corresponding PCB, and then the HTTP request is notified to the application. The application specifies the content of the request (for example, video transmission request, camera control request) based on information such as a character string included in the HTTP request. If the video transmission request has a large communication load, the PCB is switched under the management of the offload engine 102 by an offload start command. Thereafter, video data transmission is processed by the offload engine 102, and camera control is processed by the general-purpose processor 101.

  However, generation of video data and supply to the offload engine 102, analysis of a camera control request, generation of a camera control command, and the like are performed by using separately known means.

  In the above description, it goes without saying that the same can be applied to a server that performs video transmission and camera control using a protocol other than HTTP.

  Furthermore, in the above description, in addition to the protocol type and processing contents, for example, when using a peer-to-peer method as a communication form, a PCB management source may be selected based on the communication form. Peer-to-peer is often used in a small-scale LAN environment, and efficiency may be improved because direct communication is performed without using a server. When the peer-to-peer method is used, the PCB management source may be fixed to the offload engine 102.

  The PCB management source is controlled by an offload start command and an offload stop command issued by the application, but it is also possible to control the management source to be automatically switched according to the communication load status.

  FIG. 6 is a diagram showing a list of PCBs arranged in order of communication load (communication rate). In each PCB, the communication amount per unit time is recorded as a communication rate together with the management source (see FIG. 3). The communication rate is updated each time communication is performed using the PCB, and rearrangement is performed when the value is reversed from the previous and subsequent PCBs. Further, the PCB at the head of the list is held in the RAM 104 as the PCB with the maximum load, and the PCB at the end as the PCB with the minimum load.

  FIG. 7 is a flowchart showing a procedure for automatically switching the PCB management source in accordance with the communication load (communication rate). This processing procedure is started when the value of the communication rate is changed, or is periodically started using a timer.

  In step S701, the target PCB is the PCB with the maximum load. In step S702, the PCB communication rate is compared with a predetermined threshold value 1. If the communication rate exceeds the threshold 1 (S702-YES), it is confirmed in step S703 whether the management source is the general-purpose processor (CPU) 101. If the management source is the general-purpose processor 101 (S703-YES), the management source is switched to the offload engine 102 at the start of offload in step S704.

  In step S705, the PCB having the next highest communication rate is taken out. If it is determined in step S706 that there is no PCB (S706-YES), the process is terminated. On the other hand, if there is a PCB (S706-NO), the process returns to step S702, and the processes after step S702 are repeated.

  If the communication rate is equal to or lower than the threshold value 1 in step S702 (S702-NO), the process proceeds to step S707 and is compared with another threshold value 2. Here, the threshold value 2 is a value equal to or less than the threshold value 1.

  If it is determined in step S707 that the PCB communication rate is not less than or equal to the threshold 2 (S707-NO), the process proceeds to step S710, and the PCB having the next highest communication rate is taken out. On the other hand, if the PCB communication rate is equal to or less than the threshold 2 (S707—YES), it is confirmed whether the management source is the offload engine 102 (step S708). If the management source is an offload engine (S708-YES), the management source is switched to the general-purpose processor 101 by stopping the offload (step S709). Subsequently, in step S710, a PCB having the next highest communication rate is taken out. If there is a PCB with the next highest communication rate (S711-NO), the process returns to step S707, and the processes after step S707 are repeated. If it is determined in step S711 that there is no PC (S711-YES), the process ends.

  As described above, according to the present embodiment, by selecting a general-purpose processor or a communication control processor that controls communication in accordance with the contents of data communication, it is possible to achieve an optimum while ensuring high flexibility and expandability. The processing system can be selected.

(Other embodiments)
Needless to say, the object of the present invention can also be achieved by supplying a storage medium storing software program codes for realizing the functions of the above-described embodiments to a system or apparatus. Needless to say, this can also be achieved by the computer (or CPU or MPU) of the system or apparatus reading and executing the program code stored in the storage medium.

  In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the storage medium storing the program code constitutes the present invention.

  As a storage medium for supplying the program code, for example, a flexible disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a nonvolatile memory card, a ROM, or the like can be used.

  Further, the functions of the above-described embodiment are realized by executing the program code read by the computer. In addition, an OS (operating system) running on a computer performs part or all of actual processing based on an instruction of a program code, and the above-described embodiment is realized by the processing. Needless to say.

It is a block diagram which shows the structure of the data communication apparatus which concerns on embodiment of this invention. It is a figure which shows typically the structure of a protocol control block. It is a figure which shows the content of the protocol control block of TCP. It is a figure which shows the structural example of a protocol stack. It is a flowchart which shows the process sequence of an offload start command. It is a figure which shows the list of the protocol control block arranged in order of the communication rate. It is a flowchart which shows the procedure which controls automatically the management origin of a protocol control block according to communication load.

Claims (12)

A data communication apparatus having a general-purpose processor for controlling execution of a software module and a communication control processor for controlling communication,
A determination means for determining whether or not a protocol processing required in data communication is possible at a preset management source;
And switching means for switching the management source of the protocol control block generated to control the protocol processing when the processing of the protocol cannot be executed by the management source as determined by the determination means. A data communication device. The protocol includes at least one of a transport control protocol, an internet protocol, a transport level security handshake protocol, a transport level security record protocol, and a user datagram protocol. The data communication apparatus according to claim 1, wherein: Further comprising a specifying means for specifying the content of the received data processing request;
2. The data communication apparatus according to claim 1, wherein a management source of the protocol control block is preset based on a processing capacity of data to be processed based on a specifying result of the specifying unit. When the protocol control block for the transport control protocol disconnects the protocol processing in the management source of the communication control processor by sending or receiving the FIN packet, the switching means sends the management source to the general-purpose processor. The data communication device according to claim 1, wherein the data communication device is switched. Comparing means for comparing the communication load of the protocol control block with a set threshold and issuing a command for switching the management source of the protocol control block based on a result of the comparison,
2. The data communication apparatus according to claim 1, wherein the switching unit switches a management source of the protocol control block in accordance with an instruction issued by the comparison unit. A data communication method in a data communication apparatus having a general-purpose processor for controlling execution of a software module and a communication control processor for controlling communication,
A determination step of determining whether or not a protocol process required in data communication is possible at a preset management source;
A switching step of switching the management source of the protocol control block generated to control the protocol processing when the processing of the protocol cannot be executed by the management source due to the determination of the determination step. Data communication method. The protocol includes at least one of a transport control protocol, an internet protocol, a transport level security handshake protocol, a transport level security record protocol, and a user datagram protocol. The data communication method according to claim 6, wherein: A specific step of specifying the content of the received data processing request;
7. The data communication method according to claim 6, wherein a management source of the protocol control block is preset according to a processing capacity of data to be processed. When the protocol control block for the transport control protocol cuts off the protocol processing in the management source of the communication control processor by sending or receiving the FIN packet, the switching step sends the management source to the general-purpose processor. The data communication method according to claim 6, wherein the data communication is switched. A comparison step of comparing a communication load of the protocol control block with a set threshold value and issuing an instruction to switch a management source of the protocol control block based on a result of the comparison;
7. The data communication method according to claim 6, wherein the switching step switches a management source of the protocol control block in accordance with an instruction issued by the comparison step. A program for causing a computer to execute the data communication method according to any one of claims 6 to 10. A computer-readable storage medium storing the program according to claim 11.

Images