KR100725921B1 - Apparatus for TCP and UDP Socket Search - Google Patents

Abstract

1. TECHNICAL FIELD OF THE INVENTION

The present invention relates to a socket retrieval device of a transmission control protocol and a user datagram protocol.

2. The technical problem to be solved by the invention

The present invention uses a binary search algorithm to reduce the socket search time in hardware that allows the number of sockets up to 10,000, and implements the binary search algorithm in hardware to help to speed up the socket search, In case of TCP and UDP protocols, socket IDs are supported by supporting all functions such as creation, removal, retrieval, and listen / connect functions necessary for managing binary trees. Its purpose is to provide a socket retrieval device for socket retrieval of TCP and UDP to perform fast protocol processing by reducing the time required to locate a.

3. Summary of Solution to Invention

The present invention relates to a socket retrieval apparatus of a transmission control protocol (TCP) and a user datagram protocol (UDP), in which command information received from a processor is interpreted and transmitted to a branch table managing means and a tree table managing means. Master management means for receiving results from table management means and tree table management means and reporting the results to the processor; Branch table management means for receiving a command from the master management means and managing a branch table; And tree table management means for managing the binary tree.

4. Important uses of the invention

The present invention is used in network systems and the like.

TCP, UDP, Socket Search, C10K, Branch, Node, Binary Tree, Processor, TOE

Description

Apparatus for TCP and UDP Socket Search for Transmission Control Protocol and User Datagram Protocol

1 is a diagram illustrating an embodiment of a socket retrieval apparatus for TCP and UDP according to the present invention;

2 is a block diagram of an embodiment of a socket retrieval apparatus for TCP and UDP according to the present invention;

3 is a detailed block diagram of an embodiment of the master module of FIG.

4 is an explanatory diagram of one embodiment of the command and result register of FIG. 3;

FIG. 5 is a diagram explaining another embodiment of the command and result register of FIG. 3; FIG.

6 is a detailed block diagram of an embodiment of a branch table module of FIG. 2.

7 is a detailed block diagram of an embodiment of the tree table module of FIG. 2;

FIG. 8 is a flowchart illustrating a process of adding a tree node in the tree table module of FIG. 7.

9 is a flowchart illustrating a tree node search process in the tree table module of FIG. 7.

10A and 10B are flowcharts illustrating an example of deleting a tree node in the tree table module of FIG. 7.

* Explanation of symbols for the main parts of the drawings

201: master module 202: branch table module

203: Tree Table Module

The present invention provides a method for retrieving a socket ID of a packet received during transmission control protocol (hereinafter referred to as "TCP") and user datagram protocol (hereinafter referred to as "UDP") processing. The present invention relates to a socket retrieval device, and more particularly, to a socket retrieval device for TCP and UDP for packet processing in a TCP offload engine using hardware for accelerating TCP.

TCP is a connection-oriented protocol. One port of a host device and one port of a counterpart device are connected to each other, and communication is divided into one socket. That is, the source IP, the destination IP, the source port, and the destination port are combined to form one socket. When one such socket is configured, the communication on this connection is distinguished from other sockets. Here, there are various characteristics such as window size and maximum segment size, and the block storing these values is called as TCB (TCP Control Block) or CCB (Connection Control Block). This is called a Socket Resource Block.

When a packet is received, the corresponding socket should be found by looking at IP and port information of the header information of the received packet. In addition, the socket resource block corresponding to the socket ID may be read and appropriate processing corresponding thereto may be required. However, as the number of sockets increases, finding the socket ID also takes considerable time.

Until now, most protocol processing has been done in the central processing unit (CPU). In other words, the protocol is processed by the central processing unit (CPU) using software, and the socket is searched mainly by using a hash function.

Most TCP Offload Engines developed to reduce the CPU's load also include processors, which use a hash function to retrieve sockets. Is carried out. However, if there are many connected sockets, the number of sockets with the same result of this hash function will increase, resulting in a significant number of memory accesses and comparisons. These operations on the processor take a lot of time and consequently have a problem of degrading performance.

As a conventional technology, in the case of the TCP offload engine (TOE) developed by "Alacritech", a fast-path is distinguished by distinguishing a slow-path and a fast-path. ) Uses a hash function and an internal memory cache for fast searching, but this also allows only 4 sockets with the same result. Therefore, there was a problem that does not support the search for all sockets.

