Modifying service provider context information to facilitate locating interceptor context information   

Abstract: A method and system for tracking context information of a service provider and interceptors of service provider requests is provided. An interceptor modifies a portion of service provider context information to reference interceptor context information associated with a client. When the client requests a service of the service provider, the client provides the modified service provider context information along with the request. The interceptor uses the reference of the modified portion of the service provider context information to retrieve its context information. The interceptor then restores the modified portion of the service provider context information to the original unmodified portion, which the interceptor retained as part of its context information. The interceptor then forwards the request along with the original service provider context information to the service provider.

This application is a continuation application of U.S. patent application Ser. No. 11/231,352, filed on Nov. 30, 2004, issued as U.S. Pat. No. 8,135,741, entitled “MODIFYING SERVICE PROVIDER CONTEXT INFORMATION TO FACILITATE LOCATING INTERCEPTOR CONTEXT INFORMATION,” which is incorporated herein in its entirety by reference.

Computer systems typically have services (e.g., file services) that are provided to clients (e.g., an application program). The services may implement a high-level service using low-level operations. For example, a file system may provide high-level commands to open and read files, which are implemented using low-level operations, such as sector seek and sector read. To access a file, an application program can request the file system to open the file and then read the file. The file system performs the necessary low-level operations to perform the high-level commands (e.g., open and read). Thus, the developer of an application program does not need to understand or use the low-level operations, but rather can rely on the file system for performing the appropriate low-level operations. The programs that request services of a service provider are referred to as clients. To have a service performed on its behalf, a client sends a request to a service provider of that service. The service provider performs the request and returns a result such as data or status information.

The requests for services can be satisfied synchronously or asynchronously by the service provider. When a request is satisfied synchronously, the client requesting the service waits until the service completes before continuing. For example, a client may request a service by invoking a read file function of a file system that returns after the file system has retrieved the data of the file. When a request is satisfied asynchronously, the client requesting the service does not wait until the service completes before continuing. However, when the service does complete, the service provider then notifies the client. For example, a client may request a service by invoking a read file function of the file system. That function may return immediately to the client so that the client can continue executing while the file system is reading the file. When the read completes, the service provider notifies the client, for example, by calling a callback function provided by the client or sending an event notification to the client.

One example of a client/service provider model is the Transport Device Interface (“TDI”) of Microsoft Corporation. TDI defines the interactions between a “transport provider” that implements a transport layer and a “transport client” that uses the services of the transport provider. One example of a transport provider is a TCP driver, and one example of a transport client is a redirector of a file system. The redirector invokes functions provided by the TCP driver to send and receive messages via TCP. Thus, the redirector can access files stored on other computing devices using the services of the TCP driver.

A service provider may need to maintain state information for the client between requests received from the client. For example, when a file system opens a file on behalf of a client, the file system may need to maintain a file control block so that when the client requests to read from that file, it can locate the file control block needed to satisfy the request. Such information may be referred to as “context information.” One technique for tracking context information is to return a handle to the client. The handle may be an operating system object that contains or references context information for a service provider session. A service provider session may be delimited by an open and a close request, such as an open file and a close file request. The service provider provides the handle to the client at the beginning of the session, and the client provides the handle to the service provider with each request. This allows the service provider to locate context information that is appropriate for the session. For example, the TDI model specifies that a WINDOWS file object is used as the handle for a TDI session.

It is often desirable to be able to extend the functions provided by a service provider. To support such extension, many systems allow for requests for services made by clients to a service provider to be intercepted or hooked. When a client makes a request to a service provider, an interceptor may receive the request and perform additional processing before forwarding the request to the service provider. The interceptor may also intercept the response to the request and perform additional processing before forwarding the response to the client. FIG. 1 is a diagram that illustrates the layered architecture of client, interceptors, and service provider. When client 101 wants to request services of the service provider 102, the client invokes a function, which may pass control to one or more interceptors 111-119. When each interceptor is invoked, it performs its processing and then forwards the invocation to the next lower level interceptor. Ultimately, the lowest level interceptor invokes a function of the service provider.

