REGISTER  |  SIGN IN
United States Patent7219346
PatiejunasMay 15, 2007
Title
System and method for implementing a client side HTTP stack
Abstract
A software components and methods are provided for implementation of a client side HTTP stack, which provide high performance and scalability. Multithreading and completion ports are employed in the client side HTTP layer in association with sockets and a thread pool, thereby providing support for business-to-business and other more recent client side applications which create numerous requests. The invention further comprises a dedicated scheduler thread adapted to activate an object scheduled to begin sending requests at a specific time, as well as a dedicated DNS thread used for resolving symbolic domain names into IP addresses. In addition, the client side HTTP stack implementation comprises a dedicated timeout thread with a list of active sockets and timers associated with each socket to allow finer grain control over socket timeout periods.
Inventors:Patiejunas; Kestutis (Redmond, WA)
Assignee:Microsoft Corporation (Redmond, WA)
Appl. No.:09/730,190
Filed:December 5, 2000
PCT Pub Date:May 15, 2007
Current U.S. Class:718/102 709/202 709/223 
Current International Class:G06F 9/48 (20060101) G06F 9/44 (20060101)
Field of Search:718/100,102,104,105,107 709/200,203,213,217-219,227
U.S. Patent Documents
5752031May 1998Cutler et al.
5754771May 1998Epperson et al.
5796954August 1998Hanif et al.
5913215June 1999Rubinstein et al.
6003061December 1999Jones et al.
6324492November 2001Rowe
6493749December 2002Paxhia et al.
6687729February 2004Sievert et al.
6725253April 2004Okano et al.
6957435October 2005Armstrong et al.
6976095December 2005Wolrich et al.
7051330May 2006Kaler et al.
Other References
International Search Report, EP 01 12 4445, mailed Feb. 27, 2004. cited by other .
Control of Dynamic Threads Pool for Concurrent Remote Procedure Calls, IBM Technical Disclosure Bulletin, IBM Corp., May 1, 1995, vol. 38, No. 5, New York. cited by other .
Marc H. Brown, et al., DeckScape: An Experimental Web Browser, Computer Networks and ISDN Systems, Apr. 1, 1995, vol. 27, No. 6, North Holland Publishing, Amsterdam, NL. cited by other.~
Primary Examiner: Bullock, Jr.; Lewis A.
Attorney, Agent or Firm:Amin, Turocy, & Calvin, LLP
Claims

What is claimed is:
1. A client side HTTP stack software component embodied in machine readable media and effectuated on a machine that processes requests, comprising: at least one completion port object; a thread pool comprising a plurality of threads that process differentiable tasks associated with at least one client side request; a client side state machine selectively associated with the at least one request, the client side state machine selected via at least one key associated with the at least one request; and an activation component that associates a context of a first thread with the client side state machine using the at least one key and activates the first thread.

2. The client side HTTP stack implementation of claim 1, further comprising a scheduler thread that activates an object scheduled to begin sending requests at a specific time.

3. The client side HTTP stack implementation of claim 1, further comprising a DNS thread that resolves domain names into IP addresses.

4. The client side HTTP stack implementation of claim 1, further comprising a timeout thread with a list of active sockets and timers associated with each socket, the timeout thread selectively times-out at least one socket according to at least one timer in the list.

5. The client side HTTP stack implementation of claim 4, further comprising a scheduler thread that activates an object scheduled to begin sending requests at a specific time.

6. The client side HTTP stack implementation of claim 5, further comprising a DNS thread that resolves domain names into IP addresses.

7. The client side HTTP stack implementation of claim 4, further comprising a DNS thread that resolves domain names into IP addresses.