The present invention has been proposed in order to solve the above problems, by using a binary search (Binary Search) algorithm to reduce the socket search time in hardware that allows the number of sockets up to 10,000, by implementing the binary search algorithm in hardware It helps to speed up socket search, and for TCP and UDP protocols, it is necessary to create, remove, and search sockets and connect / connect functions for sockets needed for binary tree management. Its purpose is to provide a socket retrieval device for socket retrieval of TCP and UDP for fast protocol processing by reducing the time to find the socket ID by supporting all functions.

Other objects and advantages of the present invention can be understood by the following description, and will be more clearly understood by the embodiments of the present invention. Also, it will be readily appreciated that the objects and advantages of the present invention may be realized by the means and combinations thereof indicated in the claims.

The apparatus of the present invention for achieving the above object is a socket retrieval apparatus of Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), the following branch table management means and tree table management by analyzing the command information received from the processor Master management means for delivering instructions to the means and for receiving the results from the branch table management means and the tree table management means and reporting the results to the processor; Branch table management means for receiving a command from the master management means and managing a branch table; And tree table management means for managing the binary tree.

The above objects, features and advantages will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, whereby those skilled in the art may easily implement the technical idea of the present invention. There will be. In addition, in describing the present invention, when it is determined that the detailed description of the known technology related to the present invention may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a diagram illustrating an embodiment of a socket search apparatus for TCP and UDP according to the present invention, and illustrates a binary tree method, which is a memory management method according to a search algorithm.

The present invention employs a binary tree scheme as a search algorithm.

When the TCP packet is received, the packet includes a source port, a destination port, a source IP, and a destination IP as information stored therein.

The original socket ID should be configured using these four pieces of information, but the destination IP (in contrast, the source IP from the perspective of the receiving TCP offload engine (TOE)) is unusual. Except in the case of your own IP (IP), take the remaining three to find the ID (ID) of the socket.

In the case of TCP, when operating as a server, it may wait in a waiting queue until a complete connection is established. In this case, the destination port (in contrast, the entry of the receiving TCP offload engine (TOE)). In the case of Source port, the only information is the information, which may overlap with the completed socket.

Therefore, it is necessary to distinguish the socket from which the connection is completed.

The TCP Offload Engine (TOE) being designed manages a total of 1,026 Trees for efficiency. One of them is UDP, one is TCP waiting queue, and the other 1,024 is TCP.

As shown in FIG. 1, a branch table 110 represents a socket ID 111-11n located at a root of each tree.

The branch table 110 functions as a kind of hash table.

In the case of UDP and TCP Waiting Queues, there is no need for dividing criteria because there is one each. However, in case of connected TCP, a basis for dividing 1,024 trees and a hash function are required. There are many such hash functions, and they must be determined to be distributed relatively evenly to improve performance.

In the present invention, only the lower 10 bits of the IP are used.

The reason for creating the branch table 110 using an index of 10 bits is as follows.

As with the hash function, the first advantage is that classification can be done using indexes, which saves binary search time rather than using a single root. In addition, it can be used to save space required for storing information.

Since TCP Offload Engine (TOE) assumes 10,000 connections (C10K), the current socket storage is 10,240.

There are three pieces of information needed for the search: the source port, the destination port, and the destination IP (in this case, the entry of the TCP offload engine (TOE)). ) Is required.

In the following description, in order to avoid confusion, a host port uses its own port number, a remote port uses its own port number, and a remote IP uses its partner's IP number.

14 bits are required to display 10,240 socket IDs, and 28 bits are required for binary tree management, which requires two of a high pointer and a low pointer. ) Is required. Thus, a total of 92 bits per socket is required.

Since 10,240 socket spaces are required, the total storage space for tree management requires 92 * 10,240 bits.

If a part of 64-bit information is cut out and used as an index of the branch table 110, the storage space for tree management is reduced by that amount. Of course, on the contrary, the space for the branch table 110 is increased.

If the number of bits to be truncated is "n", the storage space for tree management can be saved as much as 10,240 * n bits, and the space of the branch table 110 to increase is 2 ⁿ * 14 bits. Therefore, the storage space that can be saved is as shown in Equation 1 below.