Each interceptor, however, may need to maintain its context information. For example, an interceptor that simply logs to a file all invocations to a service provider during a session may have context information that includes the handle returned by the file system when the log file was opened or created. FIG. 2 is a diagram that illustrates one example of how interceptors track their context information. When client 210 requests a service of service provider 220, it is forwarded through interceptors 250 and 260 to the service provider. The service provider creates context information that is represented as a context object 221 (e.g., a file object). The service provider returns a reference to the context object to the lowest level interceptor, which forwards the references to the next higher level interceptor until the reference to the context object is eventually forwarded to the client. Each interceptor has its own context information 251 and 261. To track its context information, an interceptor may create a hash table 255 and 265 that contains references to its context information. The hash table is hashed based on the reference to the corresponding context object provided by the service. When the client makes another request of the service provider in the same service provider session, it includes the reference to the context object in its request. When an interceptor receives the request, the interceptor hashes the reference to locate its context information associated with that session. A difficulty with the use of a hash table by each interceptor is that there can be a high overhead in having to locate the appropriate context information for an interceptor.

FIG. 3 is a diagram that illustrates another example of how interceptors track their context information. In this example, service provider 320 creates context object 321 for a session of client 310. Each interceptor 350 and 360 also creates a context object 351 and 361. When the lowest level interceptor receives the response from the service provider, it replaces the reference to the context object of the service provider with a reference to its context object before forwarding the response to the next higher level interceptor. Eventually, the highest level interceptor forwards the response with a reference to its context object. Each interceptor includes as part of its context information the reference to the context object of the next lower layer. When the client requests a service of the service provider, it includes the reference provided by the highest-level interceptor, which is a reference to the context object for that interceptor. That interceptor uses the context information of the context object and then forwards the request to the next lower level interceptor using the reference provided by that next lower level interceptor. Eventually, the service provider receives a request that includes a reference to its context object. A difficulty with such an approach for tracking context information is that there can be a high overhead in creating context objects, especially if the creation of a context object requires a context switch from application mode to operating system mode.

SUMMARY

A method and system for tracking context information of a service provider and interceptors of service provider requests is provided. The context tracking system is implemented by an interceptor. The interceptor modifies a portion of service provider context information to reference interceptor context information associated with a client. The interceptor then provides the modified context information to the client that requested the service. When the client requests a service of the service provider, the client provides the modified service provider context information along with the request. Upon receiving the request from the client, the interceptor uses the reference of the modified portion of the service provider context information to retrieve its context information. The interceptor then restores the modified portion of the service provider context information to the original unmodified portion, which the interceptor retained as part of its context information. The interceptor then forwards the request along with the original service provider context information to the service provider.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram that illustrates the layered architecture of client, interceptors, and service provider.

FIG. 2 is a diagram that illustrates one example of how interceptors track their context information.

FIG. 3 is a diagram that illustrates another example of how interceptors track their context information.

FIG. 4 is a diagram that illustrates modification of service provider context information when a session is initiated.

FIG. 5 is a diagram that illustrates restoration and modification of service provider context information when a service is requested during a session.

FIG. 6 is a diagram that illustrates no modification of service provider context information when a request is issued while another request is outstanding.

FIG. 7 is a block diagram that illustrates components of the context tracking system in one embodiment.

FIG. 8 is a flow diagram that illustrates processing of the context object created component in one embodiment.

FIG. 9 is a flow diagram that illustrates the processing of the intercept request component in one embodiment.

FIG. 10 is a flow diagram that illustrates the processing of the callback function in one embodiment.

DETAILED DESCRIPTION

A method and system for tracking context information of a service provider and interceptors of service provider requests is provided. In one embodiment, the context tracking system is implemented by an interceptor. The interceptor modifies a portion of service provider context information to reference interceptor context information associated with a client. For example, when an interceptor receives a service provider context object (e.g., a file object), the interceptor replaces certain information of the context object with a reference to context information of the interceptor. The interceptor then provides the modified context information to the client that requested the service. When the client requests a service of the service provider, the client provides the modified service provider context information along with the request. Upon receiving the request from the client, the interceptor uses the reference of the modified portion of the service provider context information to retrieve its context information. The interceptor then restores the modified portion of the service provider context information to the original unmodified portion, which the interceptor retained as part of its context information. The interceptor then forwards the request along with the original service provider context information to the service provider. In this way, the interceptor can track its context information for the client without the overhead of having to look up the context information and of having to create additional context objects.

