Method and system for layering an infinite request/reply data stream on finite, unidirectional, time-limited transports

• US 20030225889A1
• Filed: 05/30/2002
• Published: 12/04/2003
• Est. Priority Date: 05/30/2002
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Moutafov, Kamen K.
• Granted Patent: US 7,685,287 B2
• Time in Patent Office: Days
• US Class Current: 709/227
• CPC Class Codes: G06F 9/547 Remote procedure calls [RPC]; Web services
• CPC Class Codes: H04L 67/02 based on web technology, e.g. hypertext transfer protocol [HTTP]
• CPC Class Codes: H04L 67/14 Session management for real-time applications in data packet communications networks H04L65/1066
• CPC Class Codes: H04L 67/563 Data redirection of data network streams
• CPC Class Codes: H04L 67/565 Conversion or adaptation of application format or content adding application control or application functional data H04L67/561
• CPC Class Codes: H04L 9/40 Network security protocols

Abstract

An improved method and system for layering RPC communications on top of an HTTP transport. An RPC data stream of individual request/reply packets is mapped to HTTP primitives, and RPC requests are mapped to one large, HTTP, POST-like request (IN channel). Corresponding replies are mapped to another large, HTTP, GET-like request (OUT channel). The client establishes the IN channel and OUT channel as simultaneously open connections with a large content-length for each. Before the content-length is exhausted, the client and server open a new IN or OUT channel while the corresponding channel is still alive, so that there is always at least one opened IN or OUT channel available. If traffic is too infrequent, the client keeps the connection alive so that it will not be closed for being idle. This provides a bi-directional virtual connection that remains open for an unlimited time for tunneling unlimited amounts of RPC traffic.

Claims

1. In a computer network having a client and a server, a method comprising:

establishing an IN channel for client-to-server traffic, the IN channel having a lifetime that expires;

establishing an OUT channel for server-to-client traffic, the OUT channel having a lifetime that expires;

communicating data from the client to the server via the IN channel;

communicating data from the server to the client on the OUT channel; and

tracking the lifetime of each channel and replacing any channel that will expire or has expired with a corresponding new channel to provide a virtual connection having a lifetime that does not expire.

2. The method of claim 1 wherein the IN channel corresponds to an IN proxy, and wherein establishing the IN channel for client-to-server traffic comprises sending a header from the client to the IN proxy.

3. The method of claim 2 wherein the IN proxy receives the header, and in response connects to the server.

4. The method of claim 1 wherein the OUT channel corresponds to an OUT proxy, and wherein establishing the OUT channel for client-to-server traffic comprises sending a header from the client to the OUT proxy.

5. The method of claim 4 wherein the OUT proxy receives the header, and in response connects to the server.

6. The method of claim 1 further comprising, detecting when data has not been communicated over one of the channels for a defined period, and communicating at least some data over the channel such that the channel is not idle for longer than the defined period.

7. The method of claim 1 wherein each channel has a reserved lifetime, and wherein tracking the lifetime of each channel includes detecting when an amount of data sent over the channel is approaching or has reached the reserved lifetime.

8. The method of claim 1 wherein the IN channel corresponds to an IN proxy and the OUT channel corresponds to an OUT proxy, and wherein each proxy provides a receive window for flow control on its corresponding channel.

9. The method of claim 1 wherein the IN channel corresponds to an IN proxy, and further comprising, replacing the IN channel with a new IN channel, including providing a new IN proxy.

10. The method of claim 8 wherein the IN proxy provides a receive window for flow control, wherein the IN proxy and the new IN proxy detect that they are the same IN proxy, and wherein the same IN proxy continues to use the receive window flow control from the IN channel being replaced for the new channel flow control.

11. The method of claim 1 wherein the OUT channel corresponds to an OUT proxy and the OUT channel corresponds to an OUT proxy, and wherein each proxy provides a receive window for flow control on its corresponding channel.

12. The method of claim 1 wherein the OUT channel corresponds to an OUT proxy, and further comprising, replacing the OUT channel with a new OUT channel, including providing a new OUT proxy.

13. The method of claim 12 wherein the OUT proxy provides a receive window for flow control, wherein the OUT proxy and the new OUT proxy detect that they are the same OUT proxy, and wherein the same OUT proxy continues to use the receive window flow control from the OUT channel being replaced for the new channel flow control.

14. The method of claim 1 wherein the data communicated over the IN channel and the OUT channel comprise RPC data over HTTP.

15. A computer-readable medium having computer-executable instructions for performing the method of claim 1.