y = 10,240n-14 ²ⁿ

Since the function has a maximum value when n = 10, a branch table 110 is configured using 10 bits.

2 is a block diagram of an embodiment of a socket search apparatus for TCP and UDP according to the present invention.

As shown in FIG. 2, the TCP and UDP socket retrieval apparatus according to the present invention is connected to a processor, interprets the command information received from the processor and the command register, and transfers the command to other modules. A master module 201 for receiving results from the processor and reporting the results to the processor, a branch table module 202 for managing branch tables, and a tree table module for managing binary trees (Tree Table Module) 203.

Master module 201 has a processor interface.

It is connected to two processor (send / receive) buses and has command and result registers that receive instructions and inform the results.

It interprets the instructions received from the processor and passes the instructions to other modules. It also passes the information received in the instruction register. It also takes the results from other modules and reports the results to the processor.

The branch table module 202 is a module for managing the described branch tables, and the tree table module 203 is a module for managing binary trees.

The present invention proposes an implementation method for quickly processing a socket search in the design of the TCP offload engine (TOE) for TCP protocol acceleration.

The socket retrieval apparatus according to the present invention is designed for use in a TCP offload engine (TOE) that processes protocols using two transmit / receive processors.

The retrieval of sockets is required by the receiving processor, but the sending processor is responsible for entering data into the retrieval hardware to enable this retrieval. In addition, it is designed to be involved in socket creation so that the transmitting processor can easily find the socket resource block using the socket ID in communication with the host processor.

In general, the TCP offload engine (TOE) mainly deals with the TCP protocol. However, the UDP protocol also has a socket using a port number, and the socket offloading function is also included so that the TCP offload engine (TOE) can handle the UDP protocol as well. In addition, it is possible to search server sockets in the TCP Listen state so that the TCP Offload Engine (TOE) can control almost all TCP connections.

3 is a detailed block diagram of an embodiment of the master module of FIG. 2.

As shown in FIG. 3, the master module interfaces with the processor to store a command information from a command and result register 301 and the command and result register 301. A schedule state machine (Schedule FSM) 302 for analyzing the received command information and requesting the corresponding command, and analyzing the command information to select one of command register information of a receiving processor and command register information of a sending processor, and An Info Holder 303 for selecting an address to use in the module 202, and an Allocation Table 304 for receiving a seat allocation request from the Schedule State Machine 302 and assigning an address value. It includes.

The command and result register 301 is a set of registers that interface with the transmitting and receiving processors.

4 is a diagram illustrating an example of the instruction and result register of FIG. 3, and illustrates a register set used in a transmission processor.

FIG. 5 is an explanatory diagram of another embodiment of the instruction and result register of FIG. 3 and illustrates a register set used by a receiving processor.

Hereinafter, the master module 201 will be described in more detail with reference to FIGS. 3 to 5.

The lower 8 bits of "Offset 0" of each set of command registers 410, 510 are used as the command code.

The TCP / UDP protocol goes through several steps before it is created, operated, and destroyed.

First, in the case of UDP, it operates in the order of Create, Bind, Packet Transmit, and Delete.

Create is the process of creating a socket.

Bind allocates a port to a socket, and passes a packet through a state in which a socket is removed by deleting.

TCP depends on whether you are acting as a server or a client.

Create and Bind are the same, but if it is a server, it performs a process of Listen and Accept, and if it is a client, it connects.

Then, in both cases, the socket is removed by sending and receiving packets and deleting them.

Create is a command for the user to ask the system for the handle of the socket to use.

Typically this is not the same ID as the socket used inside the system. However, the socket retrieval apparatus according to the present invention receives a Create command and informs one of the empty values among the values between 0 and 10,239 to return this to the handle of the socket to the user. By doing so, the handle of the socket used when a user issues a command becomes the socket ID, and it can be used as an index to get the socket resource block without any conversion.

In this case, the tree structure does not change (for example, command code 0x20 of FIG. 4).

An allocation table 304 of FIG. 3 allows the processing of the create command.

When a Create command comes into the command and result register 301, the schedule state machine 302 analyzes and requests that a seat be allocated to the Allocation Table 304.

When the allocation request is received, the allocation table 304 outputs the smallest unused value among the values between 0 and 10,239, or outputs that there is no more empty space.