8. A machine effectuated software component included on machine readable media that implements a client side HTTP stack, comprising: a thread pool comprising N threads that process M requests from a client application component, where N and M are integers greater than 1 and where M is greater than N; a state machine associated with each of the M requests based at least on one or more tasks included as a part of each of the M requests; at least one key associated with at least one of the M requests, wherein a first one of the N threads is associated with the at least one of the M requests, and a thread activation component that associates the context of the first one of the N threads with the state machine using the at least one key, in order to activate the first one of the N threads.

9. The software component of claim 8, the at least one thread activation component activates at least one of the N threads based on an event.

10. The software component of claim 9, where the at least one thread activation component is a completion port.

11. The software component of claim 9, where at least one of the N threads deactivates itself and returns to the thread pool when an operation being processed by the at least one of the threads is pending.

12. The software component of claim 11, where the event is the receipt of a completion packet by the at least one thread activation component.

13. The software component of claim 12, where the at least one thread activation component is a completion port.

14. The software component of claim 13, further comprising a scheduler thread that activates an object scheduled to begin sending requests at a specific time.

15. The software component of claim 14, further comprising a DNS thread that resolves domain names into IP addresses.

16. The software component of claim 15, further comprising a timeout thread with a list of active sockets and timers associated with each socket, the timeout thread selectively times-out at least one socket according to at least one timer in the list.

17. The software component of claim 8, where the thread activation component associates the context of one of the N threads with the at least one state machine using the at least one key in order to activate the one of the N threads based on an event.

18. The software component of claim 8, further comprising a scheduler thread that activates an object scheduled to begin sending requests at a specific time.

19. The software component of claim 8, further comprising a DNS thread that resolves domain names into IP addresses.

20. The software component of claim 8, further comprising a timeout thread with a list of active sockets and timers associated with each socket, the timeout thread selectively times-out at least one socket according to at least one timer in the list.

21. A method effectuated at least in part by a machine for implementing a client side HTTP stack, comprising: processing M requests from a client application component using a thread pool comprising N threads, where M and N are integers greater than 1 and where M is greater than N; selectively associating a state machine with each of the M requests based at least in part on one or more differentiable task included in each of the M requests; associating at least one key with at least one of the M requests; associating a first one of the N threads with the at least one of the M requests; and associating a context of the first one of the N threads with the state machine using the at least one key, in order to deactivate the first one of the N threads.

22. The method of claim 21, further comprising: selectively deactivating at least one of the N threads; and activating at least another of the N threads based on an event using at least one thread activation component.

23. The method of claim 22, where the at least one thread activation component is a completion port.

24. The method of claim 22, where selectively deactivating at least one of the N threads comprises deactivating the at least one of the N threads when an operation being processed by the at least one of the N threads is pending.

25. The method of claim 24, where activating at least another of the N threads based on an event comprises: receiving a completion packet using the thread activation component; and activating one of the N threads upon receipt of the completion packet using the thread activation component.

26. The method of claim 25, where the at least one thread activation component is a completion port.

27. The method of claim 26, further comprising activating an object scheduled to begin sending requests at a specific time using a scheduler thread.

28. The method of claim 27, further comprising resolving domain names into IP addresses using a DNS thread.

29. The method of claim 28, further comprising selectively timing out at least one socket according to at least one timer associated with the at least one socket using a timeout thread comprising a list of active sockets and timers associated with each socket.

30. The method of claim 21, further comprising associating a context of one of the N threads with the at least one state machine using the at least one key in order to activate the one of the N threads based on an event.

31. A computer-readable medium having computer-executable instructions for processing M requests from a client application component using a thread pool comprising N threads, where M and N are integers greater than 1 and where M is greater than N, and associating a state machine with at least one of the M requests, the state machine selectively associated based on at least a task included in each of the M requests, the state machine activates at least one of the N threads based at least in part on the task, the computer executable instructions further include: associating at least one key with the at least one of the M requests; associating a first one of the N threads with the at least one of the M requests; and associating a context of the first one of the N threads with the state machine employing the at least one key, in order to deactivate the first one of the N threads.

