WO2011033562A1 - 通信装置 - Google Patents

通信装置 Download PDF

Info

Publication number
WO2011033562A1
WO2011033562A1 PCT/JP2009/004651 JP2009004651W WO2011033562A1 WO 2011033562 A1 WO2011033562 A1 WO 2011033562A1 JP 2009004651 W JP2009004651 W JP 2009004651W WO 2011033562 A1 WO2011033562 A1 WO 2011033562A1
Authority
WO
WIPO (PCT)
Prior art keywords
protocol processing
processing unit
hardware
software
protocol
Prior art date
Application number
PCT/JP2009/004651
Other languages
English (en)
French (fr)
Inventor
山浦隆博
田中信吾
Original Assignee
株式会社 東芝
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社 東芝 filed Critical 株式会社 東芝
Priority to JP2011531639A priority Critical patent/JP5481485B2/ja
Priority to PCT/JP2009/004651 priority patent/WO2011033562A1/ja
Publication of WO2011033562A1 publication Critical patent/WO2011033562A1/ja
Priority to US13/422,587 priority patent/US8943214B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0038—System on Chip

Definitions

  • the present invention relates to a communication device.
  • Protocol processing such as TCP / IP (Transmission Control Protocol / Internet Protocol), which is widely used in the Internet, etc., has been realized by software that mainly operates on CPU (Central Processing Unit).
  • CPU Central Processing Unit
  • the present invention has been made to solve the above problems, and an object of the present invention is to provide a communication device that can improve communication throughput.
  • a communication device is realized by a hardware protocol processing unit that performs hardware protocol processing on a received data frame, and hardware different from the hardware protocol processing unit, and the received data frame Includes a software protocol processing unit for performing protocol processing by software, information indicating a part of processing completed by the protocol processing by the hardware protocol processing unit, and a value obtained by protocol processing by the hardware protocol processing unit
  • a hardware protocol processing information generation unit that generates protocol processing information, and a protocol process that has not been completed in the hardware protocol processing unit is performed on the software protocol processing unit by using the protocol processing information. Characterized by comprising a that software protocol processing resumption unit.
  • FIG. 1 is a block diagram showing a communication apparatus according to Embodiment 1 of the present invention.
  • 1 is a flowchart showing reception processing of a communication apparatus according to Embodiment 1 of the present invention.
  • 3 is a flowchart showing transmission processing of the communication apparatus according to the first embodiment of the present invention.
  • 1 is a block diagram showing a communication apparatus that speeds up UDP reception according to Embodiment 1 of the present invention.
  • FIG. 1 is a block diagram showing a communication apparatus that speeds up UDP transmission according to Embodiment 1 of the present invention.
  • the block diagram which shows the communication apparatus which concerns on Example 2 of this invention.
  • 9 is a flowchart showing UDP reception processing according to Embodiment 2 of the present invention.
  • 9 is a flowchart showing TCP reception processing according to Embodiment 2 of the present invention.
  • 7 is a flowchart showing TCP transmission processing according to Embodiment 2 of the present invention.
  • FIG. 1 is a block diagram illustrating a communication apparatus.
  • FIG. 2 is a diagram illustrating the configuration of an Ethernet (R) frame.
  • FIG. 3 is a diagram illustrating the configuration of the IP header.
  • FIG. 4 is a diagram showing the structure of the UDP header.
  • a hardware protocol processing information generation unit and a software protocol information resumption unit are provided on the receiving side.
  • a software protocol processing information generation unit and a hardware protocol processing resumption unit are provided on the transmission side.
  • the communication device 80 is connected to the network 70 by Ethernet (R).
  • the communication device 80 has a function of reading video information from a disk device (Hard Disk Drive, etc.) and transmitting it to a client device connected to the network 70 by UDP (User Datagram Protocol). In addition, it has a function of saving video information received from the client device via UDP in the disk device.
  • the communication device 80 includes a hardware processing unit 1 realized by an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), and the like, and a software processing unit 2 that performs processing by software operating on the CPU. The That is, the hardware processing unit 1 and the software processing unit 2 are configured with different processing functions.
  • the hardware processing unit 1 is provided with a network controller 11, a hardware protocol processing unit 12, a hardware protocol processing information generating unit 13, and a hardware protocol processing resuming unit 14.
  • the network controller 11 When the network controller 11 receives the Ethernet (R) frame from the network 70, the network controller 11 performs processing of the Ethernet (R) physical layer and processing of a part of the Ethernet (R) data link layer. Specifically, a signal defined by the Ethernet (R) standard is demodulated, and the Ethernet (R) frame shown in FIG. 2 is extracted.
  • the Ethernet (R) frame includes an end point MAC (Media Access Control) address 111, a start point MAC (Media Access Control) address 112, a type 113, data 114, and an FCS (Frame Check Sequence) 115.
  • FCS Flash Check Sequence
  • the end point MAC address 111 is also called a destination address
  • the start point MAC address 112 is also called a source address.
  • the end point MAC address 111 is 6 octets (48 bits)
  • the start point MAC address 112 is 6 octets (48 bits)
  • the type 113 is 2 octets (16 bits)
  • the data 114 is 46 to 1500 octets
  • FCS Framework (Frame Check Sequence) 115 is composed of 4 octets (32 bits).
  • Type 113 includes IP (Internet Protocol), ARP (Address Resolution Protocol), and RARP (Reverse Address Resolution Protocol).
  • the network controller 11 adds FCS to the transmission information processed by the hardware protocol processing unit 12, performs frame modulation, and transmits it to the network 70.
  • the hardware protocol processing unit 12 includes an Ethernet® processing unit 15, an IPv4 (Internet Protocol version 4) processing unit 16, and a UDP processing unit 17.
  • the hardware protocol processing unit 12 executes hardware protocol processing during reception and transmission.
  • the Ethernet (R) processing unit 15 performs a part of the data link layer of Ethernet (R).
  • the IPv4 processing unit 16 processes the IPv4 header shown in FIG.
  • the IPv4 header (IP header) is version 211, header length 212, service type 213, IP packet length 214, identifier 215, control flag 216, fragment offset 217, lifetime 218, protocol number 219, header chuck sum 220, start point IP It consists of an address 221 and an end point IP address 222.
  • version 211 is 4 bits
  • header length 212 is 4 bits
  • service type 213 is 8 bits
  • IP packet length 214 is 16 bits
  • identifier 215 is 16 bits
  • control flag 216 is 3 bits
  • fragment offset 217 is 13 bits
  • lifetime 218 is 8 bits
  • protocol The number 219 is 8 bits
  • the header chuck sum 220 is 16 bits
  • the start point IP address 221 is 32 bits
  • the end point IP address 222 is 32 bits.
  • Protocol numbers 219 include ICMP (Internet Control Message Protocol), TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and DCCP (Datagram Congestion Control Protocol).
  • the UDP processing unit 17 processes the UDP header shown in FIG.
  • the UDP header includes a start port number 311, an end port number 312, a UDP packet length 313, and a UDP checksum 314.
  • the start port number 311 is 16 bits
  • the end port number 312 is 16 bits
  • the UDP packet length 313 is 16 bits
  • the UDP checksum 314 is 16 bits.
  • the hardware protocol processing information generation unit 13 generates protocol processing information from the processing result of the hardware protocol processing unit 12 when receiving.
  • the protocol processing information is output to the software processing unit 2.
  • the hardware protocol process resuming unit 14 receives the protocol processing information generated by the software protocol processing information generating unit 24 at the time of transmission.
  • the hardware protocol processing unit 12 that has received the protocol processing information from the hardware protocol processing resuming unit 14 performs protocol processing by hardware.
  • the software processing unit 2 includes an application 21, a software protocol processing unit 22, a software protocol processing restarting unit 23, and a software protocol processing information generating unit 24.
  • the software protocol processing unit 22 executes protocol processing by software at the time of reception and transmission.
  • the software protocol processing unit 22 includes an ARP (Address Resolution Protocol) processing unit 25, an IPv6 (Internet Protocol version 6) processing unit 26, an ICMPv4 (Internet Control Message Protocol version 4) processing unit 27, and a DCCP (Datagram Congestion Control Protocol).
  • a processing unit 28 is provided.
  • the ARP processing unit 25 performs ARP processing.
  • the IPv6 processing unit 26 performs IPv6 processing.
  • the DCCP processing unit 28 performs DCCP processing.
  • the software protocol processing resuming unit 23 receives the protocol processing information generated by the hardware protocol processing information generating unit 13 and controls the software protocol processing unit 22 when receiving.
  • the software protocol processing information generation unit 24 generates protocol processing information from the processing result of the software protocol processing unit 22 at the time of transmission.
  • the protocol processing information is output to the hardware protocol processing resuming unit 14.
  • the hardware protocol processing restarting unit 14 controls the hardware protocol processing unit 12 based on the received protocol processing information.
  • the application 21 controls to read transmission data such as video information from a disk device (not shown) during transmission.
  • the application 21 also has a function of saving received data such as video information in the disk device at the time of reception.
  • FIG. 5 is a flowchart showing the reception processing procedure of the communication apparatus.
  • FIG. 6 is a flowchart illustrating a transmission processing procedure of the communication apparatus.
  • the reception processing of the communication device 80 will be described with reference to FIG. First, data transmitted from the network 70 is input to the network controller 11.
  • the network controller 11 performs processing of the physical layer of Ethernet (R) and processing of a part of the data link layer of Ethernet (R). Specifically, the received signal specified by the Ethernet (R) standard is demodulated, and an Ethernet (R) frame (see FIG. 2) is taken out. Then, a verification process is performed using the FCS 115 to verify whether the frame is damaged. When a broken Ethernet (R) frame is detected, the frame is discarded (step S11).
  • the IPv4 processing unit 16 processes the IPv4 header (see FIG. 3). Since the Ethernet (R) type 113 may be IP or IPv6, if the value of the version 211 is “6”, the processing in the hardware protocol processing unit 12 ends. Then, along with the result obtained by the Ethernet (R) processing unit 15, the hardware protocol processing information generation unit 13 is notified that the protocol of the network layer is IPv6. If the value of the version 211 is “4”, the IPv4 processing unit 16 verifies the header length 212 and the IP packet length 214 and verifies the header checksum 220. If the IP packet is fragmented, defragment processing is performed.
  • the UDP processing unit 17 performs processing of the UDP header (see FIG. 4).
  • the UDP processing unit 17 verifies the UDP packet length 313, calculates the UDP checksum 314 of the payload, and verifies whether there is data corruption. When data corruption is detected, the payload is discarded and the process ends.
  • the hardware protocol processing unit 12 determines whether all protocol processing by hardware processing is completed (step S13).
  • the hardware protocol processing unit 12 sends to the hardware protocol processing information generation unit 13.
  • the destination type, upper layer protocol type, and data 114 are notified as a protocol processing result.
  • the hardware protocol processing unit 12 sends the start point IP address 221, end point IP address 222, IP to the hardware protocol processing information generation unit 13.
  • the packet length 214, payload, etc. are notified.
  • the hardware protocol processing information generation unit 13 generates protocol information from the notified information (step S14).
  • the hardware protocol processing information generating unit 13 transmits the generated protocol information to the software protocol processing resuming unit 23.
  • the software protocol process resuming unit 23 determines a start part of protocol processing (ARP, DCCP, ICMPv4) in software (step S15).
  • the software protocol processing unit 22 instructed to start the protocol processing by software executes the protocol processing not processed by the hardware protocol processing unit 12 (step S16).
  • the hardware protocol processing unit 12 performs Ethernet (R) processing, so analyze the ARP header and update the ARP cache and send ARP response if necessary. Do.
  • Ethernet (R) processing and IPv4 processing are performed by the hardware protocol processing unit 12, and thus DCCP protocol processing and ICMPv4 processing are performed.
  • the software protocol processing unit 22 determines whether there is data such as video information to be processed. If it is determined that there is no data to be processed, the reception process ends (step S17). On the other hand, if it is determined that there is data to be processed, the application 21 executes a process of storing the received data in the disk device (step S18). When the received Ethernet® frame completes the protocol processing of the hardware protocol processing unit 12, the application 21 performs processing for storing data such as video information in the disk device.
  • the received Ethernet (R) frame includes a protocol (ARP, DCCP, ICMPv4, etc.) that cannot be processed by the hardware protocol processing unit 12, it is obtained from the processing result of the hardware protocol processing unit 12.
  • the protocol processing information is notified to the software protocol processing unit 22.
  • the software protocol processing unit 22 finishes the protocol processing by software, if there is data to be passed to the application, the software protocol processing unit 22 passes the data to the application 21, and the application 21 stores received data such as video information in the disk device.
  • the protocol processing information described above includes information that the hardware protocol processing unit 12 has completed the protocol processing, a value obtained by the protocol processing, and the like. Therefore, the software protocol processing unit 22 does not process a protocol that has already been processed by the hardware protocol processing unit 12 and processes a protocol that could not be processed.
  • the transmission process when the software protocol processing unit 22 performs transmission, for example, there are the following three cases.
  • the first is a case in which a response packet is transmitted when ARP or ICMPv4 is processed by the reception process described above.
  • the second is a case where an ARP request packet is actively transmitted in order to know the other party's MAC address.
  • the case of data transmission by the application 21 or the software protocol processing unit 22 will be described as an example.
  • the transmission processing of the communication device 80 will be described with reference to FIG. First, data such as video information is read from the disk device by the application 21.
  • the application 21 includes UDP start port number 311, end port number 312, UDP packet length 313, IP version 211, service type 213, IP packet length 214, identifier 215, control flag 216, necessary for performing protocol processing.
  • a survival time 218, a start point IP address 221, an end point IP address 222, an Ethernet (R) start point MAC address 112, an end point MAC address 111, and a network MTU (Maximum Transmission Unit) are generated.
  • the protocol processing information is notified to the software protocol processing unit 22.
  • the software protocol processing unit 22 determines whether or not all the protocol processes to be transmitted can be processed by the hardware protocol processing unit 12 (step S21).
  • the software protocol processing unit 22 determines the ICMPv4 echo response packet. Perform the generation process.
  • the software protocol processing unit 22 generates and transmits an ARP response packet when an ARP request packet is received. If the value in the protocol processing information is not specified by the application 21, a fixed value held by the software protocol processing unit 22 may be set and included in the protocol processing information, or an ARP request packet may be transmitted. Then, the result of active resolution may be used (step S22).
  • the software protocol processing information generation unit 24 includes information indicating that protocol processing higher than IPv4 has been completed, a start IP address 221, an end point IP address 222, a protocol number 219, Ethernet ( R) Protocol processing information including a start point MAC address 112, an end point MAC address 111, a payload, and a length of the payload necessary for processing is generated.
  • the software protocol processing information generation unit 24 stores information indicating that the protocol processing up to the start point MAC address 112, the end point MAC address 111, the type 113, and the ARP necessary for processing of the lower layer Ethernet (R) is completed. It is generated as protocol processing information (step S23).
  • the software protocol processing information generating unit 24 transmits the generated protocol processing information to the hardware protocol processing resuming unit 14.
  • the hardware protocol process resuming unit 14 determines the start of the protocol process in hardware (step S24).
  • the UDP processing unit 17 adds the notified protocol processing information.
  • the included values are set in the UDP header start port number 311, end port number 312, and UDP packet length 313. Also, the UDP processing unit 17 calculates a UDP checksum 314 from the header and data, and creates a UDP header.
  • the IPv4 processing unit 16 performs fragment processing as necessary, and sets values of the identifier 215, the control flag 216, and the fragment offset 217 for each packet. Also, a value other than the header checksum 220 of the IP header is set. Finally, the header checksum 220 is calculated and a value is set in the checksum field.
  • the Ethernet (R) processing unit 15 sets the start point MAC address 112, the end point MAC address 111, and the type 113 of the Ethernet (R) frame.
  • the Ethernet (R) processing unit 15 performs Ethernet (R) protocol processing (step S25).
  • the network controller 11 adds the FCS 115 to the Ethernet (R) frame and transmits the modulated Ethernet (R) frame to the network 70 (step S26).
  • the software protocol processing unit 22 determines whether or not all the protocol processes to be transmitted can be processed by the hardware protocol processing unit 12. When it is determined that all can be processed, the transmission data is output from the hardware protocol processing unit 12 to the network controller 11. The network controller 11 transmits the data to the transmission destination device via the network 70.
  • the software protocol processing unit 22 performs transmission protocol processing. Further, the software protocol processing information generating unit 24 generates protocol processing information, and these protocol processing information is transmitted to the hardware protocol processing unit 12 via the hardware protocol processing resuming unit 14. At this time, the protocol processing information includes information indicating a part where the protocol processing is completed in the software protocol processing unit 22, a value obtained by the protocol processing, and the like.
  • the hardware protocol processing unit 12 only protocols that could not be processed by the software protocol processing unit 22 are processed. For example, when the frame to be transmitted is ARP, the hardware protocol processing unit 12 can perform Ethernet (R) processing. Therefore, the software protocol processing unit 22 performs only ARP processing, and the hardware protocol processing unit 12 Perform Ethernet (R) processing with.
  • the hardware protocol processing unit 12 can perform Ethernet (R) and IPv4 processing. Therefore, the software protocol processing unit 22 performs only DCCP or ICMPv4 processing, and the hardware protocol. The processing unit 12 performs IPv4 and Ethernet (R) processing.
  • FIG. 7 shows a first modification of the first embodiment.
  • the communication device 80a of the first modified example is provided with a hardware processing unit 1a and a software processing unit 2a.
  • the hardware processing unit 1a includes a network controller 11a, a hardware protocol processing unit 12a, and a hardware protocol processing information generation unit 13a.
  • the hardware protocol processing unit 12a is provided with an Ethernet® reception processing unit 15a, an IPv4 reception processing unit 16a, and a UDP reception processing unit 17a.
  • the software processing unit 2a includes an application 21a, a software protocol processing unit 22a, a software protocol processing resuming unit 23a, and a software protocol processing unit 30.
  • the software protocol processing unit 22a includes an ARP processing unit 25a, an IPv6 processing unit 26a, an ICMPv4 processing unit 27a, and a DCCP processing unit 28a.
  • the software protocol processing unit 30 is provided with an IPv4 transmission processing unit 31 and an Ethernet (R) transmission processing unit 32.
  • the communication device 80a is provided with a hardware protocol processing information generating unit 13a and a software protocol information resuming unit 23a corresponding to reception.
  • a software protocol processing unit 30 corresponding to transmission is provided in the software processing unit 2a of the communication device 80a.
  • the communication device 80a can speed up the UDP reception process.
  • the received data is sequentially transferred to the network controller 11a, hardware protocol processing unit 12a, hardware protocol processing information generating unit 13a, software protocol processing resuming unit 23a, software protocol processing unit 22a, and application 21a.
  • the transmission data is sequentially transferred to the application 21a, software protocol processing unit 22a, software protocol processing unit 30, and network controller 11a.
  • the software protocol processing unit 22a and the software protocol processing unit 30 may be processed by the same CPU, or may be processed by different processors.
  • FIG. 8 shows a second modification of the first embodiment.
  • the communication device 80b of the second modification is provided with a hardware processing unit 1b and a software processing unit 2b.
  • the hardware processing unit 1b is provided with a network controller 11b, a hardware protocol processing unit 12b, and a hardware protocol processing restart 14b.
  • the hardware protocol processing unit 12b is provided with an Ethernet® transmission processing unit 15b, an IPv4 transmission processing unit 16b, and a UDP transmission processing unit 17b.
  • the software processing unit 2b includes an application 21b, a software protocol processing unit 22b, a software protocol processing information generation unit 24b, and a software protocol processing unit 40.
  • the software protocol processing unit 22b includes an ARP processing unit 25b, an IPv6 processing unit 26b, an ICMPv4 processing unit 27b, and a DCCP processing unit 28b.
  • the software protocol processing unit 40 is provided with an IPv4 reception processing unit 41 and an Ethernet (R) reception processing unit 42.
  • the communication device 80b is provided with a software protocol processing information generating unit 24b and a hardware protocol information resuming unit 14b corresponding to transmission.
  • a software protocol processing unit 40 corresponding to reception is provided in the software processing unit 2b of the communication device 80b.
  • the UDP transmission processing can be speeded up.
  • the transmission data is sequentially transferred to the application 21b, the software protocol processing unit 22b, the software protocol processing information generation unit 24b, the hardware protocol processing resuming unit 14b, the hardware protocol processing unit 12b, and the network controller 11b.
  • the received data is sequentially transferred to the network controller 11b, software protocol processing unit 40, software protocol processing unit 22b, and application 21b.
  • the software protocol processing unit 22b and the software protocol processing unit 40 may be processed by the same CPU, or may be processed by different processors.
  • the communication apparatus performs a protocol process that can be processed by the hardware protocol processing unit 12 in the case of a frame that cannot be processed by the hardware protocol processing unit 12, and a software protocol processing unit. 22 is configured to perform upper layer protocol processing.
  • protocol processing that can be processed by the software protocol processing unit 22 is performed, and lower layer protocol processing is performed by the hardware protocol processing unit 12. Therefore, even when all the protocol processing can be performed by the hardware protocol processing unit 12 at the time of reception and transmission, and when only a part of the processing can be performed by the hardware protocol processing unit 12, the protocol is as fast as possible. Processing can be executed. Therefore, the transmission / reception throughput of the communication device 80 can be significantly improved.
  • Ethernet (R) processing and IPv4 processing are processed by the hardware protocol processing unit 12, and the software protocol processing unit 22 does not need to have an Ethernet (R) processing unit and an IPv4 processing unit, thereby reducing the size of the software. can do.
  • hardware protocol processing and software protocol processing can be appropriately divided.
  • the physical layer and the data link layer are Ethernet (R), but may be a standard defined by IEEE802.11.
  • the hardware protocol processing unit 12 may be provided with a control frame processing unit and a data frame processing unit.
  • a management frame processing unit may be provided in the software protocol processing unit 22.
  • the hardware protocol processing unit 12 and the software protocol processing unit 22 are assigned on a protocol basis.
  • the software protocol processing unit 22 may be provided with, for example, an IPv4 fragment and defragment processing unit, which is limited to this by notifying the incomplete portion by the protocol processing information.
  • Other processing units may be provided in the hardware protocol processing unit 12.
  • Protocols implemented in the hardware protocol processing unit 12 include HTTP (Hypertext Transfer Protocol), TCP (Transmission Control Protocol), RTP (Real-time Transport Protocol), IP sec (Security Architecture for Internet Protocol), SCTP (Stream Other protocols such as Control (Transmission Protocol) and DCCP may be used.
  • HTTP Hypertext Transfer Protocol
  • TCP Transmission Control Protocol
  • RTP Real-time Transport Protocol
  • IP sec Serial-time Transport Protocol
  • SCTP Stream Other protocols such as Control (Transmission Protocol) and DCCP may be used.
  • protocol processing information when the protocol processing information is generated, a fixed value is held in the software protocol processing unit 22, but it may be held in the hardware protocol processing unit 12.
  • FIG. 9 is a block diagram showing the communication apparatus.
  • FIG. 10 is a diagram showing the configuration of the TCP header.
  • FIG. 11 is a diagram illustrating a TCP session state.
  • This embodiment is different from the first embodiment in that the socket information transmission unit 19 is provided between the hardware protocol processing unit 12c and the software protocol processing unit 22c. Therefore, the same components as those in the first embodiment are denoted by the same reference numerals, description thereof is omitted, and only different portions are described.
  • a TCP data processing unit 18 is newly provided in the hardware protocol processing unit 12c.
  • the software protocol processing unit 22c is newly provided with a TCP control processing unit 29. Note that the IPv6 processing unit is removed from the software protocol processing unit 22c.
  • the communication device 81 receives video data from a device provided on the network 70 by TCP and stores it in a disk device (not shown), and reads the video data from the disk device and transfers the data to a device provided on the network 70 by TCP. It has a function to transmit.
  • the socket information transmission unit 19 transmits the socket information to the application 21, the hardware protocol processing unit 12c, and the software protocol processing unit 22c.
  • socket information is created when a port is opened for UDP transmission or reception. Also, socket information is created when a port is opened to send or receive TCP.
  • the socket information is set on a memory (not shown) that can be referred to from the hardware protocol processing unit 12c and the software protocol processing unit 22c.
  • the socket information is different for each protocol.
  • the IP address of the device the IP address of the partner device, the port number of the device, the port number of the partner device, the session status, the address and length of the transmission buffer specified by the application, and the application specification Stores values such as the address and length of the receive buffer, IP service type, lifetime, MTU, MAC address of the device, and MAC address of the partner device.
  • the UDP session state is either open or closed.
  • FIG. 10 shows an example of a TCP header.
  • the TCP header includes, for example, a start port number 411, an end port number 412, a sequence number 413, an acknowledgment number 414, a data offset 415, an unused (reserved) 416, a control flag 417, a window size 418, a TCP checksum 419, and an emergency It consists of a pointer 420.
  • the start port number 411 is 16 bits
  • the end port number 412 is 16 bits
  • the sequence number 413 is 32 bits
  • the confirmation response number 414 is 32 bits
  • the data offset 415 is 4 bits
  • the unused (reserved) 416 is 6 bits
  • the control flag 417 is 6 bits
  • the window size 418 is 16 bits
  • the TCP checksum 419 is 16 bits
  • the emergency pointer 420 is 16 bits. It should be noted that an option or a padding portion having a variable length in units of 32 bits is arbitrarily provided.
  • the control flag 417 includes URG (Urgent), ACK (Acknowledge), PSH (Push), RST (Reset), SYN (Synchronize), and FIN (Finish).
  • the IP address of the Switch For TCP session information, the IP address of the Switch, the IP address of the partner, the port number of the Switch, the port number of the partner, the session status, the address and length of the transmission buffer specified by the application, and the specification of the application Address and length of the receiving buffer, IP service type, lifetime, MTU, MAC address of this device, MAC address of the other device, sequence number sent but not acknowledged (SND.UNA), and then sent Sequence number (SND.NXT), send window size (SND.WND), segment sequence number used for the latest window update (SND.WL1), segment confirmation number used for the latest window update (SND .WL2), a sequence number (RCV.NXT) to be received next, a reception window size (RCV.WND), and the like are set.
  • TCP socket information values are updated by the hardware protocol processing unit 12c or the software protocol processing unit 22c at the time of segment transmission or segment reception.
  • Fig. 11 shows the session state of TCP.
  • TCP session states include LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLIHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and CLOSED.
  • FIG. 12 is a flowchart showing the UDP reception process.
  • FIG. 13 is a flowchart showing TCP reception processing.
  • FIG. 14 is a flowchart showing TCP transmission processing.
  • the network controller 11 receives an Ethernet (R) frame transmitted from the network 70. Then, the network controller 11 operates the hardware protocol processing unit 12c to perform protocol processing. That is, the UDP processing unit 17 processes the UDP header, and calculates the UDP packet length 313 and the UDP checksum 314 of the payload. Further, the UDP processing unit 17 verifies whether or not there is data corruption. If it is detected that the data is corrupted, the payload is discarded and the process is terminated (step S31). Next, the hardware protocol processing unit 12c determines whether or not the session state of the socket information is open (step S32).
  • the hardware protocol processing information generation unit 13 When it is determined that the session state of the socket information is the “closed” state, the hardware protocol processing information generation unit 13 generates protocol processing information for transmitting the ICMP port unreachable (step S33). This protocol processing information is transmitted to the software protocol processing resuming unit 23.
  • the software protocol process resuming unit 23 determines the start of protocol processing in software and notifies the software protocol processing unit 22c (step S34).
  • the ICMPv4 processing unit 27 of the software protocol processing unit 22c creates a port unreachable packet and transmits it to the application 21 (step S35).
  • the hardware protocol processing unit 12c determines whether there is received data to be processed by the application 21 (step S36). If it is determined that there is no reception data to be processed by the application 21, the reception process ends.
  • the UDP processing unit 17 When it is determined that there is received data to be processed by the application 21, the UDP processing unit 17 writes the received data in the reception buffer of the application 21 specified by the socket information, stores the video data in the disk device, and performs processing. Is finished (step S37).
  • TCP reception processing of the communication device 81 will be described with reference to FIG.
  • the TCP data processing unit 18 executes the following TCP reception processing. (1) If the session state of the socket information is “ESTABLISHED”, a part of the TCP header is processed. (2) TCP segment checksum verification and data rearrangement in order of sequence number. (3) Write the payload into the reception buffer of the application 21 obtained from the socket information. (4) If the ACK bit of the TCP segment control flag 417 is set, the acknowledged internal transmission buffer is released. (5) When a TCP segment is received, a transmission process for an acknowledgment segment to be transmitted is performed (step S41).
  • the IPv4 processing unit 16 and the Ethernet (R) processing unit 15 of the hardware protocol processing unit 12c perform respective transmission processes.
  • the acknowledgment segment is transmitted to the client device connected to the network 11 via the network controller 11.
  • the TCP data processing unit 18 determines whether FIN, SYN, or RST is set in the control flag 417 of the TCP segment (see the control flag table in FIG. 10) (step S42). ).
  • the hardware protocol processing information generation unit 13 If it is determined that FIN, SYN, or RST is set, the hardware protocol processing information generation unit 13 generates protocol processing information (step S43). This protocol processing information is transmitted from the hardware protocol processing information generating unit 13 to the software protocol processing resuming unit 23.
  • the software protocol processing resuming unit 23 instructs the software protocol processing unit 22c to start the protocol processing with software (step S44).
  • the TCP control processing unit 29 of the software protocol processing unit 22c performs TCP control processing (step S45).
  • the TCP control processing unit 29 performs bit processing of the TCP control flag according to, for example, RFC793.
  • the software protocol processing unit 22c determines whether there is received data to be processed by the application 21 (step S46). If it is determined that there is no reception data to be processed, the reception process is terminated.
  • the TCP data processing unit 18 When there is received data to be processed, the TCP data processing unit 18 writes in the reception buffer of the application 21 specified by the socket information, and the application 21 executes an operation of storing the received data in the disk device (step S47).
  • the application 21 sets socket information necessary for performing protocol processing, such as the address and length of a buffer storing transmission data such as video information to be transmitted to the socket information, and directly sets the hardware protocol processing unit 12c. To notify.
  • the software protocol processing unit 22c determines whether or not the segment should set the FIN, SYN, or RST bit of the control flag (step S51).
  • the TCP control processing unit 29 of the software protocol processing unit 22c performs TCP control processing such as TCP sequence number control and TCP header generation (steps). S52). Such a case is performed when the application 21 requests establishment or disconnection of a connection, when a segment in which the SYN bit of the control flag is set is received, or when response processing of a TCP segment is requested.
  • the software protocol processing information generation unit 24 includes information indicating that protocol processing higher than IPv4 has been completed, and information necessary for IPv4 processing (starting point IP address 221, end point IP address 222, and protocol number 219). ) And protocol processing information including information necessary for Ethernet (R) processing (starting point MAC address 112 and ending point MAC address 111) and information on the payload and the length of the payload (step S53).
  • this protocol processing information is transmitted from the software protocol processing information generating unit 24 to the hardware protocol processing resuming unit 14. Then, the hardware protocol process restarting unit 14 determines the start of the protocol process in hardware (step S54).
  • the hardware protocol processing unit 12c performs TCP data processing. Even when information is input from the hardware protocol process resuming unit 14 described above, the hardware protocol processing unit 12c performs TCP data processing (step S55).
  • the hardware protocol processing unit 12c based on the socket information received via the socket information transmission unit 19, starts with a TCP header start port number 411, end port number 412, sequence number 413, acknowledgment number 414, control flag 417, window size 418. Set. Also, the data offset is calculated from the header length. Further, a TCP checksum 419 is calculated from the TCP header and data. A TCP header is created from the data thus obtained.
  • the IPv4 processing unit 16 sets a value other than the header checksum 220 of the IP header (see FIG. 3).
  • the IPv4 processing unit 16 calculates the header checksum 220 and sets it in the checksum field.
  • the Ethernet (R) processing unit 15 sets the start point MAC address 112, the end point MAC address 111, and the type 113 of the Ethernet (R) frame (see FIG. 2) (step S55).
  • the network controller 11 adds the FCS 115 to the Ethernet (R) frame.
  • the Ethernet (R) frame created in this way is modulated, and transmission data is transmitted to the transmission destination device via the network 70 (step S56).
  • the software protocol processing unit 22c when transmitting transmission data from the application 21 or the software protocol processing unit 22c, first, it is determined whether a packet other than the ACK bit should be set in the control flag of the TCP segment. If it is a segment in which only the ACK bit of the control flag is set, all the protocol processing is performed by the hardware protocol processing unit 12c. Therefore, the software protocol processing unit 22c does not perform protocol processing.
  • the hardware protocol processing unit 12c performs protocol processing using the protocol processing information generated by the software protocol processing information generation unit 24.
  • the protocol processing information includes information indicating a part where the protocol processing is completed in the software protocol processing unit 22c, an obtained value, and the like.
  • the hardware protocol processing unit 12c does not process the protocol processing already processed by the software protocol processing unit 22c. Only protocol processing that has not been processed is performed.
  • TCP control processing related to session establishment is performed by the software protocol processing unit 22c.
  • the hardware protocol processing unit 12c changes the session state from the SYN-SENT state or the SYN-RECEIVED state to the ESTABLISHED state. You may go. As a result, even when data is received immediately after the session is established, it is possible to receive the data without missing it.
  • the transmission process of the TCP acknowledgment segment is performed by the hardware protocol processing unit 12c
  • the transmission interval of the acknowledgment segment may be opened and this may be performed by the software protocol processing unit 22c. Thereby, the circuit which transmits an acknowledgment segment can be reduced.
  • the data transmission processing is all performed by the hardware protocol processing unit 12c, but the retransmission processing may be performed by the software protocol processing unit 22c. Since the frequency of retransmission processing is low in a network with a low loss rate, it becomes possible to realize high-speed protocol processing while reducing the necessary circuits for retransmission.
  • the reception of the segment having the continuous sequence number may be performed by the hardware protocol processing unit 12c and the reception of the discontinuous segment may be performed by the software protocol processing unit 22c.
  • the circuit of the hardware protocol processing unit 12c can be simplified and high-speed protocol processing can be realized.
  • the MAC address of the own device and the MAC address of the partner device are shared by the hardware protocol processing unit 12c and the software protocol processing unit 22c via the session information, but when the hardware protocol processing unit 12c performs transmission processing.
  • the MAC address may be referred to from the IP address. In this case, it can be realized by providing a routing table in the software protocol processing unit 22c.
  • the state of the hardware protocol processing unit 12c and the software protocol processing unit 22c can be synchronized by performing the protocol processing using the socket information.
  • data processing with a high operation rate can be performed by the hardware protocol processing unit 12c
  • control processing with a low operation rate can be performed by the software protocol processing unit 22c. Therefore, the circuit scale of the hardware protocol processing unit 12c can be suppressed, and the transmission / reception throughput of the communication apparatus can be greatly improved.
  • Ethernet (R) processing, IPv4 processing, and TCP data processing are processed by the hardware protocol processing unit 12c, and the software protocol processing unit 22c does not need to have the same processing unit, so that the software size can be reduced. .
  • the communication apparatus according to the embodiment can also be realized by using, for example, a general-purpose computer apparatus as basic hardware.
  • a storage medium such as a memory, a hard disk, a CD-R, a CD-RW, a DVD-RAM, a DVD-R, or the like that is built in or attached to the communication apparatus of the embodiment.
  • the present invention can be applied to network-related devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