In one embodiment, the context tracking system is implemented by multiple interceptors that are layered between a client and a service provider. A client initiates a session with a service provider by sending a request to the service provider, which is first intercepted by the interceptor at the highest level. That interceptor forwards the request to the next lower level interceptor. Eventually, the lowest level interceptor receives the request, performs the requested service, and sends a response to the client that includes service provider context information, which is first intercepted by the lowest level interceptor. Upon receiving the response, the lowest level interceptor replaces a portion of the service provider context information with a reference to its context information, saves the portion before modification for later restoration, and forwards the response along with the modified service provider context information to the interceptor at the next higher layer. When the interceptor at the next higher layer receives the response with the modified service provider context information, it also replaces a portion of a service provider context with a reference to its context information, saves the portion before modification (which in this case is a reference to context information of the interceptor at the next lower layer) for later restoration, and forwards the response along with the newly modified service provider context information to the interceptor at the next higher layer. Eventually, the client receives the response with the modified service provider context information which contains a reference to the context information of the interceptor at the highest level.

When the client next requests a service from the service provider as part of the same session, the client sends a request to the service provider that includes the modified service provider information, which is first intercepted by the interceptor at the highest level. That interceptor uses the reference of the modified portion of the modified service provider information to retrieve its context information. That interceptor then replaces the portion of the service provider information that it previously modified with the unmodified portion that it retained and forwards the request along with the restored service provider context information, which is then intercepted by the interceptor at the next lower level. That next lower level interceptor uses the reference of the restored portion of the service provider context information to locate its context information. That interceptor then restores the portion of the service provider context information that it previously modified with the retained portion and then forwards the request along with the restored service provider context information to the interceptor at the next lower level. Eventually, the service provider receives from the interceptor of the lowest level that request along with the service provider context information restored to the original service provider context information. The service provider then services the request using the service provider context information without having to know that the request had been intercepted and the service provider context information had been modified by various interceptors.

In one embodiment, a client during a single session may request a service of a service provider before a previous request has been completed; that is, the previous request is still outstanding. For example, if the requests are serviced synchronously, then one thread of the client may send a request by invoking a function, and before that invoked function returns, another thread of the client may send a request by again invoking that function. If the requests are serviced asynchronously, then a thread of the client may send a request, and before the response is received asynchronously (e.g., by invocation of a callback function), the client (on the same or a different thread) may send another request. Whenever a client sends a request during a session while another request of that session is outstanding, the service provider context information is considered currently in use by the previous request and the modified portion may be in an unknown state. For example, the modified portion may contain the original unmodified content, content newly modified by the service provider as part of servicing the outstanding request, content modified by the interceptors as the response from the service provider is intercepted, and so on. Thus, an interceptor cannot modify the service provider context information without risk of overwriting content needed by the service provider or an interceptor in processing the outstanding request.

To prevent an interceptor from overwriting content needed by the service provider or another interceptor processing an outstanding request, an interceptor reverts to a conventional technique of looking up its context information based on the reference to service provider context information. When an interceptor receives a request, it determines whether a modified portion of the service provider context information contains a reference to its context information. If not, the interceptor knows that the service provider or another interceptor is processing another outstanding request. The interceptor may store a unique identifier of itself when it modifies service provider context information. If that unique identifier has been changed, then the interceptor knows that the service provider or another interceptor is processing an outstanding request. In an alternative embodiment, an interceptor may use a reference counting technique to determine whether there is an outstanding request. If a request is outstanding, then the interceptor uses the reference (e.g., pointer to or address of) to the service provider context information to locate the interceptor\'s context information. For example, the interceptor may use a conventional hash table data structure to locate its context information. The interceptor then performs the processing of the request and forwards the request to the interceptor at the next lower level without modifying the service provider context information. The interceptor at the next lower level again detects that a unique identifier has been changed and looks up its context information using a conventional technique. Eventually, the interceptor at the lowest level forwards the request to the service provider without modifying the service provider context information. The service provider can then process the request with the server provider context information that it expects. In this way, the interceptors can service requests issued without having to look up their context information so long as there is no outstanding request. If requests are seldom issued with outstanding requests, then the context tracking system may provide significant performance improvements over conventional techniques.