16. In a computer network having a client and a server, a method comprising:

receiving, at a first proxy, a request from a client to establish an OUT channel for server-to-client traffic, and in response, establishing a connection with the server;

receiving, at a second proxy, a request from a client to establish an IN channel for client-to-server traffic, and in response, establishing a connection with the server as the IN channel;

at the second proxy via the IN channel, receiving data from the client directed to the server and forwarding it to the server;

at the first proxy via the OUT channel, receiving data from the server directed to the client and forwarding it to the client;

receiving at the first proxy a request from the server to recycle the OUT channel to a new OUT channel corresponding to a third proxy, and in response, transitioning server-to-client traffic to the new OUT channel; and

receiving at the second proxy a request from the client to recycle the IN channel to a new IN channel corresponding to a fourth proxy, and in response, transitioning client-to-server traffic to the new IN channel.

17. The method of claim 16 further comprising, detecting whether the first proxy and the third proxy are the same.

18. The method of claim 17 wherein the third proxy detects whether the first proxy and the third proxy are the same by comparing a received connection cookie to a stored connection cookie.

19. The method of claim 16 further comprising, detecting whether the second proxy and the fourth proxy are the same.

20. The method of claim 17 wherein the fourth proxy detects whether the second proxy and the fourth proxy are the same by comparing a received connection cookie to a stored connection cookie.

21. The method of claim 16 wherein transitioning server-to-client traffic to the new OUT channel comprises providing data queued at the first proxy to the third proxy.

22. The method of claim 16 wherein transitioning server-to-client traffic to the new IN channel comprises providing data queued at the second proxy to the fourth proxy.

23. A computer-readable medium having computer-executable instructions for performing the method of claim 16.

24. In a computer network having a client and a server, a system comprising:

a client runtime that provides client requests;

a channel establishment mechanism that establishes a first unidirectional channel for client-to-server requests, and second a unidirectional channel for server-to-client replies, each channel having a finite lifetime;

a lifetime tracking mechanism that tracks the lifetime of the first channel, including by counting the size of the request data sent to the server with respect to the finite lifetime of the first channel; and

a channel recycle mechanism that replaces the first channel with a new channel when the first channel approaches or reaches expiration of its lifetime as detected by the lifetime tracking mechanism, the channel recycle mechanism operating transparent to the client runtime such that a virtual channel that never expires is available for sending data from the runtime to the server.

26. The system of claim 24 further comprising, a second lifetime tracking mechanism at the server that tracks the lifetime of the second channel, including by counting the size of the reply data sent to the client with respect to the finite lifetime of the channel;

and

a channel recycle mechanism that replaces the second channel with a new channel for server-to-client replies when the second channel approaches or reaches expiration of its lifetime as detected by the second lifetime tracking mechanism to provide a second virtual channel that never expires sending replies from the server to the client runtime.

29. The system of claim 24 wherein each channel complies with a hypertext transfer protocol.

30. The system of claim 24 wherein the server-to-client channel is via an OUT channel proxy between the server and client.

31. The system of claim 30 wherein the OUT channel proxy flow controls the server and the client flow controls the OUT channel proxy.

32. The system of claim 24 wherein the client-to-server channel is via an IN channel proxy between the client and server.

33. The system of claim 32 wherein the IN channel proxy flow controls the client and the server flow controls the IN channel proxy.

25. The system of 24 further comprising, a timer that triggers a ping of the client-to-server channel.

27. The system of 24 further comprising, a timer that triggers a ping of the server-to-client channel.

28. The system of 24 wherein the runtime comprises an RPC runtime connected for handling function calls from a client application that correspond to RPC requests.

34. In a client computer that communicates with a network server, a method comprising:

establishing a first connection with the server;

establishing a second connection with the server, the second connection having a limited lifetime;

receiving requests;

sending request data to the server via the second connection;

receiving replies from the server via the first connection in response to the requests;

tracking the amount of request data sent over the second connection with respect to the limited lifetime of the second connection; and

recycling the second connection as a new second connection to maintain at least one connection for sending the request data to the server when the second connection expires.

35. The method of claim 34 wherein the first connection with the server is via a first proxy, and wherein the second connection with the server is via a second proxy.

36. The method of claim 34 wherein the second connection will time out if determined to be idle, and further comprising, transmitting data on the second connection to prevent the second connection from being determined as idle.

37. The method of claim 34 wherein the first and second connections comprise HTTP connections, and wherein the request data and reply data comprise RPC data.

38. A computer-readable medium having computer-executable instructions for performing the method of claim 34.