　通信装置８０には、ハードウェアプロトコル処理部１２、ソフトウェアプロトコル処理部２２、ハードウェアプロトコル処理部１２の処理結果からプロトコル処理情報を生成するハードウェアプロトコル処理情報生成部１３、ハードウェアプロトコル処理情報生成部１３のプロトコル処理情報を用いてソフトウェアプロトコル処理部２２の制御を行うソフトウェアプロトコル処理再開部２３、ソフトウェアプロトコル処理部２２の処理結果からプロトコル処理情報を生成するソフトウェアプロトコル処理情報生成部２４、ソフトウェアプロトコル処理情報生成部２４のプロトコル処理情報を用いてハードウェアプロトコル処理部１２の制御を行うハードウェアプロトコル処理再開部１４が設けられる。

Description

通信装置
　本発明は、通信装置に関する。
　インターネット等で広く用いられるTCP/IP(Transmission Control Protocol/　Internet Protocol)などのプロトコル処理は、従来、主にCPU(Central Processing Unit)上で動作するソフトウェアにより実現されている。しかしながら、近年のネットワークの高速化に伴い、CPUのTCP/IP処理の負荷が増大している。その対応策として、TCP/IP処理を行う専用のハードウェアを設けることにより、高速な通信を実現する通信装置が提案されている（特許文献１参照。）。
　特許文献１に開示される通信装置では、まずデータが高レートかどうかを判別する。次に、高レートの場合には、専用ハードウェアにより各種ヘッダを除去し、アプリケーションデータをメモリ領域に転送する。更に、TCPの場合は、ヘッダのみをネットワーク通信ドライバに引き渡して、ソフトウェアによるTCP/IPスタック処理を行っている。
　しかしながら、特許文献１の技術では、高レートと判断されなかったフレームは、データリンク層、ネットワーク層の処理もすべてソフトウェアにより処理されることになる。従って、例えば、TCPのセッション確立のためのセグメントを処理する場合、処理速度が低下するという問題点がある。また、専用ハードウェアに備えられるデータリンク層やネットワーク層の処理部の機能を、ソフトウェアでも二重に備えなければならない。その結果、ソフトウェアのサイズが増大するという問題点がある。
特開２００６－３１１４５号公報
　本発明は、上記問題点を解決するためになされたもので、通信のスループットを向上できる通信装置を提供することを目的とする。
　本発明の一態様の通信装置は、受信データのフレームに対しハードウェアによるプロトコル処理を行うハードウェアプロトコル処理部と、前記ハードウェアプロトコル処理部とは異なるハードウェアで実現され、前記受信データのフレームに対しソフトウェアによるプロトコル処理を行うソフトウェアプロトコル処理部と、前記ハードウェアプロトコル処理部によるプロトコル処理で処理が完了した部分を示す情報と、前記ハードウェアプロトコル処理部によるプロトコル処理によって得られた値を含むプロトコル処理情報を生成するハードウェアプロトコル処理情報生成部と、前記プロトコル処理情報を用いて、前記ハードウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ソフトウェアプロトコル処理部に行わせるソフトウェアプロトコル処理再開部とを具備することを特徴とする。
　本発明によれば、通信のスループットを向上させ、ソフトウェアのサイズを削減できる通信装置を提供することができる。
本発明の実施例１に係る通信装置を示すブロック図。 本発明の実施例１に係るEthernet(R)フレームの構成を示す図。 本発明の実施例１に係るIPヘッダの構成を示す図。 本発明の実施例１に係るUDPヘッダの構成を示す図。 本発明の実施例１に係る通信装置の受信処理を示すフロ-チャート。 本発明の実施例１に係る通信装置の送信処理を示すフローチャート。 本発明の実施例１に係るUDP受信を高速化した通信装置を示すブロック図。 本発明の実施例１に係るUDP送信を高速化した通信装置を示すブロック図。 本発明の実施例２に係る通信装置を示すブロック図。 本発明の実施例２に係るTCPヘッダの構成を示す図。 本発明の実施例２に係るTCPのセッション状態を示す図。 本発明の実施例２に係るUDP受信処理を示すフローチャート。 本発明の実施例２に係るTCP受信処理を示すフローチャート。 本発明の実施例２に係るTCP送信処理を示すフローチャート。
　以下、本発明の実施例について図面を参照しながら説明する。
　まず、本発明の実施例１に係る通信装置について、図面を参照して説明する。図１は、通信装置を示すブロック図である。図２は、Ethernet(R)フレームの構成を示す図である。図３は、IPヘッダの構成を示す図である。図４は、UDPヘッダの構成を示す図である。本実施例では、受信側にハードウェアプロトコル処理情報生成部とソフトウェアプロトコル情報再開部を設けている。また、送信側にソフトウェアプロトコル処理情報生成部とハードウェアプロトコル処理再開部を設けている。
　図１に示す通信装置８０は、例えば映像送受信装置である。通信装置８０は、Ethernet(R)によってネットワーク７０に接続されている。通信装置８０は、映像情報をディスク装置(Hard Disk Drive等)から読み出してUDP(User Datagram Protocol)によってネットワーク７０に接続されているクライアント装置に送信する機能を備える。また、クライアント装置からUDPで受信した映像情報をディスク装置に保存する機能を備える。通信装置８０は、FPGA(Field Programmable Gate Array)やASIC(Application Specific Integrated Circuit)などによって実現されるハードウェア処理部１と、CPU上で動作するソフトウェアにより処理が行われるソフトウェア処理部２により構成される。つまり、ハードウェア処理部１とソフトウェア処理部２は、異なる処理機能で構成される。
　ハードウェア処理部１には、ネットワークコントローラ１１、ハードウェアプロトコル処理部１２、ハードウェアプロトコル処理情報生成部１３、及びハードウェアプロトコル処理再開部１４が設けられる。
　ネットワークコントローラ１１は、ネットワーク７０からEthernet(R)フレームを受信すると、Ethernet(R)物理層の処理、及びEthernet(R)のデータリンク層の一部の処理を行う。具体的には、Ethernet(R)規格によって規定された信号を復調し、図２に示すEthernet(R)フレームを取り出す。Ethernet(R)フレームは、終点MAC(Media Access Control)アドレス１１１、始点MAC(Media Access Control)アドレス１１２、タイプ１１３、データ１１４、及びＦＣＳ(Frame Check Sequence)１１５から構成される。次に、ネットワークコントローラ１１は、Ethernet(R)フレームに破損がないかを検証するためFCS(Frame Check Sequence)の検算処理を行う。なお、終点MACアドレス１１１は宛先アドレスとも呼称され、始点MACアドレス１１２は送信元アドレスとも呼称される。
　Ethernet(R)フレームの場合、例えば、終点MACアドレス１１１が６オクテット(48bit)、始点MACアドレス１１２が６オクテット(48bit)、タイプ１１３が２オクテット(16bit)、データ１１４が４６～１５００オクテット、ＦＣＳ(Frame Check Sequence)１１５が４オクテット(32bit)で構成されている。タイプ１１３には、IP(Internet Protocol)、ARP(Address Resolution Protocol)、RARP(Reverse Address Resolution Protocol)がある。
　ネットワークコントローラ１１は、送信処理のとき、ハードウェアプロトコル処理部１２で処理された送信情報にＦＣＳを付加し、フレーム変調を施してネットワーク７０に送信する。
　ハードウェアプロトコル処理部１２には、Ethernet(R)処理部１５、IPv4(Internet Protocol version 4)処理部１６、及びUDP処理部１７が設けられる。ハードウェアプロトコル処理部１２は、受信及び送信のときにハードウェアによるプロトコル処理を実行する。
　Ethernet(R)処理部１５は、Ethernet(R)のデータリンク層の一部の処理を行う。IPv4処理部１６は、図３に示すIPv4ヘッダの処理を行う。IPv4ヘッダ（IPヘッダ）は、バージョン２１１、ヘッダ長２１２、サービスタイプ２１３、IPパケット長２１４、識別子２１５、コントロールフラグ２１６、フラグメントオフセット２１７、生存時間２１８、プロトコル番号２１９、ヘッダチャックサム２２０、始点IPアドレス２２１、及び終点IPアドレス２２２から構成される。
　例えば、バージョン２１１は４bit、ヘッダ長２１２は４bit、サービスタイプ２１３は８bit、IPパケット長２１４は１６bit、識別子２１５は１６bit、コントロールフラグ２１６は３bit、フラグメントオフセット２１７は１３bit、生存時間２１８は８bit、プロトコル番号２１９は８bit、ヘッダチャックサム２２０は１６bit、始点IPアドレス２２１は３２bit、及び終点IPアドレス２２２は３２bitで構成されている。なお、３２bitの倍数オプションが任意に設けられる。プロトコル番号２１９には、ICMP(Internet Control Message Protocol)、TCP(Transmission Control Protocol)、UDP(User Datagram Protocol)、DCCP(Datagram Congestion Control Protocol)がある。
　UDP処理部１７は、図４に示すUDPヘッダの処理を行う。UDPヘッダは、始点ポート番号３１１、終点ポート番号３１２、UDPパケット長３１３、及びUDPチェックサム３１４から構成される。例えば、始点ポート番号３１１は１６bit、終点ポート番号３１２は１６bit、UDPパケット長３１３は１６bit、及びUDPチェックサム３１４は１６bitで構成されている。
　ハードウェアプロトコル処理情報生成部１３は、受信のとき、ハードウェアプロトコル処理部１２の処理結果からプロトコル処理情報を生成する。そのプロトコル処理情報は、ソフトウェア処理部２に出力される。ハードウェアプロトコル処理再開部１４は、送信のとき、ソフトウェアプロトコル処理情報生成部２４で生成されたプロトコル処理情報を受信する。ハードウェアプロトコル処理再開部１４からプロトコル処理情報を受信したハードウェアプロトコル処理部１２は、ハードウェアによるプロトコル処理を行う。
　ソフトウェア処理部２には、アプリケーション２１、ソフトウェアプロトコル処理部２２、ソフトウェアプロトコル処理再開部２３、及びソフトウェアプロトコル処理情報生成部２４が設けられる。
　ソフトウェアプロトコル処理部２２は、受信及び送信のときにソフトウェアによるプロトコル処理を実行する。ソフトウェアプロトコル処理部２２には、ARP(Address Resolution Protocol)処理部２５、IPv6(Internet Protocol version 6)処理部２６、ICMPv4(Internet Control Message Protocol version 4)処理部２７、及びDCCP(Datagram Congestion Control Protocol)処理部２８が設けられる。ARP処理部２５は、ARP処理を行う。IPv6処理部２６は、IPv6処理を行う。DCCP処理部２８は、DCCP処理を行う。
　ソフトウェアプロトコル処理再開部２３は、受信のとき、ハードウェアプロトコル処理情報生成部１３で生成されたプロトコル処理情報を受けて、ソフトウェアプロトコル処理部２２を制御する。ソフトウェアプロトコル処理情報生成部２４は、送信のとき、ソフトウェアプロトコル処理部２２の処理結果からプロトコル処理情報を生成する。そのプロトコル処理情報は、ハードウェアプロトコル処理再開部１４へ出力される。ハードウェアプロトコル処理再開部１４は、受信したプロトコル処理情報によりハードウェアプロトコル処理部１２を制御する。
　アプリケーション２１は、送信時に映像情報などの送信データを、図示しないディスク装置から読み出す制御をする。また、アプリケーション２１は、受信時に映像情報などの受信データをディスク装置に保存する機能を備えている。
　次に、実施例１に係る通信装置の動作について、図５及び図６を参照して説明する。図５は、通信装置の受信処理手順を示すフローチャートである。図６は、通信装置の送信処理手順を示すフローチャートである。
　通信装置８０の受信処理について、図５を参照して説明する。まず、ネットワーク７０から伝送されたデータがネットワークコントローラ１１に入力される。ネットワークコントローラ１１は、Ethernet(R)の物理層の処理、及びEthernet(R)のデータリンク層の一部の処理を行う。具体的には、Ethernet(R)規格によって規定された受信信号を復調し、Ethernet(R)フレーム（図２参照）を取り出す。そして、フレームに破損がないかを検証するためＦＣＳ１１５を用いて検算処理を行う。Ethernet(R)フレームの破損を検出した場合には、当該フレームは破棄される（ステップＳ１１）。
　次に、Ethernet(R)フレームに破損がないことが検証されたフレームは、ハードウェアプロトコル処理部１２に出力される。ハードウェアプロトコル処理部１２は、プロトコル処理を行う（ステップＳ１２）。具体的には、Ethernet(R)処理部１５は、受信したEthernet(R)フレームの終点MACアドレス１１１から、自ホスト宛のフレームであるか、マルチキャストフレームであるか、ブロードキャストフレームであるか、及び他ホスト宛のフレームであるかの判断を行い、宛先種別を識別する。また、必要に応じて始点MACアドレス１１２、或いは終点MACアドレス１１１によりフィルタリングを行う。Ethernet(R)フレーム中のタイプ１１３には、上位層のプロトコル種別（図２のタイプ表を参照）が記録されている。このタイプ１１３の値がIP(=0800)であれば、ハードウェアプロトコル処理部１２での処理を継続し、IPv4処理部１６での受信処理が開始される。
　IPv4処理部１６は、IPv4ヘッダ（図３参照）の処理を行う。Ethernet(R)のタイプ１１３がIPであってもIPv6である場合もあるため、バージョン２１１の値が「６」であればハードウェアプロトコル処理部１２での処理は終了する。そして、Ethernet(R)処理部１５で得られた結果とともに、ネットワーク層のプロトコルがIPv6であることをハードウェアプロトコル処理情報生成部１３に通知される。バージョン２１１の値が「４」であれば、IPv4処理部１６は、ヘッダ長２１２及びIPパケット長２１４の検証や、ヘッダチェックサム２２０を検証する。また、IPパケットがフラグメントしている場合には、デフラグメント処理が行われる。
　IPヘッダのプロトコル番号２１９には、上位層のプロトコル種別が記述（図３のプロトコル番号表を参照）されている。このプロトコル番号２１９の値がDCCP(=33)やICMPv4(=1)などを示すものであれば、ハードウェアプロトコル処理部１２での処理は終了する。一方、プロトコル番号２１９がUDP(=17)であれば、ハードウェアプロトコル処理部１２での処理が継続され、UDP処理部１７での受信処理が開始される。
　UDP処理部１７は、UDPヘッダ（図４参照）の処理を行う。UDP処理部１７は、UDPパケット長３１３の検証や、ペイロードのUDPチェックサム３１４を計算し、データの破損がないかの検証を行う。データの破損を検出すると、ペイロードが破棄され、処理が終了する。
　続いて、ハードウェアプロトコル処理部１２は、ハードウェア処理による全てのプロトコル処理が完了しているかの判定を行う（ステップＳ１３）。
　全てのプロトコル処理が完了していないと判定し、且つEthernet(R)フレーム中のタイプ１１３がARP(=0806)であれば、ハードウェアプロトコル処理部１２は、ハードウェアプロトコル処理情報生成部１３に宛先種別と、上位層のプロトコル種別と、データ１１４をプロトコル処理結果として通知する。また、IPヘッダの値がDCCP(=33)やICMPv4(=1)であれば、ハードウェアプロトコル処理部１２は、ハードウェアプロトコル処理情報生成部１３に始点IPアドレス２２１及び終点IPアドレス２２２、IPパケット長２１４、ペイロード等を通知する。ハードウェアプロトコル処理情報生成部１３は、それらの通知された情報からプロトコル情報を生成する（ステップＳ１４）。
　次に、ハードウェアプロトコル処理情報生成部１３は、生成したプロトコル情報をソフトウェアプロトコル処理再開部２３に伝達する。ソフトウェアプロトコル処理再開部２３は、ソフトウェアでのプロトコル処理（ARP、DCCP、ICMPv4）の開始部を決定する（ステップＳ１５）。
　続いて、ソフトウェアでのプロトコル処理の開始が指示されたソフトウェアプロトコル処理部２２は、ハードウェアプロトコル処理部１２で処理されなかったプロトコル処理を実行する（ステップＳ１６）。例えば、受信したフレームがARPであれば、ハードウェアプロトコル処理部１２でEthernet(R)処理が行われているので、ARPヘッダの解析を行い、必要ならARPキャッシュの更新やARP応答の送信処理を行う。受信したフレームがDCCPおよびICMPv4の場合は、Ethernet(R)処理およびIPv4処理がハードウェアプロトコル処理部１２で行われているため、DCCPのプロトコル処理やICMPv4の処理を行う。
　そして、ソフトウェアプロトコル処理部２２は、全てのプロトコル処理が完了していると判定した場合（或いは、ソフトウェアによるプロトコル処理後）、処理する映像情報などのデータがあるかを判定する。処理するデータがないと判定した場合は、受信処理は終了する（ステップＳ１７）。一方、処理するデータがあると判定した場合は、アプリケーション２１は受信データをディスク装置に格納する処理を実行する（ステップＳ１８）。受信したEthernet(R)フレームがハードウェアプロトコル処理部１２全てのプロトコル処理が完了する場合、アプリケーション２１は映像情報などのデータをディスク装置に保存する処理が行われる。
　このように、受信したEthernet(R)フレームにハードウェアプロトコル処理部１２では処理できないプロトコル（ARP、DCCP、ICMPv4など）が含まれている場合、ハードウェアプロトコル処理部１２の処理結果から得られたプロトコル処理情報がソフトウェアプロトコル処理部２２に通知される。ソフトウェアプロトコル処理部２２は、ソフトウェアによるプロトコル処理を終了すると、アプリケーションに渡すデータがあればアプリケーション２１にデータを渡し、アプリケーション２１は映像情報などの受信データをディスク装置に保存する。
　このとき、上述したプロトコル処理情報には、ハードウェアプロトコル処理部１２にてプロトコル処理が完了した情報や、プロトコル処理によって得られた値などが含まれる。したがって、ソフトウェアプロトコル処理部２２は、ハードウェアプロトコル処理部１２で既に処理を終了したプロトコルについては処理を行わず、処理できなかったプロトコルの処理を行う。
　次に、通信装置８０の送信処理について、図６を参照して説明する。送信処理では、ソフトウェアプロトコル処理部２２が送信を行う場合、例えば次の３つのケースがある。第１は、上述した受信処理によりARPやICMPv4が処理された場合に、応答パケットを送信するケース。第２は、相手のMACアドレスを知るために能動的にARP要求パケットを送信するケース。第３は、アプリケーション２１からパケットを送信するケースなどがある。ここでは、アプリケーション２１或いはソフトウェアプロトコル処理部２２によるデータ送信の場合を例にして説明する。
　通信装置８０の送信処理について、図６を参照して説明する。まず、アプリケーション２１により映像情報などのデータがディスク装置から読み出される。アプリケーション２１は、プロトコル処理を行うために必要なUDPの始点ポート番号３１１、終点ポート番号３１２、UDPパケット長３１３、IPのバージョン２１１、サービスタイプ２１３、IPパケット長２１４、識別子２１５、コントロールフラグ２１６、生存時間２１８、始点IPアドレス２２１、終点IPアドレス２２２、Ethernet(R)の始点MACアドレス１１２、終点MACアドレス１１１、ネットワークのMTU(Maximum Transmission Unit)を生成する。これらのプロトコル処理情報は、ソフトウェアプロトコル処理部２２に通知される。ソフトウェアプロトコル処理部２２は、送信を行うプロトコル処理が全てハードウェアプロトコル処理部１２で処理が可能か否かの判定を行う（ステップＳ２１）。
　ハードウェアプロトコル処理部１２では処理ができないと判定した場合、（例えば、ICMPv4の受信処理を行ったパケットがエコー応答を求めるものであった場合、）ソフトウェアプロトコル処理部２２はICMPv4のエコー応答パケットの生成処理を行う。また、ソフトウェアプロトコル処理部２２は、ARP要求パケットを受信した場合のARP応答パケットを生成して送信する。なお、プロトコル処理情報中の値がアプリケーション２１から指定されなかった場合、ソフトウェアプロトコル処理部２２で保持している固定な値を設定してプロトコル処理情報に含めてもよいし、ARP要求パケットを送信して能動的に解決した結果を用いてもよい（ステップＳ２２）。
　次に、ソフトウェアプロトコル処理情報生成部２４は、IPv4より上位のプロトコル処理が完了したことを示す情報、IPv4処理を行うために必要な始点IPアドレス２２１、終点IPアドレス２２２、プロトコル番号２１９、Ethernet(R)処理を行うために必要な始点MACアドレス１１２、終点MACアドレス１１１、ペイロードとペイロードの長さ、を含んだプロトコル処理情報を生成する。また、ソフトウェアプロトコル処理情報生成部２４は、下位層であるEthernet(R)の処理に必要な始点MACアドレス１１２、終点MACアドレス１１１、タイプ１１３、ARPまでのプロトコル処理が完了したこと示す情報、をプロトコル処理情報として生成する（ステップＳ２３）。
　続いて、ソフトウェアプロトコル処理情報生成部２４は、生成したプロトコル処理情報をハードウェアプロトコル処理再開部１４に伝達する。ハードウェアプロトコル処理再開部１４は、ハードウェアでのプロトコル処理の開始を決定する（ステップＳ２４）。
　そして、ハードウェアプロトコル処理部１２が全てのプロトコル処理が可能と判定した場合（或いは、ハードウェアでのプロトコル処理の開始が決定された後）、UDP処理部１７は、通知されたプロトコル処理情報に含まれる値をUDPヘッダの始点ポート番号３１１、終点ポート番号３１２、UDPパケット長３１３に設定する。また、UDP処理部１７は、ヘッダとデータからUDPチェックサム３１４を計算して、UDPヘッダを作成する。
　次に、IPv4処理部１６は、必要に応じてフラグメントの処理を行い、パケット毎の識別子２１５、コントロールフラグ２１６、フラグメントオフセット２１７の値を設定する。また、IPヘッダのヘッダチェックサム２２０以外の値を設定する。最後に、ヘッダチェックサム２２０を計算して、チェックサムフィールドに値を設定する。
　次に、Ethernet(R)処理部１５は、Ethernet(R)フレームの始点MACアドレス１１２、終点MACアドレス１１１、タイプ１１３を設定する。また、Ethernet(R)処理部１５は、Ethernet(R)のプロトコル処理を行う（ステップＳ２５）。そして、ネットワークコントローラ１１は、Ethernet(R)フレームにＦＣＳ１１５を付加し、変調されたEthernet(R)フレームをネットワーク７０に送信する（ステップＳ２６）。
　このように、アプリケーション２１又はソフトウェアプロトコル処理部２２からパケット送信を行う場合、ソフトウェアプロトコル処理部２２は、送信を行うプロトコル処理が全てハードウェアプロトコル処理部１２で処理が可能か否かを判定する。全て処理可能と判断される場合、送信データはハードウェアプロトコル処理部１２からネットワークコントローラ１１に出力される。ネットワークコントローラ１１は、ネットワーク７０を介して送信先装置に伝送する。
　一方、全て処理ができないと判断される場合、ソフトウェアプロトコル処理部２２は、送信プロトコル処理を行う。更に、ソフトウェアプロトコル処理情報生成部２４はプロトコル処理情報を生成し、これらのプロトコル処理情報がハードウェアプロトコル処理再開部１４を介してハードウェアプロトコル処理部１２に送信される。このとき、プロトコル処理情報には、ソフトウェアプロトコル処理部２２にてプロトコル処理が完了した部分を示す情報、プロトコル処理により得られた値などが含まれる。ハードウェアプロトコル処理部１２では、ソフトウェアプロトコル処理部２２で処理できなかったプロトコルのみが処理されることになる。例えば、送信するフレームがARPの場合には、ハードウェアプロトコル処理部１２でEthernet(R)の処理が可能であるため、ソフトウェアプロトコル処理部２２でARPの処理のみを行い、ハードウェアプロトコル処理部１２でEthernet(R)の処理を行う。送信するフレームがDCCPやICMPv4の場合は、ハードウェアプロトコル処理部１２でEthernet(R)およびIPv4の処理が可能であるため、ソフトウェアプロトコル処理部２２でDCCPまたはICMPv4の処理のみを行い、ハードウェアプロトコル処理部１２でIPv4およびEthernet(R)の処理を行う。
　図７は、実施例１の第１の変形例を示す。第１の変形例の通信装置８０ａには、ハードウェア処理部１ａとソフトウェア処理部２ａが設けられる。ハードウェア処理部１ａには、ネットワークコントローラ１１ａ、ハードウェアプロトコル処理部１２ａ、及びハードウェアプロトコル処理情報生成部１３ａが設けられる。ハードウェアプロトコル処理部１２ａには、Ethernet(R)受信処理部１５ａ、IPv4受信処理部１６ａ、及びUDP受信処理部１７ａが設けられる。ソフトウェア処理部２ａには、アプリケーション２１ａ、ソフトウェアプロトコル処理部２２ａ、ソフトウェアプロトコル処理再開部２３ａ、及びソフトウェアプロトコル処理部３０が設けられる。ソフトウェアプロトコル処理部２２ａには、ARP処理部２５ａ、IPv6処理部２６ａ、ICMPv4処理部２７ａ、及びDCCP処理部２８ａが設けられる。ソフトウェアプロトコル処理部３０には、IPv4送信処理部３１とEthernet(R)送信処理部３２が設けられる。
　この第１変形例では、受信に対応するハードウェアプロトコル処理情報生成部１３ａとソフトウェアプロトコル情報再開部２３ａを通信装置８０ａに設けている。送信に対応するソフトウェアプロトコル処理部３０を通信装置８０ａのソフトウェア処理部２ａに設けている。通信装置８０ａでは、ＵＤＰ受信処理を高速化することができる。
　この場合、受信データは、ネットワークコントローラ１１ａ、ハードウェアプロトコル処理部１２ａ、ハードウェアプロトコル処理情報生成部１３ａ、ソフトウェアプロトコル処理再開部２３ａ、ソフトウェアプロトコル処理部２２ａ、アプリケーション２１ａへと順次転送される。送信データは、アプリケーション２１ａ、ソフトウェアプロトコル処理部２２ａ、ソフトウェアプロトコル処理部３０、ネットワークコントローラ１１ａへと順次転送される。
　なお、ソフトウェアプロトコル処理部２２ａとソフトウェアプロトコル処理部３０は、同一のCPUによって処理されるものであってもよいし、別々のプロセッサによって処理されるものであってもよい。
　図８は、実施例１の第２の変形例を示す。第２の変形例の通信装置８０ｂには、ハードウェア処理部１ｂとソフトウェア処理部２ｂが設けられる。ハードウェア処理部１ｂには、ネットワークコントローラ１１ｂ、ハードウェアプロトコル処理部１２ｂ、及びハードウェアプロトコル処理再開１４ｂが設けられる。ハードウェアプロトコル処理部１２ｂには、Ethernet(R)送信処理部１５ｂ、IPv4送信処理部１６ｂ、及びUDP送信処理部１７ｂが設けられる。ソフトウェア処理部２ｂには、アプリケーション２１ｂ、ソフトウェアプロトコル処理部２２ｂ、ソフトウェアプロトコル処理情報生成部２４ｂ、及びソフトウェアプロトコル処理部４０が設けられる。ソフトウェアプロトコル処理部２２ｂには、ARP処理部２５ｂ、IPv6処理部２６ｂ、ICMPv4処理部２７ｂ、及びDCCP処理部２８ｂが設けられる。ソフトウェアプロトコル処理部４０には、IPv4受信処理部４１とEthernet(R)受信処理部４２が設けられる。
　この第２変形例では、送信に対応するソフトウェアプロトコル処理情報生成部２４ｂとハードウェアプロトコル情報再開部１４ｂを通信装置８０ｂに設けている。受信に対応するソフトウェアプロトコル処理部４０を通信装置８０ｂのソフトウェア処理部２ｂに設けている。通信装置８０ｂでは、ＵＤＰ送信処理を高速化することができる。
　この場合、送信データは、アプリケーション２１ｂ、ソフトウェアプロトコル処理部２２ｂ、ソフトウェアプロトコル処理情報生成部２４ｂ、ハードウェアプロトコル処理再開部１４ｂ、ハードウェアプロトコル処理部１２ｂ、ネットワークコントローラ１１ｂへと順次転送される。受信データは、ネットワークコントローラ１１ｂ、ソフトウェアプロトコル処理部４０、ソフトウェアプロトコル処理部２２ｂ、アプリケーション２１ｂへと順次転送される。
　なお、ソフトウェアプロトコル処理部２２ｂとソフトウェアプロトコル処理部４０は、同一のCPUによって処理されるものであってもよいし、別々のプロセッサによって処理されるものであってもよい。
　上述したように、本実施例の通信装置は、フレーム受信処理では、ハードウェアプロトコル処理部１２では処理できないフレームの場合、ハードウェアプロトコル処理部１２で処理可能なプロトコル処理を行い、ソフトウェアプロトコル処理部２２で上位層のプロトコル処理を行う構成としている。また、フレーム送信処理では、ソフトウェアプロトコル処理部２２で処理可能なプロトコル処理を行い、ハードウェアプロトコル処理部１２で下位層のプロトコル処理を行う構成としている。このため、受信時及び送信時において全てのプロトコル処理がハードウェアプロトコル処理部１２で行える場合にも、また一部の処理しかハードウェアプロトコル処理部１２で行えない場合にも、できる限り高速にプロトコル処理を実行することができる。したがって、通信装置８０の送受信のスループットを大幅に向上させることができる。
　また、Ethernet(R)処理とIPv4処理はハードウェアプロトコル処理部１２で処理され、ソフトウェアプロトコル処理部２２にはEthernet(R)処理部とIPv4処理部を備える必要がないため、ソフトウェアのサイズを削減することができる。更に、ハードウェアプロトコル処理とソフトウェアプロトコル処理を適宜分割することが可能となる。
　なお、本実施例では、物理層及びデータリンク層がEthernet(R)であったが、IEEE802.11で定義される規格であってもよい。IEEE802.11を物理層及びデータリンク層に用いる場合、ハードウェアプロトコル処理部１２に制御フレーム処理部及びデータフレーム処理部を設けても良い。また、ソフトウェアプロトコル処理部２２にマネージメントフレーム処理部を設けてもよい。
　また、本実施例ではハードウェアプロトコル処理部１２及びソフトウェアプロトコル処理部２２の割り当てをプロトコル単位で行った。プロトコル処理情報により未完了部分を通知することにより、これに限定される、例えばIPv4のフラグメント及びデフラグメント処理部をソフトウェアプロトコル処理部２２に設けてもよい。また、その他の処理部をハードウェアプロトコル処理部１２に設けてもよい。
　また、ハードウェアプロトコル処理部１２に実装するプロトコルは、HTTP(Hypertext Transfer Protocol)、TCP(Transmission Control Protocol)、RTP(Real-time Transport Protocol)、IP sec（Security Architecture for Internet Protocol）、SCTP(Stream Control Transmission Protocol)、DCCPなど他のプロトコルであってもよい。
　更に、プロトコル処理情報を生成する際に、ソフトウェアプロトコル処理部２２に固定的な値を保持する構成としたが、ハードウェアプロトコル処理部１２に保持してもよい。
　次に、本発明の実施例２に係る通信装置について、図面を参照して説明する。図９は通信装置を示すブロック図である。図１０は、TCPヘッダの構成を示す図である。図１１は、TCPのセッション状態を示す図である。本実施例では、ソケット情報伝達部１９をハードウェアプロトコル処理部１２ｃとソフトウェアプロトコル処理部２２ｃの間に設けている点が、実施例１と違う。よって、実施例１と同一構成部分には、同一符号を付してその部分の説明を省略し、異なる部分のみ説明する。
　ハードウェアプロトコル処理部１２ｃには、Ethernet(R)処理部１５、IPv4処理部１６、UDP処理部１７の他にTCPデータ処理部１８が新たに設けられている。ソフトウェアプロトコル処理部２２ｃには、ARP処理部２５、ICMPv4処理部２７の他にTCP制御処理部２９が新たに設けられている。なお、ソフトウェアプロトコル処理部２２ｃには、IPv6処理部が取り除かれている。
　通信装置８１は、TCPによりネットワーク７０に設けられる装置からの映像データを受信して図示しないディスク装置に保存する機能と、ディスク装置から映像データを読み出してTCPによりネットワーク７０に設けられる装置へデータを送信する機能を有している。また、実施例１の機能の他に、ソケット情報をアプリケーション２１、ハードウェアプロトコル処理部１２ｃ、及びソフトウェアプロトコル処理部２２ｃに伝達するソケット情報伝達部１９を有している。
　通信装置８１では、UDPの送信、或いは受信を行うためにポートが開かれたとき、ソケット情報が作成される。また、TCPの送信、或いは受信を行うためにポートが開かれたとき、ソケット情報が作成される。ソケット情報は、ハードウェアプロトコル処理部１２ｃ、及びソフトウェアプロトコル処理部２２ｃから参照可能なメモリ（図示せず）上に設定されている。
　ここで、ソケット情報は、プロトコル毎に異なっている。例えば、UDPの場合、本装置のIPアドレス、相手装置のIPアドレス、本装置のポート番号、相手装置のポート番号、セッションの状態、アプリケーションの指定する送信バッファのアドレスと長さ、アプリケーションの指定する受信バッファのアドレスと長さ、IPのサービスタイプ、生存時間、MTU、本装置のMACアドレス、相手装置のMACアドレス等の値が格納されている。UDPのセッションの状態は、オープン或いはクローズのどちらかの状態をとる。
　図１０は、TCPヘッダの一例を示す。TCPヘッダは、例えば始点ポート番号４１１、終点ポート番号４１２、シーケンス番号４１３、確認応答番号４１４、データオフセット４１５、未使用（予約）４１６、コントロールフラグ４１７、ウィンドウサイズ４１８、TCPチェックサム４１９、及び緊急ポインタ４２０から構成されている。
　例えば、始点ポート番号４１１は１６bit、終点ポート番号４１２は１６bit、シーケンス番号４１３は３２bit、確認応答番号４１４は３２bit、データオフセット４１５は４bit、未使用（予約）４１６は６bit、コントロールフラグ４１７は６bit、ウィンドウサイズ４１８は１６bit、TCPチェックサム４１９は１６bit、及び緊急ポインタ４２０は１６bitである。なお、３２bit単位で可変長であるオプションやバディング部が任意に設けられる。コントロールフラグ４１７のフラグには、URG(Urgent)、ACK(Acknowledge)、PSH(Push)、RST(Reset)、SYN(Synchronize)、及びFIN(Finish)がある。
　TCPのセッション情報の場合、本装置のIPアドレス、相手装置のIPアドレス、本装置のポート番号、相手装置のポート番号、セッションの状態、アプリケーションの指定する送信バッファのアドレスと長さ、アプリケーションの指定する受信バッファのアドレスと長さ、IPのサービスタイプ、生存時間、MTU、本装置のMACアドレス、相手装置のMACアドレス、送信したがACKされていないシーケンス番号(SND.UNA)、次に送信するシーケンス番号(SND.NXT)、送信ウィンドウサイズ(SND.WND)、最新のウィンドウ更新のために使ったセグメントシーケンス番号(SND.WL1)、最新のウィンドウ更新のために使われたセグメント確認番号(SND.WL2)、次に受信するべきシーケンス番号(RCV.NXT)、受信ウィンドウサイズ(RCV.WND)等の値が設定される。
　TCPのソケット情報については、セグメント送信時或いはセグメント受信時に、ハードウェアプロトコル処理部１２ｃ或いはソフトウェアプロトコル処理部２２ｃにて値が更新されるものがある。
　図１１は、TCPのセッション状態を示す。TCPのセッション状態は、LISTEN、SYN-SENT、SYN-RECEIVED、ESTABLIHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK、TIME-WAIT、及びCLOSEDがある。
　次に、実施例２の通信装置の動作について、図１２乃至１４を参照して説明する。図１２は、UDP受信処理を示すフローチャートである。図１３は、TCP受信処理を示すフローチャートである。図１４は、TCP送信処理を示すフローチャートである。
　通信装置８１のＵＤＰ受信処理について、図１２を参照して説明する。まず、ネットワークコントローラ１１がネットワーク７０から伝送されてきたEthernet(R)フレームを受信する。そして、ネットワークコントローラ１１によってハードウェアプロトコル処理部１２ｃが動作し、プロトコル処理が行われる。即ち、UDP処理部１７は、UDPヘッダの処理を行い、UDPパケット長３１３、ペイロードのUDPチェックサム３１４を計算する。またUDP処理部１７は、データの破損がないか否かを検証する。データの破損していることを検知すると、ペイロードを破棄して、処理を終了する（ステップＳ３１）。次に、ハードウェアプロトコル処理部１２ｃは、ソケット情報のセッション状態がオープンかどうかの判定を行う（ステップＳ３２）。
　ソケット情報のセッション状態が「クローズ」状態と判定された場合、ハードウェアプロトコル処理情報生成部１３はICMPのport unreachableを送信するプロトコル処理情報を生成する（ステップＳ３３）。このプロトコル処理情報はソフトウェアプロトコル処理再開部２３に伝達される。ソフトウェアプロトコル処理再開部２３は、ソフトウェアでのプロトコル処理の開始を決定して、ソフトウェアプロトコル処理部２２ｃに通知する（ステップＳ３４）。ソフトウェアプロトコル処理部２２ｃのICMPv4処理部２７は、port unreachableパケットを作成してアプリケーション２１に送信する（ステップＳ３５）。
　一方、セッションの状態が「オープン」状態と判定した場合、ハードウェアプロトコル処理部１２ｃは、アプリケーション２１で処理する受信データがあるか否かの判定を行う（ステップＳ３６）。アプリケーション２１にて処理する受信データがないと判定された場合、受信処理は終了する。
　アプリケーション２１にて処理する受信データがあると判定された場合、UDP処理部１７はソケット情報によって指定されているアプリケーション２１の受信バッファに受信データを書き込み、ディスク装置に映像データを格納して、処理を終了する（ステップＳ３７）。
　次に、通信装置８１のＴＣＰ受信処理について、図１３を参照して説明する。TCPデータ処理部１８は、以下のＴＣＰ受信処理を実行する。（１）ソケット情報のセッション状態が「ESTABLISHED」であれば、TCPヘッダの一部の処理を行う。（２）TCPセグメントのチェックサム検証と、シーケンス番号順にデータの並べ替え処理を行う。（３）ペイロードをソケット情報から得られるアプリケーション２１の受信バッファに書き込む。（４）TCPセグメントのコントロールフラグ４１７のACKビットが設定されていれば、確認応答された内部送信バッファの解放処理を行う。（５）TCPセグメントを受信した場合、送信する確認応答セグメントの送信処理を行う（ステップＳ４１）。
　ここで、TCPデータ処理部１８によって確認応答セグメントが作成されると、ハードウェアプロトコル処理部１２ｃのIPv4処理部１６及びEthernet(R)処理部１５では、それぞれの送信処理を行う。これにより、確認応答セグメントはネットワークコントローラ１１を介してネットワーク１１に接続されるクライアント装置に送信される。
　次に、TCPデータ処理部１８は、TCPセグメントのコントロールフラグ４１７（図１０のコントロールフラグ表を参照）にFIN、SYN、或いはRSTのいずれかが設定されているか否かの判定を行う（ステップＳ４２）。
　FIN、SYN、或いはRSTが設定されていると判定した場合、ハードウェアプロトコル処理情報生成部１３は、プロトコル処理情報を生成する（ステップＳ４３）。このプロトコル処理情報は、ハードウェアプロトコル処理情報生成部１３からソフトウェアプロトコル処理再開部２３に伝達される。ソフトウェアプロトコル処理再開部２３は、ソフトウェアプロトコル処理部２２ｃに対しソフトウェアでのプロトコル処理の開始を指示する（ステップＳ４４）。ソフトウェアプロトコル処理部２２ｃのTCP制御処理部２９は、TCP制御処理を行う（ステップＳ４５）。TCP制御処理部２９は、例えばRFC793に従い、TCPコントロールフラグのビット処理を行う。例えば、SYNフラグが設定されていて、ソケット情報のセッション状態がLISTENであれば、セッション情報のSND.NXT、RCV.NXT等の値が設定される。このとき、コントロールフラグにSYNビットとACKビットを立てたセグメントが相手装置に送信され、SYN-RECEIVEDにセッション状態を移行するという処理が行われる。ソフトウェアプロトコル処理部２２ｃは、アプリケーション２１にて処理する受信データがあるか否かの判定を行う（ステップＳ４６）。処理する受信データがないと判定した場合は、受信処理を終了する。
　処理する受信データがある場合、TCPデータ処理部１８はソケット情報によって指定されているアプリケーション２１の受信バッファに書き込み、アプリケーション２１は受信データをディスク装置に格納する動作を実行する（ステップＳ４７）。
　次に、通信装置８１のアプリケーション２１からTCPセグメントを送信する処理を、図１４を参照して説明する。ここでは、アプリケーション２１から送信するとしたが、ソフトウェアプロトコル処理部２２ｃから送信する場合も同じである。
　まず、アプリケーション２１は、ソケット情報に送信する映像情報などの送信データを格納したバッファのアドレス及び長さなど、プロトコル処理を行うために必要なソケット情報を設定して、直接ハードウェアプロトコル処理部１２ｃへ通知する。
　次に、コントロールフラグ４１７のACKフラグ(=02)のみを設定すべきセグメントの場合は以下の送信処理が実行される。ソフトウェアプロトコル処理部２２ｃは、コントロールフラグのFIN、SYN、或いはRSTビットを設定すべきセグメントか否かの判定を行う（ステップＳ５１）。
　FIN、SYN、或いはRSTビットを設定すべきセグメントと判定した場合、ソフトウェアプロトコル処理部２２ｃのTCP制御処理部２９は、TCPシーケンス番号の制御やTCPヘッダの生成など、TCPの制御処理を行う（ステップＳ５２）。この様なケースは、アプリケーション２１からコネクションの確立や切断を要求された場合や、コントロールフラグのSYNビットが設定されたセグメントを受信した場合、TCPセグメントの応答処理を求める場合などで行われる。
　次に、ソフトウェアプロトコル処理情報生成部２４は、IPv4よりも上位のプロトコル処理が完了されたことを示す情報と、IPv4処理に必要な情報（始点IPアドレス２２１、終点IPアドレス２２２、及びプロトコル番号２１９）と、Ethernet(R)処理に必要な情報（始点MACアドレス１１２及び終点MACアドレス１１１）と、ペイロードとペイロードの長さの情報を含むプロトコル処理情報を生成する（ステップＳ５３）。
　続いて、このプロトコル処理情報がソフトウェアプロトコル処理情報生成部２４からハードウェアプロトコル処理再開部１４に伝達される。そして、ハードウェアプロトコル処理再開部１４は、ハードウェアでのプロトコル処理の開始を決定する（ステップＳ５４）。
　一方、FIN、SYN、或いはRSTビットを設定すべきセグメントでないと判定した場合、ハードウェアプロトコル処理部１２ｃはＴＣＰデータ処理を行う。上述したハードウェアプロトコル処理再開部１４から情報が入力された場合も、ハードウェアプロトコル処理部１２ｃはＴＣＰデータ処理を行う(ステップＳ５５)。ハードウェアプロトコル処理部１２ｃは、ソケット情報伝達部１９を介して受信したソケット情報からTCPヘッダの始点ポート番号４１１、終点ポート番号４１２、シーケンス番号４１３、確認応答番号４１４、コントロールフラグ４１７、ウィンドウサイズ４１８を設定する。また、ヘッダ長からデータオフセットを計算する。更に、TCPヘッダとデータからTCPチェックサム４１９を計算する。こうして得られたデータから、TCPヘッダが作成される。
　次に、IPv4処理部１６は、IPヘッダ（図３参照）のヘッダチェックサム２２０以外の値を設定する。またIPv4処理部１６は、ヘッダチェックサム２２０を計算して、チェックサムフィールドに設定する。
　続いて、Ethernet(R)処理部１５では、Ethernet(R)フレーム（図２参照）の始点MACアドレス１１２、終点MACアドレス１１１、及びタイプ１１３を設定する（ステップＳ５５）。
　最後に、ネットワークコントローラ１１はEthernet(R)フレームにＦＣＳ１１５を付加する。こうして作成されたEthernet(R)フレームは変調されて、ネットワーク７０を介して送信先装置に送信データが伝送される（ステップＳ５６）。
　このように、アプリケーション２１又はソフトウェアプロトコル処理部２２ｃから送信データをパケット送信する場合、まずTCPセグメントのコントロールフラグにACKビット以外のビットを設定すべきパケットかの判断が行われる。もしも、コントロールフラグのACKビットのみが設定されたセグメントである場合、全てハードウェアプロトコル処理部１２ｃによってプロトコル処理されることになる。よって、ソフトウェアプロトコル処理部２２ｃではプロトコル処理は行わない。
　一方、コントロールフラグのACK以外のビットを設定すべきセグメントである場合には、ソフトウェアプロトコル処理部２２ｃで少なくとも一部のプロトコル処理が行われる。この場合、ソフトウェアプロトコル処理情報生成部２４にて生成されたプロトコル処理情報を用いて、ハードウェアプロトコル処理部１２ｃがプロトコル処理を行うものである。このとき、プロトコル処理情報には、ソフトウェアプロトコル処理部２２ｃにてプロトコル処理が完了した部分を示す情報、及び得られた値などが含まれる。ハードウェアプロトコル処理部１２ｃでは、ソフトウェアプロトコル処理部２２ｃによって既に処理されたプロトコル処理については、処理しない。処理されなかったプロトコル処理のみが行われる。
　実施例２では、セッション確立に関するTCPの制御処理をソフトウェアプロトコル処理部２２ｃで行っているが、セッション状態がSYN-SENT状態又はSYN-RECEIVED状態からESTABLISHED状態への変更をハードウェアプロトコル処理部１２ｃで行ってもよい。これにより、セッション確立直後にデータが受信された場合にも、データを取りこぼすことなく受信することが可能となる。
　また、TCPの確認応答セグメントの送信処理をハードウェアプロトコル処理部１２ｃで行っているが、確認応答セグメントの送信間隔を開け、これをソフトウェアプロトコル処理部２２ｃで行ってもよい。これにより、確認応答セグメントを送信する回路を削減することができる。
　また、データの送信処理は、全てハードウェアプロトコル処理部１２ｃで行うとしているが、再送処理をソフトウェアプロトコル処理部２２ｃで行ってもよい。ロス率の低いネットワークでは再送処理の発生頻度が低いので、再送のための必要な回路を削減しながら高速なプロトコル処理を実現することが可能となる。
　また、受信処理において、シーケンス番号が連続しているセグメントの受信はハードウェアプロトコル処理部１２ｃで行い、不連続なセグメントの受信はソフトウェアプロトコル処理部２２ｃで行ってもよい。パケット順序の入れ替わりの発生頻度が低いネットワークでは、ハードウェアプロトコル処理部１２ｃの回路を簡単化し、高速なプロトコル処理を実現することが可能となる。
　更に、自装置のMACアドレスと相手装置のMACアドレスは、セッション情報を介してハードウェアプロトコル処理部１２ｃとソフトウェアプロトコル処理部２２ｃで共有したが、ハードウェアプロトコル処理部１２ｃが送信処理を行うときにIPアドレスからMACアドレスを参照できるようにしてもよい。この場合、ソフトウェアプロトコル処理部２２ｃにルーティングテーブルを備えることで実現できる。
　上述したように、本実施例の通信装置では、ソケット情報を用いてプロトコル処理を行うことでハードウェアプロトコル処理部１２ｃとソフトウェアプロトコル処理部２２ｃの状態が同期できる。これにより、稼働率の高いデータ処理をハードウェアプロトコル処理部１２ｃで行い、稼働率の低い制御処理をソフトウェアプロトコル処理部２２ｃで行うことができる。したがって、ハードウェアプロトコル処理部１２ｃの回路規模を抑え、さらに通信装置の送受信のスループットを大幅に向上させることができる。
　また、Ethernet(R)処理とIPv4処理とTCPデータ処理についてはハードウェアプロトコル処理部１２ｃで処理され、ソフトウェアプロトコル処理部２２ｃに同じ処理部を備える必要がないため、ソフトウェアサイズを削減することができる。
　本発明は、上記実施例に限定されるものではなく、発明の要旨を逸脱しない範囲で、種々、設計変更してもよい。また実施例１，２を適宜組み合わせてもよい。
　実施例の通信装置は、例えば汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することができる。また、実施例の通信装置に内蔵或いは外付けされたメモリ、ハードディスク、ＣＤ－Ｒ、ＣＤ－ＲＷ、ＤＶＤ－ＲＡＭ、ＤＶＤ－Ｒなどの記憶媒体などを適宜利用するのが好ましい。
　本発明によれば、ネットワーク関連装置へ適用することができる。
１、１ａ、１ｂ、１ｃ　ハードウェア処理部
２、２ａ、２ｂ、２ｃ　ソフトウェア処理部
１１、１１ａ、１１ｂ　ネットワークコントローラ
１２、１２ａ、１２ｂ　ハードウェアプロトコル処理部
１３、１３ａ　ハードウェアプロトコル処理情報生成部
１４、１４ｂ　ハードウェアプロトコル処理再開部
１５、１５ａ、１５ｂ　Ethernet（R）処理部
１６、１６ａ、１６ｂ　IPv4処理部
１７、１７ａ、１７ｂ　UDP処理部
１９　ソケット情報伝達部
２１、２１ａ、２１ｂ　アプリケーション
２２、２２ａ、３０、４０　ソフトウェアプロトコル処理部
２３、２３ａ　ソフトウェアプロトコル処理再開部
２４、２４ｂ　ソフトウェアプロトコル処理情報生成部
２５、２５ａ、２５ｂ　ARP処理部
２６、２６ａ、２６ｂ　IPv6処理部
２７、２７ａ、２７ｂ　ICMPv4処理部
２８、２８ａ、２８ｂ　DCCP処理部
２９　TCP制御処理部
３１　IPv4送信処理部
３２　Ethernet（R）送信処理部
４１　IPv4受信処理部
４２　Ethernet（R）受信処理部
７０　ネットワーク
８０、８０ａ　通信装置
２１１　バージョン
　２１２　ヘッダ長
　２１３　サービスタイプ
２１４　IPパケット長
２１５　識別子
２１６　コントロールフラグ
２１７　フラグメントオフセット
２１８　生存時間
２１９　プロトコル番号
２２０　ヘッダチェックサム
２２１　始点IPアドレス
２２２　終点IPアドレス
３１１、４１１　始点ポート番号
３１２、４１２　終点ポート番号
３１３　UDPパケット長
３１４　UDPチェックサム
４１３　シーケンス番号
４１４　確認応答番号
４１５　データオフセット
４１６　未使用（予約）
４１７　コントロールフラグ
４１８　ウィンドウサイズ
４１９　TCPチェックサム
４２０　緊急ポインタ

