The following operators can be used to better focus your queries.
( ) , AND, OR, NOT, W/#
? single char wildcard, not at start
* multi char wildcard, not at start
(Cat? OR feline) AND NOT dog?
Cat? W/5 behavior
(Cat? OR feline) AND traits
Cat AND charact*
This guide provides a more detailed description of the syntax that is supported along with examples.
This search box also supports the look-up of an IP.com Digital Signature (also referred to as Fingerprint); enter the 72-, 48-, or 32-character code to retrieve details of the associated file or submission.
Concept Search - What can I type?
For a concept search, you can enter phrases, sentences, or full paragraphs in English. For example, copy and paste the abstract of a patent application or paragraphs from an article.
Concept search eliminates the need for complex Boolean syntax to inform retrieval. Our Semantic Gist engine uses advanced cognitive semantic analysis to extract the meaning of data. This reduces the chances of missing valuable information, that may result from traditional keyword searching.
Disclosed is a novel method that has been developed to
efficiently handle persistent HTTP
connections within the kernel using AIX's in-kernel GET engine called FRCA
(Fast Response Cache Architecture)
English (United States)
This text was extracted from a PDF file.
This is the abbreviated version, containing approximately
52% of the total text.
Page 1 of 2
A method to handle cached static GET requests from in-kernel GET Engine in presence of non-cached requests over HTTP 1.1 connections.
The in-kernel GET Engine that is supported on AIX* (called Fast Response Cache Architecture) intercepts HTTP GET requests at the TCP level and if this request is cached in the memory the response is sent directly instead of passing the request to the user space web server. This reduces the system overhead (in terms of CPU utilization) due to eliminating tasks of the web server such as file system access, copying data from user space to kernel, etc. In the original implementation, if the GET Engine cannot handle a request (due to reasons such as a dynamic request or a static request that is not cached in memory) it passes the tcp connection to the user space web server. This implementation worked well for HTTP 1.0 requests where a new tcp connection is created for every request. However, with HTTP 1.1 the connections are persistent which means multiple requests can be handled over a single connection. The GET engine on getting a request that it cannot handle passes the connection to the web server. And all subsequent requests that come on this connection are handled by the user space web server even though they could have been handled by the in-kernel GET Engine. For example, if a HTTP 1.1 connection handles 10 GET requests, and the first of these requests is a dynamic request which the GET engine cannot handle, and the remaining 9 are static requests that are cached in memory by the in-kernel GET Engine, the user space web server ends up handling all 10 requests when 9 of them could have been handled by the in-kernel GET engine. This behavior severely affected the performance gains previously achieved from the...