If a value is output, this value is written to the command and result register 301 so that the sending processor uses that value as the Socket ID.

The allocation table 304 is a hardware implementation of a function similar to the file allocation table of the operating system (OS), and only one space allocation is possible at a time, but it can be processed at a high speed. It's hardware.

When the bind function of UDP is called, UDP enters the normal operating state. Therefore, socket information should be added to a tree structure by using a host port number so that a packet can be searched when a packet is received. At this time, the tree to be used is one tree for UDP (for example, command code 0x09 of FIG. 4).

In the case of TCP, even if the bind function is called, it is not in the normal operation state.

First, in the case of a client, a connect function must be called to know the IP and port number of the other party. Therefore, when the Connect function is called, it must be added to the socket information in the tree structure by using the other's IP, port number, and its own port number. In this case, the tree used is a tree having the lower 10 bits of the opposite IP of the 1,024 TCP trees as the root index (for example, in FIG. 4). Command code 0x08).

Secondly, in the case of Server, the Listen function is called first. When the listen function is called, the socket enters a wait state. In this case, the other party's IP and port number are unknown. However, the received packet should be searched using its port number. Therefore, socket information should be added to the tree structure using only its port number. In this case, the tree to be used is one wait tree for a socket in a TCP wait state (for example, command code 0x0A of FIG. 4).

Next, if the packet is received from the other party, the connection request packet is not known until the IP and port numbers of the other party are known. The information of this received packet is delivered to the transmitting processor once for uniformity of operation, and then the transmitting processor uses a method of adding socket information to the tree structure. At this time, the sending processor creates another new socket, that is, executes an operation such as Create once more, and uses 1,024 IPs, port numbers, and port numbers of the other party. The socket information is added to one tree of the two TCP trees (for example, command code 0x08 of FIG. 4).

The socket in the wait tree remains in use until a remove command is received from the user and is used for processing a newly received connection request packet.

When a user requests to delete a socket, the node is removed from the tree structure where the socket information is stored, and when the user requests the removal with the socket ID in the allocation table 304, Releases the allocated space so that the ID can be used again the next time a Create command is received. In this case, the command code used varies depending on the case.

For the removal of the TCP socket that is connected and working, use the command code "0x14". For UDP sockets, use "0x15" and for the TCP Listen state, use "0x16". Tree) can be separated and removed.

Although not common, for TCP client sockets that do not receive unbound UDP or Connect commands, only the removal from the Allocation Table 304 is performed using the "0x10" code. Do it.

The above is the instructions given by the transmitting processor. If the packet is received, if the received packet is a TCP connection request packet, the socket is searched in the wait tree (for example, command code 0x02 of FIG. 5), and UDP is used. If the packet is a UDP tree (for example, command code 0x01 of FIG. 5), and if it is another general TCP packet, the search should be performed in the TCP tree (for example, command code 0x04 of FIG. 5).

This is a command issued by the receiving processor. The socket search apparatus according to the present invention responds to the command with a socket ID, or informs that there is no corresponding socket.

The result register of the command and result register 301 has two of both transmission and reception success (result code 0x02), failure (result code 0x03), and code (0x01) indicating that processing is in progress.

For the result code of the sending processor, the Socket ID (Sock_ID) field has a valid value when showing a successful result for the Create command, and for the receiving processor, every command is a search, so always a socket ID when showing a successful result. (Sock_ID) has a valid value.

When an instruction is issued to the instruction and result register 301, it is passed to the schedule state machine 302 and the info holder 303.

The schedule state machine 302 makes a request to the Allocation Table 304 if the command is a socket create and remove command, and to the Tree Table Module 203 for other commands. You will be asked. In the case of a remove command, both requests are made.

The info holder 303 selects one of the information of the instruction register of the receiving processor and the information of the transmitting processor based on the instruction information. In addition, an address to be used in the branch table module 202 is selected. It then decides whether to search the tree using both IP and Port information or to search the tree using only the host port. These values will persist until the command completes.

FIG. 6 is a detailed block diagram illustrating an example of a branch table module of FIG. 2.

As shown in FIG. 6, the branch table 601 has a total of 1,026 entries in the memory block. The value of each entry has a socket ID located at the root of the selected tree.

"BT_Rdata" 603 is an output value of the branch table 601 which is a memory block.