Claims (10)

  1. 　受信データのフレームに対しハードウェアによるプロトコル処理を行うハードウェアプロトコル処理部と、
    　前記ハードウェアプロトコル処理部とは異なるハードウェアで実現され、前記受信データのフレームに対しソフトウェアによるプロトコル処理を行うソフトウェアプロトコル処理部と、
    　前記ハードウェアプロトコル処理部によるプロトコル処理で処理が完了した部分を示す情報と、前記ハードウェアプロトコル処理部によるプロトコル処理によって得られた値を含むプロトコル処理情報を生成するハードウェアプロトコル処理情報生成部と、
    　前記プロトコル処理情報を用いて、前記ハードウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ソフトウェアプロトコル処理部に行わせるソフトウェアプロトコル処理再開部と、
    を具備することを特徴とする通信装置。
  2. 　前記プロトコル処理情報は、前記ハードウェアプロトコル処理部で処理が完了した層の上位層のプロトコル識別子を含み、
    前記ソフトウェアプロトコル処理再開部は、上位層のプロトコル処理を前記ソフトウェアプロトコル処理部に行わせることを特徴とする請求項１に記載の通信装置。
  3. 　送信データのフレームに対しソフトウェアによるプロトコル処理を行うソフトウェアプロトコル処理部と、
    　前記ハードウェアプロトコル処理部とは異なるハードウェアで実現され、前記送信データのフレームに対しハードウェアによるプロトコル処理を行うハードウェアプロトコル処理部と、
    　前記ソフトウェアプロトコル処理部によるプロトコル処理で処理が完了した部分を示す情報と、前記ソフトウェアプロトコル処理部によるプロトコル処理で得られた値を含むプロトコル処理情報を生成するソフトウェアプロトコル処理情報生成部と、
    　前記プロトコル処理情報を用いて、前記ソフトウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ハードウェアプロトコル処理部に行わせるハードウェアプロトコル処理再開部と、
    を具備することを特徴とする通信装置。
  4. 　前記プロトコル処理情報は、前記ソフトウェアプロトコル処理部で処理が完了した層の下位層のプロトコル識別子を含み、
    前記ハードウェアプロトコル処理再開部は、下位層のプロトコル処理を前記ハードウェアプロトコル処理部に行わせることを特徴とする請求項３に記載の通信装置。
  5. 　受信データのフレーム及び送信データのフレームに対しハードウェアによるプロトコル処理を行うハードウェアプロトコル処理部と、
    前記ハードウェアプロトコル処理部とは異なるハードウェアで実現され、前記受信データのフレーム及び前記送信データのフレームに対しソフトウェアによるプロトコル処理を行うソフトウェアプロトコル処理部と、
    受信のときに、前記ハードウェアプロトコル処理部によるプロトコル処理で処理が完了した部分を示す情報と、前記ハードウェアプロトコル処理部によるプロトコル処理によって得られた値を含むプロトコル処理情報を生成するハードウェアプロトコル処理情報生成部と、
    受信のときに、前記ハードウェアプロトコル処理情報生成部のプロトコル処理情報を用いて、前記ハードウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ソフトウェアプロトコル処理部に行わせるソフトウェアプロトコル処理再開部と、
    送信のときに、前記ソフトウェアプロトコル処理部によるプロトコル処理で処理が完了した部分を示す情報と、前記ソフトウェアプロトコル処理部によるプロトコル処理によって得られた値を含むプロトコル処理情報を生成するソフトウェアプロトコル処理情報生成部と、
    送信のときに、前記ソフトウェアプロトコル処理情報生成部のプロトコル処理情報を用いて、前記ソフトウェアプロトコル処理部で処理が未完了となっているプロトコル処理を前記ハードウェアプロトコル処理部に行わせるハードウェアプロトコル処理再開部と、
    を具備することを特徴とする通信装置。
  6. 　前記ハードウェアプロトコル処理部は、Ethernet処理部、IP処理部、及びUDP処理部を有し、
    前記プロトコル処理情報は、前記ハードウェアプロトコル処理部の各処理の完了の有無、始点MACアドレス、終点MACアドレス、タイプ、始点IPアドレス、終点IPアドレス、長、プロトコル番号、ペイロードの内少なくとも１つを含み、
    前記ソフトウェアプロトコル処理部は、通信プロトコルの内、前記Ethernet処理部、前記IP処理部、及び前記UDP処理部以外のプロトコル処理部を備えることを特徴とする請求項５に記載の通信装置。
  7. 　前記ハードウェアプロトコル処理部は、Ethernet処理部、IP処理部、UDP処理部、及びTCPデータ処理部を有し、
    前記プロトコル処理情報は、前記ハードウェアプロトコル処理部の各処理の完了の有無、TCPのコントロールフラグ、シーケンス番号、確認応答番号、始点IPアドレス、終点IPアドレス、始点ポート番号、終点ポート番号の内少なくとも１つを含み、
    前記ソフトウェアプロトコル処理部は、TCP処理の内、TCPセグメントのコントロールフラグのSYN、FIN、或いはRSTフラグ処理を行うTCP制御処理部を備えることを特徴とする請求項５に記載の通信装置。
  8. 　前記ハードウェアプロトコル処理部と前記ソフトウェアプロトコル処理部の間に、ソケット情報を伝達するソケット情報伝達部を有し、
    前記ハードウェアプロトコル処理部或いは前記ソフトウェアプロトコル処理部は、前記ソケット情報を用いてプロトコル処理を行うことを特徴とする請求項５に記載の通信装置。
  9. 　前記TCPデータ処理部は、シーケンス番号が連続なセグメントの受信を行い、
    前記ソフトウェアプロトコル処理部はシーケンス番号が不連続なセグメントの受信処理を行うことを特徴とする請求項７に記載の通信装置。
  10. 　前記TCPデータ処理部は、再送以外のデータ送信処理を行い、
    前記ソフトウェアプロトコル処理部は再送のデータ送信処理を行うことを特徴とする請求項７に記載の通信装置。