32. The computer-readable medium of claim 31, further comprising computer-executable instructions for: selectively deactivating at least one of the N threads; and activating at least another of the N threads based on an event using at least one thread activation component.

33. The computer-readable medium of claim 32, where the at least one thread activation component is a completion port.

34. The computer-readable medium of claim 32, where the computer-executable instructions for selectively deactivating at least one of the N threads comprises computer-executable instructions for deactivating the at least one of the N threads when an operation being processed by the at least one of the N threads is pending.

35. The computer-readable medium of claim 34, where the computer-executable instructions for activating at least another of the N threads based on an event comprises computer-executable instructions for: receiving a completion packet using the thread activation component; and activating one of the N threads upon receipt of the completion packet using the thread activation component.

36. The computer-readable medium of claim 35, further comprising computer-executable instructions for activating an object scheduled to begin sending requests at a specific time using a scheduler thread.

37. The computer-readable medium of claim 36, further comprising computer-executable instructions for resolving domain names into IP addresses using a DNS thread.

38. The computer-readable medium of claim 37, further comprising computer-executable instructions for selectively timing out at least one socket according to at least one timer associated with the at least one socket using a timeout thread comprising a list of active sockets and timers associated with each socket.

39. The computer-readable medium of claim 31, further comprising computer-executable instructions for associating a context of one of the N threads with the at least one state machine using the at least one key in order to activate the one of the N threads based on an event.

40. A machine executed software component resident on machine readable media for implementing a client side HTTP stack, comprising: means for processing M requests from a client application component using a thread pool comprising N threads, where M and N are integers greater than 1 and where M is greater than N; means for assigning each of the M requests with a state machine, the assignment of the state machine based on one or more differentiable tasks that comprises each of the M requests; and means for associating at least one key with at least one of the M requests, a first one of the N threads with the at least one of the M requests, and a context of the first one of the N threads with the state machine using the at least one key, in order to deactivate the first one of the N threads.

41. The software component of claim 40, further comprising: means for selectively deactivating at least one of the N threads; and means for activating at least another of the N threads based on an event.

42. The software component of claim 41, further comprising means for activating an object scheduled to begin sending requests at a specific time.

43. The software component of claim 41, further comprising means for resolving domain names into IP addresses.

44. The software component of claim 41, further comprising means for selectively timing out at least one socket according to at least one timer associated with the at least one socket.
Description


TECHNICAL FIELD

The present invention relates generally to computer systems, and more particularly to methods and systems for implementing a client side HTTP stack in a computer system.

BACKGROUND

The rapid growth of the Internet and Internet based applications has created a multitude of benefits for individuals, businesses, governments, schools, and society in general. Several years ago the Internet was primarily used by individuals to `surf the web` using a web browser software application component. In this situation, the individual's computer is sometimes referred to as a client. The client requests data, images, or other information from another machine, sometimes referred to as a server, via the Internet. This client/server architecture may be thought of in terms of a requesting machine (e.g., the client) and a supplying machine (e.g., the server), which may include a database and a database management system (DBMS) software application. The client web browser gains access to the Internet through a network communications protocol, which includes one or more layers, in order to request and obtain information from the server database software.

The browser typically interfaces with a hypertext transport protocol (HTTP) software component, which provides for sending requests and receiving responses in a first layer. The HTTP software component is sometimes referred to as the HTTP stack. The HTTP stack protocol is used to establish a connection with a web server and to transmit hypertext markup language (html) pages or other data to the client browser. To do this, the HTTP stack interfaces with a transport layer, such as the transmission control protocol (TCP). The TCP layer interfaces with a network layer software component, such as the Internet protocol (IP) layer. The TCP/IP communications protocol has become the standard for most Internet communication, wherein the TCP layer or stack provides transport functions to ensure the total amount of bytes in a transmitted data packet are properly received, and the IP layer provides a routing mechanism. In the IP protocol, messages include addresses for both the destination station or machine, and the destination network (e.g., an IP address), thus rendering the IP protocol particularly applicable to the Internet.