FIG. 4-6 are diagrams that illustrate an example of the modification and restoration of server provider context information in one embodiment. In this example, only one interceptor is between the client and the service provider. FIG. 4 is a diagram that illustrates modification of service provider context information when a session is initiated. Initially, a client issues 401 an open request that identifies a callback function (e.g., app::callback). The interceptor receives the request and forwards 402 the open request with its own callback function (e.g., int::callback) to the service provider. The service provider performs its services and when complete responds 403 to that request by invoking the callback function provided by the interceptor. The service provider passes a reference to a context object (i.e., “co”) that includes its context information. Upon receiving that response, the interceptor creates 404 an interceptor context object (i.e., “ico”), which may be created locally by the interceptor to avoid the overhead of a context switch. An interceptor context object may contain a reference to the interceptor context information field, a count field, a context object pointer field, and a retained service provider context information field. The interceptor context information field contains either a reference to or the interceptor context information itself. The count field contains a count of the number of outstanding requests. Rather than using its unique identifier to identify whether a request is outstanding, an interceptor may use the count field. The interceptor increments the count field for each request it processes and decrements the count field for each response it processes. A count of zero means that no request is outstanding. The context object pointer field contains a pointer to the context object returned by the service provider, which may be used to resolve hash collisions when a request is outstanding. The retained service provider context information field contains a copy of the portion of the service provider context information to be modified so that it can be restored when a request is processed. The interceptor then modifies 405 a portion of the context object to reference the interceptor context object. The interceptor then invokes the callback function provided by the client to respond to the service request. When the client receives 406 the response, it stores a reference to the context object for use in requesting services during the same session.

FIG. 5 is a diagram that illustrates restoration and modification of service provider context information when a service is requested during a session. The client sends 501 a read request that includes the reference to the context object and identifies a callback function. Upon receiving the request, the interceptor retrieves 502 a reference to the interceptor context object from the received context object. The interceptor then restores 503 the context object using the content retained in the interceptor context object and increments the count of outstanding requests. The interceptor then forwards the request with the context object and a callback function to the service provider. The service provider performs 504 its processing and then responds by invoking the callback function of the interceptor and providing a reference to the context object. Upon receiving the response, the interceptor retrieves 506 the interceptor context object associated with the callback function. The interceptor may use different entry points of a callback function to identify the appropriate interceptor context object that is associated with that response. Alternatively, the interceptor may perform conventional lookup techniques for locating interceptor context information. The interceptor then modifies 507 the context object to point to the interceptor context object, decrements the count of outstanding requests, and forwards the response by invoking the callback function of the client. Upon receiving the response, the client stores 508 a reference to the context object.

FIG. 6 is a diagram that illustrates no modification of service provider context information when a request is issued while another request is outstanding. The client sends 601 a request that identifies the context object. In this example, the context object contains a reference to service provider context information, rather than interceptor context information. When processing the outstanding request, the interceptor restored the context object by overwriting the reference to the interceptor context object with the retained content. Upon receiving the next request, the interceptor detects 602 that a request is outstanding either by checking for its unique identifier in the modified portion of the context object or by determining that the count field of the interceptor context object is greater than zero. The interceptor then locates the interceptor context object using the reference to the context object and the hash table. Upon locating the interceptor context object, the interceptor increments 603 the count field to indicate that two requests are outstanding and forwards the request to the service provider without modifying the context object. The service provider performs 604 its processing and then responds by invoking the callback function provided by the interceptor. Upon receiving the response, the interceptor identifies 605 the appropriate interceptor context object and decrements 606 the field count. The interceptor then invokes the callback function of the client without modifying the context object. The client maintains 607 a reference to the context object for issuing the next request. The context object contains the unmodified service provider context information.