PCT/JP2009/004651 2009-09-16 2009-09-16 通信装置 WO2011033562A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2011531639A JP5481485B2 (ja) 2009-09-16 2009-09-16 通信装置とそれを用いた受信処理方法及び送信処理方法
PCT/JP2009/004651 WO2011033562A1 (ja) 2009-09-16 2009-09-16 通信装置
US13/422,587 US8943214B2 (en) 2009-09-16 2012-03-16 Communication apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/004651 WO2011033562A1 (ja) 2009-09-16 2009-09-16 通信装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/422,587 Continuation US8943214B2 (en) 2009-09-16 2012-03-16 Communication apparatus

Publications (1)

Publication Number Publication Date
WO2011033562A1 true WO2011033562A1 (ja) 2011-03-24

Family

ID=43758191

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/004651 WO2011033562A1 (ja) 2009-09-16 2009-09-16 通信装置

Country Status (3)

Country Link
US (1) US8943214B2 (ja)
JP (1) JP5481485B2 (ja)
WO (1) WO2011033562A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9100332B2 (en) 2011-02-28 2015-08-04 Kabushiki Kaisha Toshiba Data transmitting device, data communicating device, and computer readable medium
US9866639B2 (en) 2014-03-13 2018-01-09 Kabushiki Kaisha Toshiba Communication apparatus, information processor, communication method, and computer-readable storage medium
US9961147B2 (en) 2014-03-13 2018-05-01 Kabushiki Kaisha Toshiba Communication apparatus, information processor, communication method, and computer-readable storage medium
JP2018097429A (ja) * 2016-12-08 2018-06-21 キヤノン株式会社 通信装置、その制御方法、およびプログラム
US10897426B2 (en) 2013-09-30 2021-01-19 Mitsubishi Electric Corporation Reception apparatus and communication apparatus

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000235536A (ja) * 1999-02-15 2000-08-29 Fuji Xerox Co Ltd データ通信方式及び装置
JP2001339462A (ja) * 2000-05-29 2001-12-07 Toshiba Corp 通信プロトコル処理方法および通信プロトコル処理装置
JP2003308262A (ja) * 2002-04-08 2003-10-31 Wiznot Corp ハードウェアプロトコルプロセシングロジックで実現されたインタネット通信プロトコル装置、及びその装置を用いたデータ並列処理方法
JP2009055134A (ja) * 2007-08-23 2009-03-12 Ricoh Co Ltd 通信制御装置、通信制御方法及び通信制御プログラム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6434620B1 (en) 1998-08-27 2002-08-13 Alacritech, Inc. TCP/IP offload network interface device
JP3491626B2 (ja) * 2001-05-29 2004-01-26 ソニー株式会社 送信装置、受信装置、及び送受信装置
US7389462B1 (en) * 2003-02-14 2008-06-17 Istor Networks, Inc. System and methods for high rate hardware-accelerated network protocol processing
US8549345B1 (en) * 2003-10-31 2013-10-01 Oracle America, Inc. Methods and apparatus for recovering from a failed network interface card
KR20050049864A (ko) * 2003-11-24 2005-05-27 삼성전자주식회사 소프트웨어 프로토콜 스택과 하드웨어 프로토콜 스택을사용한 멀티미디어 통신 장치 및 그 통신 방법
JP2006031145A (ja) 2004-07-13 2006-02-02 Matsushita Electric Ind Co Ltd データ受信装置
KR100530856B1 (ko) * 2005-05-11 2005-11-23 (주) 위즈네트 임베디드 시스템을 위한 고속 데이터 처리 기능을 가지는통신방법 및 그 장치
US7760741B2 (en) * 2005-05-18 2010-07-20 International Business Machines Corporation Network acceleration architecture
JP2007142582A (ja) 2005-11-15 2007-06-07 Canon Inc データ通信装置、データ通信方法、プログラム及び記憶媒体
JP5587530B2 (ja) 2007-03-29 2014-09-10 日本電気株式会社 エンジン・プロセッサ連携システム及び連携方法
US8054779B2 (en) * 2007-05-08 2011-11-08 Microsoft Corporation Simultaneous wireless support in software defined radio
JP4964683B2 (ja) 2007-06-18 2012-07-04 株式会社リコー 通信装置およびプログラム
JP5049834B2 (ja) 2008-03-26 2012-10-17 株式会社東芝 データ受信装置、データ受信方法およびデータ処理プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000235536A (ja) * 1999-02-15 2000-08-29 Fuji Xerox Co Ltd データ通信方式及び装置
JP2001339462A (ja) * 2000-05-29 2001-12-07 Toshiba Corp 通信プロトコル処理方法および通信プロトコル処理装置
JP2003308262A (ja) * 2002-04-08 2003-10-31 Wiznot Corp ハードウェアプロトコルプロセシングロジックで実現されたインタネット通信プロトコル装置、及びその装置を用いたデータ並列処理方法
JP2009055134A (ja) * 2007-08-23 2009-03-12 Ricoh Co Ltd 通信制御装置、通信制御方法及び通信制御プログラム

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9100332B2 (en) 2011-02-28 2015-08-04 Kabushiki Kaisha Toshiba Data transmitting device, data communicating device, and computer readable medium
US10897426B2 (en) 2013-09-30 2021-01-19 Mitsubishi Electric Corporation Reception apparatus and communication apparatus
US9866639B2 (en) 2014-03-13 2018-01-09 Kabushiki Kaisha Toshiba Communication apparatus, information processor, communication method, and computer-readable storage medium
US9961147B2 (en) 2014-03-13 2018-05-01 Kabushiki Kaisha Toshiba Communication apparatus, information processor, communication method, and computer-readable storage medium
JP2018097429A (ja) * 2016-12-08 2018-06-21 キヤノン株式会社 通信装置、その制御方法、およびプログラム