The socket identifier comparator 602 compares the value of the socket ID to the command and result register 301 with the value of "BT_Rdata" 603, which is the output of the branch table 601. It is a block that finds whether the two match or whether the value "BT_Rdata" 603 is null. Currently, the null value uses a 14 bit "3FF" value, and for this purpose, the value of the branch table 601 is filled with all bits "1" at initialization.

FIG. 7 is a detailed configuration diagram of an embodiment of the tree table module of FIG. 2, and illustrates an internal form of a tree table module 203 that occupies the largest portion of the present invention.

The tree table 701 is a block of memory that contains socket information and pointer information of a binary tree.

The read state machine 702 and the write state machine 703 read and update tree information in the tree table 701 which is a memory block, and manage the tree.

If the read state machine 702 receives a command to find data and then needs to update, the read state machine 703 issues a command to the write state machine 703 to update the tree information.

The write state machine 703 may also send a write request signal to the branch table 601 of the branch table module 202.

Current_data 706 is a register that temporarily stores information read from the tree table 701.

Prev_data 708 stores the Current_data 706 value again when the Current_data 706 value is changed, and Mother_Data 707 is a register that stores the Current_data 706 value according to the instruction of the read state machine 702. Here, "Sock_info" of Mother_Data (707) is 54-bit data created by attaching a host port, a remote port, and a remote IP (22 bits). As two values, and compares the values in the binary tree.

"Low_pt" and "high_pt" of Mother_Data 707 indicate pointer values of two child nodes of the tree, which are IDs of sockets.

The calculator 705 informs the read state machine 702 of various results by using information entered into the command register of the command and result register 301 and information read from the tree table 701. The result is to determine whether it matches "Sock_info" or is larger or smaller, and whether "low_pt" and "high_pt" are null or match the socket ID in the command register, etc. will be.

The tree record data generator (Tw_data_Generator) 704 generates a value to be recorded when the tree table 701 needs to be updated. In this case, the tree write data generator 704 and the write state machine 703 are not involved in the case of a search which is a command of the receiving processor.

According to the command, the tree table module 203 needs to do three things: add a node, delete a node, and search.

Adding or deleting a node is an operation according to a command issued by a transmitting processor, and a search is an operation according to a command issued by a receiving processor. The procedures for these three operations are as follows. In order to implement binary tree management in hardware, this procedure stores data in register values and determines the read / write address and write data of the memory block.

FIG. 8 is a flowchart illustrating a process of adding a tree node in the tree table module of FIG. 7.

First, a branch table (B_add) 601 is first read (801). Here, the address input as "B_add" varies depending on the type of command. That is, in case of connected TCP socket, it becomes the lower 10 bits of remote IP, and in case of TCP socket in listen state waiting for connection, the address for Wait Branch, UDP Is the address for the UDP branch.

Next, a comparison is made between the read value BT_Rdata and the socket ID ID to be added now (802). In the normal case, the read value BT_Rdata may not be the same as the socket ID (sock_id) to be added (803). If this value is null, since there are no sockets currently stored in the tree, the socket ID (ID) to be added now is stored at the corresponding address of the branch table (601) (804), and the tree table (Tree) The initial value is written into the corresponding socket ID position of the table 701 (805). The high pointer and low pointer values of the initial value are null values, and other 54-bit " Sock_Info " information is only inputted with the host port number. Or, record all the Host Port, Remote Port, and Remote IP. Here, the format "A / B / C" recorded in "T_W_data" 805 means "Sock_Info / Low Pointer / High Pointer".

As a result of the comparison 802, if the "BT_Rdata" value is not null, the tree is searched using the value. That is, "T_R_add = BT_Rdata" 806.

The value of "Sock_Info" is larger than the read tree node, the high pointer is null (807), or the value is smaller, and the low pointer is null. If it is NULL (808) is a case that finds a node that can be added (Node). In this case, the socket ID received by the command is stored in a pointer value, and an initial value is written in the corresponding socket ID location (809, 810). If the "Sock_Info" value is larger and the high pointer is not null (811) or if the value is smaller and the low pointer is null (812), the " T_R_add "is inserted to continue searching the memory constituting the tree.

Here, when comparing the "Sock_Info" value, all 54 bit values are compared in the case of the connected TCP socket, and in all other cases (UDP and TCP queue), only the host port value is compared.