On the server machine, the server software application (e.g., a database management system software component) receives requests from one or more such clients via a layered network architecture including a server side IP layer, a server TCP layer, and a server side HTTP stack. In the past, significant attention was focused on improving the throughput capability of server side software implementations of the HTTP layer (e.g., the server side HTTP stack), such as by the employment of multi-tasking techniques. This is because such servers are commonly subjected to hundreds and even thousands of client requests within a short period of time.

Thus, many server side HTTP stack software implementations provide for multithreading, which allows two or more streams of execution (threads) to run concurrently within a single program (e.g., to service multiple client requests). Multithreading may be employed in a single processor server machine, and/or in a multiprocessing environment wherein a plurality of processors may service individual threads. For example, individual client requests may be processed by corresponding threads, thereby increasing the request handling capacity of the server. In addition, some server side HTTP stack implementations include methods and software components for facilitating efficient usage of such threads, for example, completion ports and the like.

While improvements have heretofore been made in the server side HTTP stack implementation to support the large number of requests typically received by such servers, little attention has been thus far paid to the client side HTTP stack implementation. The typical web browser application on the client side is usually asked to obtain information from a server in relatively small chunks (e.g., one html page at a time). In addition, the web browser typically only generates a new request when the client user performs a user interface command, such as by selecting a new page to view. For example, a user may obtain a page of information, and study the page for several seconds or even minutes before initiating a request for another page. Consequently, there has thusfar been no incentive to improve the request throughput capacity of client side HTTP stack implementations.

In recent years, however, advanced software applications have been developed and installed, which provide businesses and other institutions with Internet based features and capabilities requiring improved processing capabilities on the client machine. For instance, a client machine may include an application which generates hundreds or even thousands of requests in a very short period of time, which need to be processed in a timely fashion. Thus, there is a need for improved methods and systems for implementing a client side HTTP stack in a computer system.

SUMMARY

The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is intended to neither identify key or critical elements of the invention nor delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

The invention comprises a client side HTTP stack implementation which provides high performance and scalability not previously achieved, wherein multithreading and completion ports are employed in the client side HTTP layer in association with sockets and a thread pool. In the past, the client side HTTP stack has been implemented using one socket and one thread. While this provided usable processing capability for a single user accessing the Internet via a browser application, business-to-business and other more recent client side applications create numerous requests, which require timely processing. The single thread, single socket architecture, however, accommodates only one request at a time. Thus, in prior client side stack implementations, other requests may become starved due to the client processor being occupied processing one request at a time.

The invention allows client side applications to create completion ports with an associated concurrency value indicating the maximum number of threads associated with the port which should be running at any given time. I/O is associated with client side sockets, which in turn are associated with the completion port using a key. The use of completion ports and concurrency values improves processor utilization by allowing blocking threads to be deactivated, thereby suspending execution of tasks related to a given request, until the completion port receives an associated completion packet from the I/O. In operation, the threads that block on a completion port are deactivated, thereby allowing other threads to be activated as completion packets are received at the completion port within the concurrency limits.

In addition, the client side HTTP stack implementation provides for state machines associated with the requests. The state machines are associated with specific requests using one or more keys. When a client side completion port receives a completion packet from a server, the next available thread processes the request according to the corresponding state machine using the key. The state machine allows the correct processing of tasks associated with a particular request by any one of the threads from the thread pool, and thus facilitates the improved processing efficiencies achieved through the use of a thread pool and completion ports. In particular, the key facilitates the ability of a thread whose associated operation (e.g., an I/O operation) is pending, to check a completion port which may then activate the thread when any other operation is completed. When the initial (e.g., I/O) operation completes, the next available thread then resumes execution thereof at the appropriate state using the key. The thread thus returns to a pool of available or free threads once the thread receives an indication (e.g., status code) that the current operation is pending.