Also Published As

Publication number Publication date
JP5481485B2 (ja) 2014-04-23
JPWO2011033562A1 (ja) 2013-02-07
US20120233344A1 (en) 2012-09-13
US8943214B2 (en) 2015-01-27

Similar Documents

Publication Publication Date Title
US7171489B2 (en) Method to synchronize and upload an offloaded network stack connection with a network stack
US7007103B2 (en) Method to offload a network stack
US7526577B2 (en) Multiple offload of network state objects with support for failover events
JP4668207B2 (ja) 移動通信システムにおけるパケット再送方法及びそのプログラムが記録されたコンピュータで読取り可能な記録媒体
US7716731B2 (en) Method for dynamically tunneling over an unreliable protocol or a reliable protocol, based on network conditions
US7773546B2 (en) System and method for a software-based TCP/IP offload engine for digital media renderers
JP2011024238A (ja) 移動通信システムにおけるパケット再送方法及びそのプログラムが記録されたコンピュータで読取り可能な記録媒体
JP2006261873A (ja) パケット転送装置およびその転送制御方式
US20070076618A1 (en) IP communication device and IP communication system therefor
WO2010097978A1 (ja) 通信装置、方法及びプログラム
WO2018128597A1 (en) Cross-device segmentation offload
JP5481485B2 (ja) 通信装置とそれを用いた受信処理方法及び送信処理方法
US20110225308A1 (en) Data communication apparatus and method
JP4658546B2 (ja) フェイルオーバーイベントをサポートするネットワーク状態オブジェクトの多重オフロード
US8578040B2 (en) Method, system and article for client application control of network transmission loss tolerance
WO2019196853A1 (zh) Tcp加速方法及装置
JP2006253867A (ja) フレーム伝送システム及びフレーム伝送方法
Herrero et al. Network and Transport Layers
TWI652953B (zh) 重排方法及其裝置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09849422

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011531639

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09849422

Country of ref document: EP

Kind code of ref document: A1