FIG. 7 is a block diagram that illustrates components of the context tracking system in one embodiment. The context tracking system is implemented by interceptors of client requests and service provider responses. An interceptor 700 that implements the context tracking system includes a context object created component 701, an intercept request component 702, a callback component 703, an interceptor processing component 704, and a context data structure 705. The context object created component is invoked by the interceptor when a context object is provided by the service provider when a session is created. The intercept request component is invoked by the interceptor when a request for service is intercepted. The intercept request component restores the service provider context information as appropriate. The callback component, which intercepts responses, is invoked when a response is provided by a service provider. The callback component modifies and retains the service provider context information as appropriate. The interceptor processing component performs the main processing function of the interceptor. The context data structure, which may be a hash table, a binary tree, or other data structure, is used to locate interceptor context information when multiple requests are outstanding. The interceptor may also use the context data structure defined in context information when a response is received to locate the interceptor context information.

The computing devices on which the context tracking system may be implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives). The memory and storage devices are computer-readable media that may contain instructions that implement the context tracking system. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communications link. Various communications links may be used, such as the Internet, a local area network, a wide area network, or a point-to-point dial-up connection.

The context tracking system may be implemented in various operating environments that include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. The context tracking system may also be implemented on computing devices such as cell phones, personal digital assistants, consumer electronics, home automation devices, and so on.

The context tracking system may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.

FIG. 8 is a flow diagram that illustrates processing of the context object created component in one embodiment. The component is invoked when the interceptor receives a newly created context object. In block 801, the component creates an interceptor context object that contains a reference to the interceptor\'s context information. In block 802, the component initializes the count field of the interceptor context object to zero to indicate that no requests are outstanding. In block 803, the component sets the context object pointer field of the interceptor context object to point to the context object. In block 804, the component retains the service provider context information that is being modified by storing it in the service provider context field of the interceptor context object. In block 805, the component stores the interceptor context object using a hash table and hashing on the reference to the context object. In block 806, the component modifies the context object to point to the interceptor context object and then completes.

FIG. 9 is a flow diagram that illustrates the processing of the intercept request component in one embodiment. The component is invoked by an interceptor to restore the context object. In decision block 901, if another request is outstanding, then the component continues at block 904, else the component continues at block 902. In block 902, the component retrieves the reference to the interceptor context object from the modified portion of the context object. In block 903, the component restores the service provider context object using the retained content and continues at block 906. In block 904, the component searches the hash table for the interceptor context object. In decision block 905, if the interceptor context object was found in the hash table, then the component continues at block 906, else the component continues at block 911. In block 906, the component increments the count field of the interceptor count object to indicate that one more request is outstanding. In block 907, the component sets the interceptor context to the interceptor context of the interceptor context object so that the interceptor can perform its processing in the appropriate context. In block 908, the component processes the request with the interceptor context. In block 909, the component sets the callback routine to identify the interceptor context object. In block 910, the component forwards to the service provider or the interceptor at the next lower level the request that includes the restored service provider context object and the callback function and then completes. In block 911, the component performs the processing of the request when context information is not available.

FIG. 10 is a flow diagram that illustrates the processing of the callback function in one embodiment. In block 1001, the component retrieves the interceptor context object for the interceptor. In block 1002, the component decrements the count filed of the interceptor context object to indicate that one less request is outstanding. In decision block 1003, if no more requests are outstanding, then the component continues at block 1004, else the component continues at block 1005. In block 1004, the component modifies a portion of the context object to point to the interceptor context object. The component may also retain a new copy of the unmodified content in the interceptor context object if the service provider or interceptors are allowed to modify that content after creation of the context object. In block 1005, the component then forwards the response by invoking the callback function of the application and then completes.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. Accordingly, the invention is not limited except as by the appended claims.