The invention further comprises a dedicated scheduler thread adapted to activate an object scheduled to begin sending requests at a specific time, as well as a dedicated DNS thread used for resolving symbolic domain names into IP addresses. In addition, the client side HTTP stack implementation comprises a dedicated timeout thread with a list of active sockets and timers associated with each socket to allow finer grain control over socket timeout periods.

An aspect of the present invention provides a client side HTTP stack software component for processing requests. The software component includes one or more completion port objects and a thread pool with a plurality of threads for processing tasks associated with client side requests. Whereas prior client side HTTP stack implementations comprise a single thread of execution, the invention provides multi-tasking request processing on the client system through the employment of a pool of threads shared between a plurality of active HTTP requests, which was heretofore not available.

In addition, the use of completion ports provides for efficient use of the thread pool, thereby further improving the throughput of client side request processing. One or more (e.g., several) nested and interrelated state machines may be associated with individual requests. When a thread processing a client request is going to perform a long lasting I/O operation (e.g., when a request message has been sent to a server and the thread is waiting for a response), the thread may determine from a status code that the operation is pending and discontinue the execution. The completion port may then activate the thread pending receipt of a completion packet associated with one or more the pending requests. Thus, once the thread is thus disassociated from the pending operation, the thread returns to the pool of available threads, from which it or other threads may be activated by the completion port to process another request. The selective activation of threads ensures that requests which may be further processed at a given time are provided with a thread for such processing, within the concurrency value associated with the completion port.

The state machines and the key associated with the request processes further facilitate the activation of threads using the completion port. For instance, when a first thread processing a task associated with a particular client request (e.g., an I/O operation) receives a status code indicating that the task is pending, the context of the first thread including the corresponding state machine state may be associated with a key, and the first thread returns to the thread pool. When the request processing is subsequently restarted (e.g., via the completion port activating a thread from the pool upon receipt of a completion packet), execution proceeds at the appropriate place (e.g., state machine state) according to the key associated with the request. The request may be restarted using the same or a different thread from the thread pool. For instance, the completion port may associate the context of the request with one of the threads in the pool using the key, in order to activate the thread based on an event, wherein the event may be the receipt of a completion packet.

In addition to the thread pool, completion ports, state machines, and keys, the client side HTTP stack component may comprise a scheduler thread adapted to activate an object scheduled to begin sending requests at a specific time, a DNS thread adapted to resolve domain names into IP addresses, and/or a timeout thread with a list of active sockets and timers associated with each socket, which is adapted to selectively timeout at least one socket according to a timer in the list.

According to another aspect of the invention, there is provided a software component for implementing a client side HTTP stack, comprising a thread pool. The thread pool may include N threads adapted to process M requests from a client application component, where N and M are integers greater than 1, and wherein M may be greater than N. For instance, ten such threads may be employed to process hundreds or even thousands of requests. The HTTP stack component may also comprise one or more thread activation components for selectively activating at least one of the N threads based on an event (e.g., receipt of a completion packet). In this regard, the thread activation component may comprise a completion port or any other software component adapted for such selective activation of threads of execution.

The threads in the thread pool are adapted to deactivate or otherwise disassociate themselves from processing an operation associated with a client request when the thread receives an indication (e.g., a status code) that the operation is pending. Thereafter, the thread returns to the thread pool to await activation by the completion port based on receipt of a completion packet. Thus, rather than waiting without performing any request processing tasks (e.g., blocking on an I/O operation), the thread may be advantageously employed to perform useful operations associated with a completion packet.

State machines may be associated with the M requests, and one or more keys may be associated with the requests. For example, each request may have a collection of several state machines associated with it, which are used when processing that particular request. Thus, where a first thread is associated with a first request, the thread may be adapted to associate its contextwith the corresponding state machine using a key, prior to returning to the thread pool. In addition, the thread activation component is adapted to associate the context of one of the N threads with the state machine using the key in order to activate the thread based on an event (e.g., receipt of a completion packet).

