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

• US 7,685,287 B2
• Filed: 05/30/2002
• Issued: 03/23/2010
• 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.
• Primary Examiner(s): Lin; Kenny S
• Assistant Examiner(s): TRUONG, LAN DAI T
• Application Number:
  US10/158,239
• Publication Number:
  US 20030225889A1
• Time in Patent Office: 2,854 Days
• Field of Search: 709/227, 709/201, 709/203, 709/217, 709/230, 709/237, 709/238, 370/351, 718/1
• 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 and wherein the IN channel complies with a hypertext transfer protocol;

establishing an OUT channel for server-to-client traffic, the OUT channel having a lifetime that expires and wherein the OUT channel complies with the hypertext transfer protocol;

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

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

prior to the expiration of the IN channel, establishing a new IN channel, wherein the new IN channel complies with the hypertext transfer protocol, wherein the expiration of the IN channel is determined by counting a size of request data sent from the client to the server with respect to the lifetime of the IN channel; and

prior to the expiration of the OUT channel, establishing a new OUT channel, wherein the new OUT channel complies with the hypertext transfer protocol, wherein the expiration of the OUT channel is determined by counting a size of data sent from the server to the client with respect to the lifetime of the OUT channel, and wherein the establishing of the new IN channel and the new OUT channel recycle the established IN channel and OUT channel to provide a virtual connection between the client and the server 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 includes 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 includes 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:

communicating some data over a channel detected not to have data communicated thereon for a defined period.

7. The method of claim 1 wherein the IN channel has an IN-channel reserved lifetime, and the OUT channel has an OUT-channel reserved lifetime, the method further comprising:

when data reaches the IN-channel reserved lifetime on the IN channel, begin establishing the new IN channel; and

when data reaches the OUT-channel reserved lifetime on the OUT channel, begin establishing the new OUT channel.

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 the OUT proxy and the IN proxy each provides a receive window for flow control.

9. The method of claim 8 wherein the IN proxy provides a receive window for flow control, wherein the new IN proxy continues to use the receive window flow control from the IN proxy in response to identifying that the IN proxy is the same as the new IN proxy.

10. The method of claim 1 wherein the IN channel corresponds to an IN proxy, and further comprising:

providing a new IN proxy upon establishing the new IN channel.

11. The method of claim 1 wherein the OUT channel corresponds to an OUT proxy, and further comprising:

providing a new OUT proxy upon establishing the new OUT channel.

12. The method of claim 11 wherein the OUT proxy provides a receive window for flow control, wherein the new OUT proxy continues to use the receive window flow control from the OUT proxy in response to identifying that the OUT proxy is the same as the new OUT proxy.

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

14. 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 as the OUT channel, wherein the OUT channel complies with a hypertext transfer protocol;

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, wherein the IN channel complies with the hypertext transfer protocol;

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, wherein the new OUT channel complies with the hypertext transfer protocol, and wherein the request from the server to recycle the OUT channel is generated before expiration of the OUT channel, wherein the expiration is determined by counting a size of request data sent from the server to the client; 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, wherein the new IN channel complies with the hypertext transfer protocol, and wherein the request from the client to recycle the IN channel is generated before expiration of the IN channel, wherein the expiration is determined by counting a size of data sent from the client to the server.

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

16. The method of claim 15 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.

17. The method of claim 15 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.

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

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

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

21. A method of creating a bi-directional virtual channel for transporting RPC information between a client and a server comprising:

establishing a first HTTP IN channel having a predetermined lifetime, wherein the first HTTP IN channel automatically expires upon reaching the predetermined lifetime and wherein the first HTTP IN channel transports a first portion of RPC information from the client to the server; and

prior to expiration of the first HTTP IN channel, recycling the IN channel by establishing a second HTTP IN channel, the second HTTP IN channel transports a second portion of RPC information from the client to the server following expiration of the first HTTP IN channel, wherein the expiration of the first HTTP IN channel is determined by counting the size of the request data sent to the server with respect to the predetermined lifetime of the first HTTP IN channel.

22. The method as defined in claim 21 further comprising:

establishing a first HTTP OUT channel having an associated predetermined lifetime, wherein the first HTTP OUT channel automatically expires upon reaching the predetermined lifetime and wherein the first HTTP OUT channel transports a third portion of RPC information from the server to the client; and

prior to expiration of the first HTTP OUT channel, establishing a second HTTP OUT channel, the second HTTP OUT channel transports a fourth portion of RPC information from the server to the client following expiration of the first HTTP OUT channel.