In the flowchart, the result of empty and full means when the pointer value of the child node is null or not.

9 is a flowchart illustrating a tree node search process in the tree table module of FIG. 7.

The search does not change the tree structure.

First, a branch table is read (901). Similarly, the address entered as "B_add" depends on the type of command. That is, in case of connected TCP socket, it becomes the lower 10 bits of remote IP, and in case of TCP socket in listen state waiting for connection, the address for Wait Branch, UDP Is the address for the UDP branch.

Next, it is checked whether the "BT_Rdata" value is a null value (902).

If the value of "BT_Rdata" is null, the search fails because there is no socket currently stored in the tree (903). If not null, the value is searched for the tree (T_R_add = BT_Rdata) (904).

When the "Sock_Info" value is matched with the read tree node (905), the current read socket ID value 709 may be returned as a result (906).

If no match is found, then the search fails (907, 908).

10A and 10B are flowcharts illustrating an example of deleting a tree node in the tree table module of FIG. 7.

First, a branch table is read (1001). Then, the "BT_Rdata" value and the "sock_id" value are compared (1002).

As a result of the comparison (1002), if the BT_Rdata value is null, there is no node to delete because there is no socket stored in the current tree (1003). If this value matches the socket ID (sock_id) to be deleted, an indication is made that root should be removed (Set [root_matched]) (1004).

The next thing to do is to find the mother node of the node that needs to be deleted.

The tree is searched using the value of BT_Rdata (1005). In this case, the high pointer and low pointer values are compared with the socket ID to be deleted along with the comparison made at the time of addition or search. If a match is found, the result of the high match and the low match is shown (1006 and 1007).

Compared to the tree node read, the Sock Info value is larger, the high pointer matches the socket ID, or the Sock Info value is smaller, and the low pointer is the socket ID. ) Matches the parent node of the node to be deleted. At this time, the socket ID value 709 and the data 706 are stored in the mother_id 710 and the mother_data 707, and the high child is deleted or the low child of the mother node is deleted. child) is also checked (delete_position <= high or low) (1008, 1009). Here, if BT_Rdata has already matched, it can be determined that the operation up to this point is completed.

Next, read the value of the node to delete (1010, 1011, 1012).

When there is no child node or only one child node in the node to be deleted (1013), the ID (pointer value) of the child node is stored in the child_id 711 (1015 and 1016). This can be done by connecting directly to the parent node.

However, if there are two child nodes in the node to be deleted, the smallest value among the subtrees of the high node or the largest value among the subtrees of the low node should be brought to the position of the node to be deleted. In other words, you need to connect to the mother node. Here, the smallest value among the subtrees of the high node is obtained. In this case, since the child pointer of the deleted node must be recorded in the child pointer of the imported node, the value is stored in the value of branch_id 712 (1014).

The high node is read (1017) to detect if a low node exists (1018).

The search result 1018 stores the current ID value in the child_id 711 because the node should be connected to the mother node if it does not exist (1019). In addition, a low pointer value stored in the branch_id 712 is connected to a low tree.

As a result of the search (1018), if there is a low node, the low node is read (1020) and the tree follows the low pointer until there is no low node. Search for (1021). In this case, since the parent node of the node where the low node does not exist must be stored, the previous_address 713 and the data 708 are always stored.

If a low node is found, the node's ID is stored in child_id 711 (1022). In addition, the two pointers previously stored in branch_id 712 are connected to the subtree. And, if there is a high node in this node, disconnect it and connect it to the mother node of the current node. The mother node of the current node is recorded in Previous_r_add 713 (1023).

The last step is to connect the new node with the mother node of the deleted node. If the deleted node was a root node (Root matched) (1024), the ID (711) value of the new node is recorded in the branch table (1025). The B_add value used at this time uses the same value as (1001) when reading the branch table.

If it is not the root node, the child node deleted at the mother_id 710 is high or low ([delete position]) (1026), and thus the appropriate data is completed. (1027, 1028).

The present invention described above is capable of various substitutions, modifications, and changes without departing from the technical spirit of the present invention for those skilled in the art to which the present invention pertains. It is not limited by the drawings.