Yet another aspect of the invention provides a method of implementing a client side HTTP stack, which comprises processing M requests from a client application component using a thread pool comprising N threads, wherein M and N are integers greater than 1 and wherein M is greater than N. The method may further comprise selectively activating at least one of the N threads using one or more thread activation components (e.g., a completion port) based on an event (e.g., receipt of a completion packet). The threads may selectively deactivate and return to the thread pool, for example, when a thread receives an indication that the current operation with which it is associated is pending. In this manner, the threads do not block on I/O operations. Activating a thread based on an event may comprise receiving a completion packet using the thread activation component, and activating one of the N threads upon receipt of the completion packet.

Moreover, the method may comprise associating a state machine with at least one of the M requests. This may comprise associating at least one key with the at least one of the M requests, associating a first one of the N threads with the at least one of the M requests, and associating a context of the first one of the N threads with the at least one state machine using the at least one keywhen the first one of the N threads is deactivated or disassociated from the request (e.g., when an operation associated with the request is pending). In addition, the method may comprise associating a context of one of the N threads with the at least one state machine using the at least one key in order to activate the thread based on an event.

The method may further comprise activating an object scheduled to begin sending requests at a specific time using a scheduler thread and/or resolving domain names into IP addresses using a DNS thread. In addition, the method may include selectively timing out at least one socket according to at least one timer associated with the at least one socket using a timeout thread comprising a list of active sockets and timers associated with each socket.

Still another aspect of the invention provides a computer-readable medium having computer-executable instructions for processing M requests from a client application component using a thread pool comprising N threads, wherein M and N are integers greater than 1 and wherein M is greater than N. Further computer-executable instructions may be provided for selectively activating at least one of the N threads using at least one thread activation component based on an event.

To the accomplishment of the foregoing and related ends, certain illustrative aspects of the invention are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention may be employed and the present invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram illustrating an exemplary client side HTTP stack implementation according to an aspect of the present invention;

FIG. 2 is a schematic diagram illustrating relationships between several classes within an exemplary client side HTTP stack implementation;

FIG. 3 is a schematic diagram illustrating several exemplary state machines according to another aspect of the invention;

FIG. 4 is a schematic diagram further illustrating the state machines of FIG. 3, including various exemplary state machine states associated therewith;

FIG. 5 is a schematic diagram illustrating an exemplary client computer system with a client side HTTP stack implementation according to the invention;

FIG. 6 is a schematic diagram illustrating an exemplary client computer system accessing one or more server computers via the Internet;

FIG. 7 is a schematic diagram illustrating another exemplary client computer system having a business-to-business application adapted to obtain data or information from a plurality of server computers via the Internet according to requests from a plurality of applications running on separate client computers;

FIG. 8 is a schematic diagram illustrating another exemplary client computer system adapted to obtain information relating to availability of automobiles from a plurality of dealer server computers according to requests from a plurality of web browsers;

FIG. 9 is a flow diagram illustrating an exemplary method of implementing a client side HTTP stack according to another aspect of the invention;

FIG. 10 is a flow diagram further illustrating the exemplary method of FIG. 9; and

FIG. 11 is a schematic block diagram illustrating an exemplary operating environment in which one or more aspects of the invention may be implemented.

DETAILED DESCRIPTION

The present invention is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It may be evident, however, to one skilled in the art that the present invention may be practiced without these specific details. Moreover, well-known structures and devices are illustrated in some instances in block diagram form in order to facilitate description of the present invention.

The invention comprises software components and methods for implementation of a client side HTTP stack, which provide high performance and scalability not achievable with conventional implementations. Multithreading and completion ports are employed in the client side HTTP layer in association with sockets and a thread pool, whereby business-to-business and other request intensive client side applications are supported. The invention further comprises a dedicated scheduler thread adapted to activate an object scheduled to begin sending requests at a specific time, as well as a dedicated DNS thread used for resolving symbolic domain names into IP addresses. In addition, the client side HTTP stack implementation comprises a dedicated timeout thread with a list of active sockets and timers associated with each socket to allow finer grain control over socket timeout periods.

