Patent Application
20060282537
1. Technical Field
The present invention relates in general to the field of data processing systems, and specifically, the field of networked data processing systems. Still more particularly, the present invention relates to a system and method of handling connection requests between networked data processing systems.
2. Description of the Related Art
Transmission Control Protocol (TCP) is one of the most widely-used transmission protocols on the Internet. Because TCP provides a reliable and in-order byte stream between two points of communication, applications utilizing TCP do not have to keep track of data lost or re-ordered during transmission.
To establish connections utilizing TCP, the sending and receiving hosts perform a three-way handshake. First, the sending host (host A) sends a synchronize (SYN) signal to the receiving host (host B). The SYN signal indicates to host B that host A is ready to transmit. After host B receives the SYN signal from host A, host B sends a SYN/ACK message that indicates that host B acknowledges and accepts the connection. If host A receives the SYN/ACK message, host A will respond with a second ACK message, after which traffic can flow over the established TCP connection.
When a server, such as host B, receives the initial SYN message, it typically creates a new process thread to handle the client (host A) connection request. The creation and maintenance of the process thread utilizes processor and system memory resources. When the TCP session terminates, the processor and system memory resources are released and ready for allocation to other tasks.
However, the TCP connection process includes several disadvantages. For example, since servers such as host A and host B typically service multiple connections, connection requests in the form of SYN signals are usually placed on a TCP connection queue (hereinafter referred to as an “embryonic queue). All embryonic queues are finite in length, and may become saturated due to dynamic factors such as connection receipt rate, available system resources, protocol response, and application behavior. Those with skill in this art will appreciate that when an embryonic queue is full, a configuration parameter causes a randomly chosen embryonic queue entry to be deleted in order to free an entry slot for a newly arrived connection request. This random deletion is arbitrary and inefficient. Therefore, there is a need for a system and method of handling TCP connection requests that does not require random deletion of received TCP connection requests.
The present invention mitigates the effects of embryonic queue saturation that results from, among other things, connection receipt rate, system resources (e.g., CPU dispatch), protocol response (e.g., timers), application behavior (e.g., accept of connections), and malicious SYN flood attacks utilizing spoofed valid IP addresses.
A preferred embodiment of the present invention discloses a system and method for responding to a full TCP queue. After a server receives a TCP connection request from a client, the server places the request on an embryonic queue of TCP connection requests sorted by the amount of elapsed time since the server has respond to each respective TCP connection request. When the server attempts to place a new TCP connection request on a full embryonic queue, the host, via the TCP protocol, will remove the entry at the end of the embryonic queue. The last entry, due to the high timer value, is more likely to having performed unsuccessful attempts at completing a connection.
The above-mentioned features, as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
Now referring to the figures, and in particular, with reference to
Those skilled in the art will appreciate that network 100 can include many additional components (e.g., routers, firewalls, etc.) not specifically illustrated in
With reference now to
As depicted, exemplary data processing system 200 includes processor(s) 202, which are coupled to system memory 204 via system bus 206. Preferably, system memory 204 may be implemented as a collection of dynamic random access memory (DRAM) modules. Typically, system memory 204 includes data and instructions for running a collection of applications. In the present invention, system memory 204 includes a collection of sockets (not illustrated) instantiated by processor(s) 202 to enable data processing system 200 to communicate with other data processing systems on a network. Also, system memory 204 preferably includes an embryonic queue 250, as depicted in
Now referring to back
Those skilled in the art will appreciate that data processing system 200 can include many additional components not specifically illustrated in
A preferred embodiment of the present invention, network 100 of
Frequently, networks such as network 100 utilize various protocols to enable connectivity between parts of the network. While a preferred embodiment of the present invention utilizes the transmission control protocol (TCP), those with skill in this art will appreciate that the system and method disclosed in the present invention are applicable to other communications protocols such as Winsock, NetBIOS, etc.
In a preferred embodiment of the present invention, TCP operates as an extension of the operating system kernel. That is, the operating system enables TCP operations to be carried out without extra TCP programs. However, in some embodiments of the present invention, TCP operations may be handled utilizing specialized TCP programs.
As illustrated,
The process then proceeds to step 304, which depicts the server binding the socket to a local port in the server. Then, the process continues to step 306, which illustrates the server listening for client requests through the local port via the socket. Then, as illustrated in step 308, the server determines whether a TCP connection request has been received from a client. If a TCP connection request has not been received by the server, the process iterates at step 308. However, if a TCP connection request has been received by the server, the process continues to step 310, which depicts the server sending a SYN/ACK request to acknowledge and accept the SYN request from the client.
Then, as depicted in step 312, the server determines whether or not an ACK message has been received from the client. If the server determines an ACK message has not been received from a client, the process iterates at step 312. However, if the server determines an ACK message has been received from a client, the process continues to step 314, which illustrates the server and client transferring data over the established connection. The process then continues to step 316, which illustrates the server determining whether or not the connection between the server and client has been terminated, either through an explicit connection termination or a connection time-out. If the connection has not been terminated, the process returns to step 314 and proceeds in an iterative fashion. If, however, the server determines that the connection has terminated, the process proceeds to step 318, which illustrates the process ending.
With respect to the client, the process begins at step 300 and proceeds to step 320, which illustrates the client creating a socket and binding that socket to a local port for communication with the server. Then, as depicted in step 322, the client sends a connection request to the server, preferably in the form of a SYN request. Then, the client determines whether it has received a SYN/ACK message from the server, as illustrated in step 324. If the client has not received a SYN/ACK message from the server, the process iterates at step 324. However, if the client has received a SYN/ACK message from the server, the process continues to step 326, which illustrates the client sending an ACK message to the server, which completes the three-way handshake procedure and enables the server and the client to form a connection. Then, the server and client begin transfer of data, as illustrated in step 314. Periodically, as previously discussed, the server and client determine whether or not the connection has been terminated, as depicted in step 316. If the connection has not been terminated, the process returns to step 314 and proceeds in an iterative fashion. If the connection has been terminated, the process continues to step 318, which depicts the process ending.
Returning to step 404, if the server decides to accept the TCP connection request, the process continues to step 408, which depicts the server sending a SYN/ACK signal in response to the client's SYN signal. Also, the server starts a timer related to the TCP connection request. This timer measures the amount of time that has elapsed since the SYN/ACK signal has been sent by the server. The timer value, stored in timer field 258 in TCP connection request nodes 252 as illustrated in
The process then proceeds to step 410, which illustrates the server determining whether the embryonic queue utilized to order TCP connection request is full. If the server determines that the queue is not full, the process continues to step 414, which depicts the server placing the TCP connection request on the queue and ordering the queue by each TCP connection request's relative timer values, stored in timer field 258. By ordering the queue, the server places the TCP connection requests will a smaller timer value at the front of the queue and the requests with a larger value at the end of the queue. A TCP connection requests with larger timer values have a lesser probability of successful connection completion. Usually, a TCP connection request that results in a successful connection has an associated timer value that is small because clients that are more likely to connect successfully promptly return the SYN/ACK signal from the server. The process then proceeds to marker A and continues to step 310 in
Returning to step 410, if the server determines that the embryonic queue is full, the process continues to step 412, which illustrates the server removing an entry at the end of the list to enable the newly-received and accepted TCP connection entry to be placed on the queue. As previously discussed, TCP connection requests at the end of the embryonic queue have larger timer values and are thus more likely to not result in a successful connection. Therefore, the TCP connection requests located at the end of the queue are more logical candidates for deletion from the queue to enable a newly-received TCP connection request to be placed on the queue. The process then continues to step 414, which was discussed previously. Then, the process returns to step 402 and proceeds in an iterative fashion.
As disclosed, the present invention is a system and method of responding to a full TCP embryonic queue. After a server receives a TCP connection request from a client, the server places the request on an embryonic queue of TCP connection request sorted by the amount of elapsed time since the server has responded to the respective TCP connection request. When the server attempts to place a new TCP connection request on a full embryonic queue, the server, via the TCP protocol, will removed the entry at the end of the embryonic queue. The last entry, due to the high timer value, is more likely to having performed unsuccessful attempts at completing a connection.
Also, it should be understood that at least some aspects of the present invention may alternatively implemented in a program product. Programs defining functions on the present invention can be delivered to a data storage system or a computer system via a variety of signal-bearing media, which include, without limitation, non-writable storage media (e.g., CD-ROM), writable storage media (e.g., floppy diskette, hard disk drive, read/write CD-ROM, optical media), and communication media, such as computer and telephone networks including Ethernet. It should be understood, therefore in such signal-bearing media when carrying or encoding computer readable instructions that direct method functions in the present invention, represent alternative embodiments of the present invention. Further, it is understood that the present invention may be implemented by a system having means in the form of hardware, software, or a combination of software and hardware as described herein or their equivalent.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.