The present invention as described above, when manufacturing the TCP acceleration hardware so that the two built-in processors to transmit and receive functions, it is possible to quickly search and manage up to 10,000 TCP and UDP sockets through the hardware, the hardware is a socket By including the socket allocation function at the time of creation, the user can access the socket resource block using the socket ID (ID) passed by the user as it is, and also by separating the hash by one more time before the binary search. In addition to improving the efficiency of the search and saving memory, it does not only manage the information of the TCP sockets that have been connected, but also the TCP sockets in listen state. Searching all sockets also has the effect of supporting all the functions required for TCP / UDP full-offloading.

Claims (9)

In the socket retrieval device of Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), Master management means for interpreting the command information received from the processor and transferring the command to the branch table management means and the tree table management means, and receiving the result from the branch table management means and the tree table management means and reporting the result to the processor; Branch table management means for receiving a command from the master management means and managing a branch table; And Tree Table Management Means for Managing Binary Trees Socket search device comprising a. The method of claim 1, The master management means, Instruction and result register means coupled to two processor (send / receive) buses for receiving instructions and informing a result, said interface being for interfacing with said processor to store instruction information; Schedule status processing means for analyzing the command information received from the command and result register means and requesting the corresponding command; An information holding means for selecting one of command register information of a receiving processor and command register information of a transmitting processor by analyzing the command information, and selecting an address to be used by the branch table managing means; And Allocation table management means for receiving a seat allocation request from the schedule state processing means and assigning an address value Socket search device comprising a. The method of claim 1, The branch table management means, A branch table for storing a socket ID value located at a root of a selected tree having a total of 1,026 entries in a memory block; And Compare the value of the socket ID to the command and result register means and the output value of the branch table to see whether they match or whether the output value of the branch table is a null value. Means for comparing socket identifiers to find Socket search device comprising a. The method of claim 1, The tree table management means, A tree table for storing socket information and pointer information of a binary tree; A read state machine and a write state machine for reading and updating tree information in the tree table and managing the tree; Current data storage means for temporarily storing the information read from the Tree Table; Past data storage means for storing the current data again when the value of the current data storage means is changed; Parent data storage means for storing a value of the current data storage means according to the instruction of the read state machine; The result value is informed to the read state machine by using the information entered into the command register of the command and result register means and the information read from the tree table, and the information of the command register matches the socket information (Sock_info) or larger. Calculating means for determining whether the row pointer and the high pointer are null or match the socket IDs of the instruction registers; And Tree record data generating means for generating a value to be recorded when updating of the tree table is required Socket search device comprising a. The method of claim 4, wherein The read state machine and the write state machine, If the read state machine receives a command to find data and then needs to update, the write state machine updates tree information when the command is issued to the write state machine, and the write state machine is the branch table module. And a write request signal is also sent to a branch table of the socket search apparatus. The method of claim 4, wherein The parent data storage means, The socket information (Sock_info), a low pointer (Low_pt), a high pointer (high_pt), the socket information (Sock_info) is a host port (Host Port), a remote port (Remote Port), Remote IP (Remote IP) ( 54 bit data created by attaching 22 bits to a single value, compares the values in the binary tree, and compares the values of the values in the binary tree. The low pointer (Low_pt) and the high pointer (high_pt) Pointer value of two child nodes (Child Node), the pointer value is a socket search device, characterized in that the ID (ID) of the socket. The method according to any one of claims 1 to 6, The tree table management means, According to the command, the node is added, the node is deleted, and the node is searched. The node is added or deleted according to the command issued by the sending processor. The search is performed according to the command issued by the receiving processor. The socket retrieval apparatus of claim 1, wherein the binary tree is stored in a register value to implement hardware management in a binary tree, and the read / write address and write data of the memory block are determined. The method of claim 7, wherein The master management means, It manages not only TCP sockets connected but also TCP sockets in UDP and Listen states. When a command is created in the command and the result register, the schedule state processing means analyzes the schedule socket to the allocation table management means. Request to allocate a seat, and when the allocation request is received, outputs a value from the allocation table management means, and the output value is recorded in the command and result register so that the transmission processor stores the output value as a Socket ID. Socket search apparatus, characterized in that the use. The method of claim 7, wherein The branch table, A socket search device that improves search speed and efficiency and saves memory resources by managing multiple trees through hash rather than using only one tree.

Images