In FIG. 1, an exemplary client side HTTP stack implementation component 2 is illustrated according to an aspect of the present invention. Component 2 comprises a thread pool 4 having N threads 6, 8, and 10, where N is an integer, for executing one or more of M client requests 12, 14, and 16, where M is an integer greater than N. The requests 12, 14, and 16 are generated by a client software application component 18. For example, the threads 6, 8, and 10 of the thread pool 4 may be scheduled for execution of a particular request (e.g., request 12, 14, or 16) according to a concurrency value (not shown) associated with a completion port 20, whereby the number of active threads may be controlled. Thus, where the concurrency value (e.g., 10) for the completion port 20 has not been reached, and one or more of the M requests 12, 14, and/or 16 require processing, a thread from the thread pool 4 may be activated and associated with a request for performing such processing. Further in accordance with the invention, threads from the thread pool 4 may be selectively deactivated or otherwise disassociated from a request, for example, when receiving a status code (not shown) indicating that an I/O operation associated with one of the sockets 24, 26, and/or 28 is pending.

The processing of various tasks associated with a particular client request (e.g., requests 12, 14, and/or 16) may be accomplished in accordance with one or more state machines, collectively referenced as 22. For example, state machines 22 may be provided for TCP data transmission, security protocol implementation (e.g., secure sockets layer (SSL) or transport layer security (TSL) implementations), data parsing, and/or authentication, as illustrated and described in greater detail hereinafter.

The state machines 22 associated with processing the client requests 12, 14, and/or 16 may be employed to further facilitate the activation of threads from the thread pool 4 using the completion port 20. For example, when a first thread 6
processing a task associated with client request 12 determines that an operation associated with the client request 12 is pending (e.g., on completion of an I/O operation), the context of the first thread 6 may be associated with the corresponding state machine 22 using a key (not shown), whereafter the first thread 6 is returned to the pool 4 of available threads (e.g., the thread 6 is deactivated). When the processing of the request 12 is subsequently restarted, execution proceeds at the appropriate place or state according to the corresponding state machine 22. The request may be restarted using the same thread or a different thread from the thread pool 4 (e.g., thread 6, 8, or 10). For instance, the completion port 20 may associate the context of thread 8 in the pool 4 with the state machine 22 corresponding with the client request 12 using the key in order to activate the thread 8 based on an event. In this regard, the event may be the receipt of a completion packet in the completion port 20
via one of the sockets 24, 26, or 28.

In addition to the thread pool 4, completion port 20, state machines 22, and keys (not shown), the client side HTTP stack component 2 may comprise a scheduler thread 30 adapted to activate an object scheduled to begin sending requests at a specific time. For example, the scheduler thread 30 may monitor a time-sorted queue inside a connection pool class (not shown) for some items to be activated at a specified time. Thread 30 may then call a specific external entry point to activate these items at the appropriate time. The scheduler thread 30 may be used for both placing objects from a client connections class (not shown) in a queue for delayed activation, as well as for timing out one or more operations that are in progress. For example, operations like send may be timed out by the scheduler thread 30 if they don't complete at specified time.

The component 2 may further comprise a domain name system (DNS) address resolution thread 32 adapted to resolve domain names into IP addresses. The DNS thread 32 may accept a structure from a queue (not shown) with data about DNS resolution that should be done, and is adapted to perform the resolution and signal an event in that structure about completion of the resolution. An exemplary DNS thread may be implemented via the following sample code:

TABLE-US-00001 class DNS_REQUEST { public: DNS_REQUEST( );
 
Copyright 2006-2008 Patent Looker, LLC