Source: http://www.google.de/patents/US6742044
Timestamp: 2013-05-21 22:45:29
Document Index: 291822043

Matched Legal Cases: ['Application No. 60', 'Application No. 09', 'Application No. 09', 'application No. 09', 'Application No. 09', 'application No. 09']

Patent US6742044 - Distributed network traffic load balancing technique implemented without ... - Google PatenteSuche Bilder Maps Play YouTube News Gmail Drive Mehr » Erweiterte Patentsuche | Webprotokoll | Anmelden Erweiterte Patentsuche PatenteThe technique of the present invention provides a solution to the problem of routing or redirecting a given client to a replica or proxy server which has a relatively shortest propagation delay to the client. According to the technique of the present invention, a network device referred to as an intercept...http://www.google.de/patents/US6742044?utm_source=gb-gplus-sharePatent US6742044 - Distributed network traffic load balancing technique implemented without gateway router Ver�ffentlichungsnummerUS6742044 B1PublikationstypErteilung Anmeldenummer09/569,090 Ver�ffentlichungsdatum25. Mai 2004Eingetragen10. Mai 2000 Priorit�tsdatum10. Mai 2000Auch ver�ffentlicht unterUS7401159 ErfinderJames AvianiDavid Eric SwansonFrederick BakerII Kenneth E. MuellerMatthew Richard GnagyUrspr�nglich Bevollm�chtigterCisco Technology, Inc.Cisco Technolgy, Inc. US-Klassifikation709/235709/238709/229709/227709/226709/225Internationale KlassifikationH04L29/08H04L29/06G06F15/16 UnternehmensklassifikationH04L29/08171H04L29/0818H04L29/08738H04L29/06095H04L29/08144H04L29/08261H04L29/06115H04L29/08216 Europ�ische KlassifikationH04L29/08N9A1BH04L29/08N9A1CH04L29/08N9A1GH04L29/08N9A7H04L29/06J7H04L29/08N9AH04L29/08N27DReferenzenPatentzitate (46)Nichtpatentzitate (31) Referenziert von (43)Externe LinksUSPTO USPTO-Zuordnung EspacenetDistributed network traffic load balancing technique implemented without gateway routerUS 6742044 B1 Zusammenfassung The technique of the present invention provides a solution to the problem of routing or redirecting a given client to a replica or proxy server which has a relatively shortest propagation delay to the client. According to the technique of the present invention, a network device referred to as an intercept server sits in front of a host server, and intercepts packets routed to the host server. When desired, packets which are intercepted by the intercept server are replicated, encapsulated and tunneled to selected client servers in the overlay network. The tunneled packets are received and processed by each of the selected client servers, whereupon each of the selected client servers generates a respective spoofed response to the source device identified in the header of the originally intercepted packet. Further, according to the technique of the present invention, each of the selected client servers transmits its respective spoofed response to the identified source device at substantially the same time. The client server associated with the spoofed response which is first received at the identified source device is considered to have the relatively shortest propagation delay to the identified source device, and is identified as the successful client server. Thereafter, the source device will be directed or redirected to communicate directly with the successful client server when subsequently attempting to access information from the host server.
What is claimed is: 1. A method for routing traffic in a data network, the data network including a sub-network of client servers which include information corresponding to information stored on at least one host server, the method comprising:
receiving, at a first device, a first packet from a source device destined to a host server; identifying the source device using information from the first packet; selecting, using the identified source device information, a first portion of the client servers for forwarding information relating to the first packet, wherein the first portion includes two or more client servers; forwarding information relating to the first packet from the first device to the first portion of the client servers; causing each of the first potion of client servers to respond to the source device at substantially the same time, wherein said causing is performed by the first devices; determining a specific trigger time reference value for causing each of the first portion of client servers to transmit a respective spoofed response to the first request at a time corresponding to the trigger time reference value; and transmitting said trigger time reference value to each of the first portion of client servers along with the forwarded first request information to thereby cause each of the first portion of client servers to transmit a respective response to the source device at substantially the same time. 2. The method of claim 1 further comprising:
assigning a unique starting sequence number to each of the first portion of client servers, wherein each starting sequence number corresponds to a SYN, ACK segment of a TCP protocol, wherein the assigning is performed by the intermediary device. 3. The method of claim 2 further comprising causing each of the first portion of client servers to include its assigned starting sequence number in its response transmitted to the source device.
4. The method of claim 1 wherein the source device corresponds to a client system.
5. The method of claim 1 wherein said forwarding further includes:
encapsulating the received first packet in accordance with an encapsulation tunneling protocol; and transmitting the encapsulated packet to each of the first portion of client servers using the encapsulation tunneling protocol. 6. The method of claim 5 further comprising:
receiving, at a first client server, the encapsulated packet; generating, at said first client server using information from said received encapsulated packet, a first spoofed response to said first packet; and transmitting said first spoofed response to the source device. 7. The method of claim 6 wherein the first packet utilizes a TCP protocol, and wherein the first spoofed response comprises a TCP acknowledgement segment having an associated sequence number, the sequence number including information relating to an identity of the first client server.
8. The method of claim 1 further comprising determining a respective propagation delay value associated with communicating with each client server of at least the first portion of client servers; and
using the propagation delay information to forward the information relating to the first packet to the first portion such that the forwarded first packet information is received at each of the first portion of client servers at substantially the same time. 9. The method of claim 1 further comprising:
receiving, at the source device, a plurality of responses to the first packet from at least some of the first portion of client servers; processing an earliest received response of the plurality of received responses in accordance with a first technique, wherein said first technique includes using information from the earliest received response at the source device to conduct subsequent communication transactions; and processing at least one duplicate responses to the first packet in accordance with a second technique, wherein said second technique includes not using information from the at least one duplicate received response at the source device to conduct subsequent communication transactions. 10. The method of claim 9 wherein said plurality of responses are received using a TCP protocol.
wherein said selecting includes identifying at least one preferred client server associated with the identified source device; and wherein said first plurality of client servers includes said at least one preferred client server and at least one randomly selected client server from the sub-network. 12. The method of claim 11 further comprising:
identifying a successful client server of said first portion of client servers associated with generating a response to the first packet which was first received at the source device; and if the identified client server is not classified as a preferred client server for communicating with the identified source device, classifying the identified client server as one of the at least one preferred client servers for communicating with the identified source device. 13. The method of claim 12 further comprising selecting a least preferred one of the at least one preferred client servers for preferred status degradation in response to the identified client server being classified as a preferred client server.
14. The method of claim 1 wherein the first packet utilizes a TCP protocol, the method further comprising:
receiving a TCP acknowledgement (ACK) segment from the source device, said ACK segment having an associated sequence number which includes information relating to an identity of a successful client server of the first plurality of client servers which generated a response to the forwarded first packet information that was first received at the source device; identifying the successful client server using information from the received ACK segment; encapsulating the received ACK segment in accordance with an encapsulation tunneling protocol; and transmitting, using the encapsulation tunneling protocol, the encapsulated packet to the successful client server. 15. The method of claim 14 further comprising issuing a TCP reset packet to each of the other client servers of the first portion of client servers which are not identified as the successful client server.
identifying a successful client server of said first portion of client servers associated with generating a response to the first packet which was first received at the source device; receiving a second packet from said source device, said second packet relating to a request to access data from said host server; encapsulating the second packet; tunneling the encapsulated second packet to the successful client server; generating, at the successful client server, a spoofed response to the source device, wherein the spoofed response includes a redirect response.
17. A method for routing traffic in a data network, the data network including a sub-network of client servers which include information corresponding to information stored on at least one host server, the method comprising:
receiving, at a first client server, a tunneled packet and timing information from an intercept server, said tunneled packet including encapsulated information relating to a first packet intercepted by the intercept server, said first packet including a source address and a destination address, said source address corresponding to a source device which generated the first packet, said first packet information relating to a request to open a communication connection with a host server; generating, at said first client server using information from said received tunneled packet, a first spoofed response to said request, wherein the first spoofed response includes information for identifying the first client server; and transmitting said first spoofed response to the source device so that the first spoofed response is transmitted at a time specified by the timing information received from the intercept server. 18. The method of claim 17 wherein the first packet corresponds to a SYN segment of a communication utilizing a TCP protocol, and wherein the first spoofed response comprises a SYN, ACK segment which includes a first sequence number, the first sequence number including information relating to an identity of the first client server.
19. The method of claim 18 wherein the tunneled packet includes information relating to the first sequence number included in the SYN, ACK segment, said method further comprising utilizing the first sequence number information in generating the first spoofed response.
20. The method of claim 18 wherein the sequence number corresponds to an IP address of the first client server.
21. The method of claim 17 wherein the tunneled packet includes transmission timing information relating to a specific trigger time at which the first client server is to transmit the first spoofed response to the source device, said method further comprising transmitting the first spoofed response to the source device at the specific trigger time.
22. The device of claim 17 wherein the tunneled packet includes transmission timing information relating to a specific transmission delay time value in which the first client server is to delay transmission of the first spoofed response to the source device, said method further comprising delaying transmission of the first spoofed response to the source device until a time period corresponding to the transmission delay time value has elapsed.
receiving, at a second client server, a tunneled packet from the intercept server, said tunneled packet including encapsulated information relating to a first packet intercepted by the intercept server, said first packet including a source address and a destination address, said source address corresponding to a source device which generated the first packet, said first packet information relating to a request to open a communication connection with a host server; generating, at said first client server using information from said received tunneled packet, a second spoofed response to said request, wherein the second spoofed response includes information for identifying the second client server; and transmitting said second spoofed response to the source device at substantially a same time that said first spoofed response is transmitted to the source device. 24. The method of claim 23 wherein the first packet corresponds to a SYN segment of a communication utilizing a TCP protocol, and wherein the second spoofed response comprises a SYN, ACK segment which includes a second sequence number, the second sequence number including information relating to an identity of the second client server.
25. The method of claim 17 wherein the tunneled packet includes information relating to a specific trigger time for transmitting a response to the source device;
wherein said transmitting includes transmitting the first and second spoofed responses from each respective client server to the source device at a time value corresponding to the specific trigger time. 26. The method of claim 25 further comprising synchronizing said intercept server, said first client servers and said second client server.
27. A method for routing traffic in a data network, the data network including a sub-network of client servers which include information corresponding to information stored on at least one host server, the method comprising:
receiving, at a first plurality of client servers, a respective tunneled packet and timing information from an intercept server, said tunneled packet including encapsulated information relating to a first packet intercepted by the intercept server, said first packet including a source address and a destination address, said source address corresponding to a source device which generated the first packet, said first packet information relating to a request to open a communication connection with a host server; generating, at each of the first plurality of client servers a respective spoofed response to said first packet using information from said received tunneled packet, wherein the each spoofed response includes information for identifying a client server which generated the spoofed response; and transmitting each of the respective spoofed responses at substantially a same time to the source device as specified by the timing information received from the intercept server. 28. The method of claim 27 further comprising:
receiving, at the source device, a plurality of responses to the first packet from at least some of the first portion of servers; processing an earliest received response of the plurality of received responses in accordance with a first technique, wherein information from the earliest received response is used by the source device to conduct subsequent communication transactions; and processing at least one duplicate responses to the first packet in accordance with a second technique, wherein information from the at least one duplicate received response is not used by the source device to conduct subsequent communication transactions. 29. The method of claim 28 wherein said plurality of responses are received using a TCP protocol.
30. The method of claim 28:
wherein the first packet corresponds to a SYN record query for a specific domain name; wherein the source device includes a client for receiving the plurality of responses; and wherein said processing includes: determining, using information from said earliest received response, a specific IP address associated with the specific domain name, the specific IP address corresponding to a successful server which transmitted the earliest received response; and binding the specific IP address with the specific domain name. 31. A computer program product for routing traffic in a data network, the data network including a sub-network of client servers which include information corresponding to information stored on at least one host server, the computer program product comprising:
a computer usable medium having computer readable code embodied therein, the computer readable code comprising: computer code for receiving, at a first device, a packet from a source device destined to a host server; computer code for identifying the source device using information from the first packet; computer code for selecting, using the identified source device information, a first portion of the client servers for forwarding the first packet, wherein the first portion includes two or more client servers; computer code for forwarding information from the first device relating to the first packet to the first portion of the client servers; and computer code for causing each of the first potion of client servers to respond to the source device at substantially the same time, wherein said causing is performed by the first devices computer code for determining a trigger time value for causing each of the first portion of client servers to transmit a respective response to the first packet at the specified trigger time; and computer code for transmitting said trigger time value to each of the first portion of client servers along with the forwarded first packet information to thereby cause each of the first portion of client servers to transmit a respective response to the source device at substantially the same time. 32. The computer program product of claim 31 further comprising computer code for determining a respective propagation delay value associated with communicating with each client server of at least the first portion of client servers;
wherein said forwarding computer code includes computer code for transmitting said first packet information to each of the first portion of client servers at specific times such that the forwarded first packet information is received at each of the first portion of client servers at substantially the same time. 33. A computer program product for routing traffic in a data network, the data network including a sub-network of client servers which include information corresponding to information stored on at least one host server, the computer program product comprising:
a computer usable medium having computer readable code embodied therein, the computer readable code comprising: computer code for receiving, at a first client server, a tunneled packet and timing information from an intercept server, said tunneled packet including information relating to a request from a source device to open a communication connection with a host server; computer code for generating, at said first client server using information from said received tunneled packet, a first spoofed response to said first packet; and computer code for transmitting said first spoofed response to the source device so that the age first spoofed response is transmitted at a time specified by the timing information received from the intercept server. 34. The computer program product of claim 33 further comprising:
computer code for receiving, at a second client server, a tunneled packet from said intercept server, said tunneled packet including information relating to a request from a source device to open a communication connection with a host server; computer code for generating, at said second client server using information from said received tunneled packet, a second spoofed response to said first packet; computer code for transmitting said second spoofed response to the source device at substantially the same time that said first spoofed response is transmitted to the source device. 35. A system for facilitating a client device to access a specific server in a data network, the system comprising:
a sub-network of client servers which include information corresponding to information stored on at least one host server; and at least one intercept server configured or designed to intercept at least one packet routed to the at least one host server, said intercept server being further configured or designed to identify a source device associated with generating the intercepted packet; said intercept server being further configured or designed to forward information relating to the first packet to a selected portion of the client servers, wherein the first portion includes two or more client servers; said intercept server being further configured or designed to cause each of the selected potion of client servers to respond to the source device at substantially the same times, wherein said intercept server is further configured or designed to determine a trigger time value for cause each of the selected portion of client servers to transmit a respective response to the first packet at the specified trigger time, and is further configured or designed to transmit said trigger time value to each of the selected portion of client servers along with the forwarded first packet information to thereby cause each of the selected portion of client servers to transmit a respective response to the source device at substantially the same time. 36. The system of claim 35 wherein the intercept server is further configured or designed to assign a unique starting sequence number to each of the selected portion of client servers, wherein each starting sequence number corresponds to a SYN, ACK segment of a TCP protocol.
37. The system of claim 36 wherein the intercept server is further configured or designed to cause each of the selected portion of client servers to include its assigned starting sequence number in the first spoofed response transmitted to the source device.
38. The system of claim 35 wherein said intercept server is further configured or designed to encapsulate the received first packet in accordance with an encapsulation tunneling protocol, and is further configured or designed to transmit the encapsulated packet to each of the selected portion of client servers using the encapsulation tunneling protocol.
39. The system of claim 35 wherein said intercept server is further configured or designed to determine a respective propagation delay value associated with communicating with each client server of at least the selected portion of client servers, and is further configured or designed to transmit said first packet information to each of the selected portion of client servers at specific times such that the forwarded first packet information is received at each of the selected portion of client servers at substantially the same time.
40. The system of claim 35 wherein said intercept server includes memory comprising information relating to at least one preferred client server associated with the source device, wherein the intercept server is further configured or designed to identify, using the identified source device information, the at least one preferred client server for communicating with said source device;
wherein said first plurality of client servers includes said at least one preferred client server and at least one randomly selected client server associated with the sub-network. 41. The system of claim 40 wherein said intercept server is further configured or designed to identify a successful client server of said selected portion of client servers associated with generate a response to the first packet which was first received at the source device, and is further configured or designed to classify the identified client server as one of the at least one preferred client servers for communicate with the identified source device if the identified client server is not classified as a preferred client server for communicate with the identified source device, classify the identified client server as one of the at least one preferred client servers for communicate with the identified source device.
42. The system of claim 41 wherein said intercept server is further configured or designed to select a least preferred one of the at least one preferred client servers for preferred status degradation in response to the identified client server bee classified as a preferred client server.
43. The system of claim 35 wherein the intercept server is configured or designed to communicate with the source device using a TCP protocol,
said intercept server being further configured or designed to receive a TCP acknowledgement (ACK) segment from the source device, said ACK segment having an associated sequence number which includes information relating to an identity of a successful client server of the first plurality of client servers which generated a response to the forwarded first packet that was first received at the source device; said intercept server being further configured or designed to identify the successful client server use information from the received ACK segment; said intercept server being further configured or designed to encapsulate the received ACK segment in accordance with an encapsulation tunneling protocol; and said intercept server being further configured or designed to transmit, using the encapsulation tunneling protocol, the encapsulated packet to the successful client server. 44. The system of claim 43 wherein said intercept server is further configured or designed to issue a TCP reset packet to each of the other client servers of the selected portion of client servers which were not identified as the successful client server.
45. The system of claim 35 further wherein said intercept server is further configured or designed to identify a successful client server of said selected portion of client servers associated with generate a response to the first packet which was first received at the source device;
said intercept server being further configured or designed to receive a second packet from said source device to access data from said host server; said intercept server being further configured or designed to encapsulate the second first packet; said intercept server being further configured or designed to tunnel the encapsulated first packet to the successful client server; wherein said successful client server is configured or designed to generate a spoofed response to the source device, wherein the spoofed response includes a redirect packet. 46. A network device comprising:
at least one CPU; memory, said memory including a first portion of memory configured or designed to store information associated with at least one host server in a data network; and at least one interface for receiving a tunneled packet and timing information from an intercept server, said tunneled packet including encapsulated information relating to a first packet intercepted by the intercept server, said first packet including a source address and a destination address, said source address corresponding to a source device associated with generating the first packet, said first packet information relating to a request to open a communication connection with a host server; said network device being configured or designed to generate, using information from said received tunneled packet, a first spoofed response to said request, wherein the first spoofed response includes information for identifying the first client server; said network device being further configured or designed to transmit said first spoofed response to the source device so that the first spoofed response is transmitted at a time specified by the timing information received from the intercept server. 47. The device of claim 46 wherein the first packet corresponds to a SYN segment of a communication utilizing a TCP protocol, and wherein the first spoofed response comprises a SYN, ACK segment which includes a first sequence number, the first sequence number including information relating to an identity of the first client server.
48. The device of claim 47 wherein the tunneled packet includes information relating to the first sequence number included in the SYN, ACK segment, and wherein the device is configured or designed to utilize the first sequence number information when generating the first spoofed response.
49. The device of claim 46 wherein the tunneled packet includes transmission timing information relating to a specific time at which the network device is to transmit the first spoofed response to the source device, and wherein the network device is further configured or designed to transmit the first spoofed response to the source device at the specified time.
50. A system for routing traffic in a data network, the data network including at least one host server and an intercept server configured or designed to intercept packets directed to the at least one host server, the system comprising:
a plurality of client servers configured or designed to store information corresponding to information stored on the at least one host server; wherein the plurality of client servers includes: a first client server configured or designed to receive a tunneled packet and timing information from the intercept server, said tunneled packet including information relating to a request from a source device to open a communication connection with a host server; the first client server being further configured or designed to generate, using information from the received tunneled packet, a first spoofed response to said first packet; and wherein the first client server is further configured or designed to transmit said first spoofed response to the source device so that the first spoofed response is transmitted at a time specified by the timing information received from the intercept server. 51. The system of claim 50, wherein the first client server is configured or designed to communicate using a TCP protocol, and wherein the first spoofed response comprises a TCP acknowledgement segment having an associated sequence number, the sequence number include information relate to an identity of the first client server.
52. The system of claim 51 wherein the sequence number corresponds to an IP address of the first client server.
53. The system of claim 50 wherein said source device is configured or designed to receive a plurality of responses to the first packet from at least some of the selected portion of client servers;
said source device being further configured or designed to process an earliest received response of the plurality of received responses in accordance with a first technique, wherein information from the earliest received response is used by the source device to conduct subsequent communication transactions; and wherein said source device is further configured or designed to process at least one duplicate responses to the first packet in accordance with a second technique, wherein information from the at least one duplicate received response is not used by the source device to conduct subsequent communication transactions. 54. The system of claim 53 wherein the first packet corresponds to a SYN record query for a specific domain name; wherein the source device includes a client for receiving the plurality of responses; and wherein the client is configured or designed to determine, using information from said earliest received response, a specific IP address associated with the specific domain name, the specific IP address corresponding to a successful server which transmitted the earliest received response; and wherein the client is further configured or designed to bind the specific IP address with the specific domain name. 55. The system of claim 53 wherein said source device is configured or designed to communicate using a TCP protocol.
56. A system for routing a client device to access a specific server in a data network, the system comprising:
a sub-network of client servers which include information corresponding to information stored on at least one host server; and at least one intercept server configured or designed to intercept at least one packet routed to the at least one host server, the intercepted packet including information for identifying a source device associated with the packet, the intercept server being further configured or designed to forward information relating to the intercepted packet and timing information to a selected portion of the client servers in the sub-network, wherein the selected portion includes two or more client servers; wherein each of the selected portion of client servers is configured or designed to transmit, at substantially the same time based on the received timing information from the intercept server, a respective spoofed response to the source device, wherein each spoofed response is generated using information from the intercepted packet. 57. The system of claim 56 wherein the intercept server is further configured or designed to determine a successful client server associated with generating a particular spoofed response which was received first at the source device, the successful client server being one of the selected portion of client servers, and is further configured or designed to bind an ID of the source device with an ID of the successful client server device. 58. The system of claim 57 further wherein the system is configured or designed to cause the source device to communicate with the successful client server for accessing information associated with the at least one host server.
59. The system of claim 57 wherein the intercepted packet corresponds to a SYN segment for a communication with the at least one host server utilizing a TCP protocol, and wherein each spoofed response comprises a SYN, ACK segment which includes a sequence number relating to an identity of a client server generating the spoofed response.
60. A system for routing traffic in a data network, the data network including a sub-network of client servers which include information corresponding to information stored on at least one host server, the system comprising:
means for receiving, at a first client server, a tunneled packet and timing information from an intercept server, said tunneled packet including encapsulated information relating to a first packet intercepted by the intercept server, said first packet including a source address and a destination address, said source address corresponding to a source device which generated the first packet, said first packet information relating to a request to open a communication connection with a host server; means for generating, at said first client server using information from said received tunneled packet, a first spoofed response to said request, wherein the first spoofed response includes information for identifying the first client server; and means for transmitting said first spoofed response to the source device so that the first spoofed response is transmitted at a time specified by the timing information received from the intercept server. 61. A method for routing traffic in a data network, the data network including a sub-network of client servers which include information corresponding to information stored on at least one host server, the method comprising:
receiving, at a first device, a first packet from a source device destined to a host server; identifying the source device using information from the first packet; selecting, using the identified source device information, a first portion of the client servers for forwarding information relating to the first packet, wherein the first portion includes two or more client servers; forwarding information relating to the first packet from the first device to the first portion of the client servers; causing each of the first potion of client servers to respond to the source device at substantially the same time, wherein said causing is performed by the first device; determining a respective propagation delay value associated with communicating with each client server of at least the first portion of client servers; using the propagation delay information to generate a respective transmission delay time value for each of the first portion of client servers; and transmitting said transmission delay time values to each respective client server of the first portion of client servers along with the forwarded first request information to thereby cause each of the first portion of client servers to delay transmission of its respective spoofed response to the source device until a time period corresponding to the transmission delay time value has elapsed. 62. The method of claim 61 further comprising:
assigning a unique starting sequence number to each of the first portion of client servers, wherein each starting sequence number corresponds to a SYN, ACK segment of a TCP protocol, wherein the assigning is performed by the intermediary device. 63. The method of claim 62 further comprising causing each of the first portion of client servers to include its assigned starting sequence number in its response transmitted to the source device.
64. The method of claim 61 wherein the source device corresponds to a client system.
65. The method of claim 61 wherein said forwarding further includes:
encapsulating the received first packet in accordance with an encapsulation tunneling protocol; and transmitting the encapsulated packet to each of the first portion of client servers using the encapsulation tunneling protocol. 66. The method of claim 65 further comprising:
receiving, at a first client server, the encapsulated packet; generating, at said first client server using information from said received encapsulated packet, a first spoofed response to said first packet; and transmitting said first spoofed response to the source device. 67. The method of claim 66 wherein the first packet utilizes a TCP protocol, and wherein the first spoofed response comprises a TCP acknowledgement segment having an associated sequence number, the sequence number including information relating to an identity of the first client server.
68. The method of claim 61 further comprising determining a respective propagation delay value associated with communicating with each client server of at least the first portion of client servers; and
using the propagation delay information to forward the information relating to the first packet to the first portion such that the forwarded first packet information is received at each of the first portion of client servers at substantially the same time. 69. The method of claim 61 further comprising:
receiving, at the source device, a plurality of responses to the first packet from at least some of the first portion of client servers; processing an earliest received response of the plurality of received responses in accordance with a first technique, wherein said first technique includes using information from the earliest received response at the source device to conduct subsequent communication transactions; and processing at least one duplicate responses to the first packet in accordance with a second technique, wherein said second technique includes not using information from the at least one duplicate received response at the source device to conduct subsequent communication transactions. 70. The method of claim 69 wherein said plurality of responses are received using a TCP protocol.
71. The method of claim 61 wherein said selecting includes identifying at least one preferred client server associated with the identified source device; and wherein said first plurality of client servers includes said at least one preferred client server and at least one randomly selected client server from the sub-network. 72. The method of claim 71 further comprising:
identifying a successful client server of said first portion of client servers associated with generating a response to the first packet which was first received at the source device; and if the identified client server is not classified as a preferred client server for communicating with the identified source device, classifying the identified client server as one of the at least one preferred client servers for communicating with the identified source device. 73. The method of claim 72 further comprising selecting a least preferred one of the at least one preferred client servers for preferred status degradation in response to the identified client server being classified as a preferred client server.
74. The method of claim 61 wherein the first packet utilizes a TCP protocol, the method further comprising:
receiving a TCP acknowledgement (ACK) segment from the source device, said ACK segment having an associated sequence number which includes information relating to an identity of a successful client server of the first plurality of client servers which generated a response to the forwarded first packet information that was first received at the source device; identifying the successful client server using information from the received ACK segment; encapsulating the received ACK segment in accordance with an encapsulation tunneling protocol; and transmitting, using the encapsulation tunneling protocol, the encapsulated packet to the successful client server. 75. The method of claim 74 further comprising issuing a TCP reset packet to each of the other client servers of the first portion of client servers which are not identified as the successful client server.
76. The method of claim 61 further comprising:
RELATED APPLICATION DATA This invention is related to U.S. patent application Ser. No. 09/569,090, filed concurrently herewith, naming James Aviani, David Eric Swanson, Frederick Baker, Kenneth E. Mueller II, and Matthew Richard Gnagy as inventors, and entitled, �DISTRIBUTED NETWORK TRAFFIC LOAD BALANCING TECHNIQUE IMPLEMENTED WITHOUT GATEWAY ROUTER.� That application is incorporated herein by reference in its entirety and for all purposes.
More importantly, the Akaimi routing technique is limited only to resolving DNS queries implemented using DNS protocol. Currently, the Akaimi technique for re-routing clients to a nearest proxy server is not extendable to other protocols such as, for example, TCP. Thus, for example, when a client obtains a particular IP address of a server, and subsequently attempts to initiate a TCP connection with that server, the Akaimi technique can not be used to re-route the client to establish a TCP connection with a topologically closer proxy server.
SUMMARY OF THE INVENTION According to specific embodiments of the present invention, a technique is provided for routing a client device to access a specific client server in a data network. The data network may include at least one host server, a sub-network of client servers associated with the at least one host server, and at least one client system. According to one embodiment, the data network corresponds to the Internet, wherein the at least one host server corresponds to the host server of a content provider, the sub-network of client servers corresponds to an overlay network of proxy or replica servers.
Other embodiments of the present invention are directed to a method and computer program product for routing a client device to access a specific server in a data network. The data network includes a sub-network of client servers which are configured to include information corresponding to information stored on at least one host server. A first packet is received from a source device. Information relating to the first packet is then forwarded to a first portion of client servers in the sub-network. Each of the first portion of client servers is then caused to transmit, at substantially the same time, a respective spoofed response to the source device. Each spoofed response may be generated using information from the first packet. According to a specific embodiment, a successful client server may then be identified as being associated with generating a particular spoofed response that was first received at the source device. An ID of the source device may then be binded with an ID of the successful client server in order to cause subsequent requests from the source device to access information from the host server to be routed to the successful client server device for processing. Further, according to a specific implementation, the first packet received from the source device may correspond to a SYN segment of a TCP protocol for communicating with the host server. Additionally, each spoofed response may comprise a SYN, ACK segment which includes a unique sequence number relating to an identity of the client server which generated the spoofed response.
Additional embodiments of the present invention are directed to a method and computer program product for routing traffic in a data network. The data network comprises a sub-network of client servers configured to include information corresponding to information stored on at least one host server. A first packet from a source device is received at a first network device. The source device is identified using information from the first packet. Using the identified source device information, a first portion of the client servers is then selected for forwarding information relating to the first packet. Information relating to the first packet is then forwarded to the first portion of client servers. Each of the first portion of client servers is then caused to transmit a respective spoofed response to the source device at substantially the same time. According to a specific embodiment, the selection of the first portion of client servers may include at least one preferred client server associated with the identified source device, and may further include at least one randomly selected client server from the sub-network of client servers.
Further embodiments of the present invention are directed to a method and computer program product for routing traffic in a data network. The data network includes a sub-network of client servers configured to include information corresponding to information stored on at least one host server. A tunneled packet transmitted from an intercept server is received at a first client server. The tunneled packet includes encapsulated information related to a first packet intercepted by the intercept server. The first packet includes a source address and a destination address. The source address corresponds to a source device which generated the first packet. The first packet information relates to a request to open a communication connection with a host server. The first client server generates a first spoofed response to the first packet request using information from the received tunneled packet. The first spoofed response further includes information for identifying the first client server which generated the first spoofed response. The first spoofed response is then transmitted to the source device. According to a specific implementation, the first packet corresponds to a SYN segment of a communication utilizing a TCP protocol. Further, according to this embodiment, the first spoofed response comprises a SYN, ACK segment which includes a first sequence number relating to an identity of the first client server.
An alternate embodiment of the present invention is directed to a system for routing a client device to access a specific server in a data network. The system comprises a sub-network of client servers configured to include information corresponding to information stored on at least one host server. The system may further comprise at least one intercept server configured to intercept at least one packet routed to a host server. The intercept server is further configured to identify a source device which generated the intercepted packet. The intercept server may further be configured to forward information relating to the first packet to a selected portion of client servers. Further, the intercept server may be configured to cause each of the selected client servers to transmit a respective spoofed response to the source device at substantially the same time.
Another embodiment of the present invention is directed to a network device comprising at least one CPU and memory. The memory may include a first portion of memory configured to store content information which is substantially similar to content information stored on at least one host server in a data network. The network device may further comprise at least one interface for receiving a tunneled packet from an intercept server. The tunneled packet may include encapsulated information relating to a first packet intercepted by the intercept server. The first packet may include a source address and destination address, wherein the source address corresponds to a source device associated with generating the first packet. The first packet information may relate to a request to open a communication connection with the host server. The network device may be further configured to generate, using information from the received tunneled packet, a first spoofed response to the source device request, wherein the first spoofed response includes information for identifying the first client server which generated the first spoofed response. Additionally, the network device may further be configured to transmit the first spoofed response to the source device.
An alternate embodiment of the present invention is directed to a system for routing a source device to access a specific server in a data network. The system comprises a sub-network of client servers configured to include information corresponding to information stored on at least one host server. The system further includes at least one intercept server configured to intercept at least one packet addressed to a host server. The intercepted packet includes information for identifying a source device associated with the packet. The intercept server is further configured to forward information relating to the intercepted packet to a selected portion of the client servers in the sub-network. Each of the selected client servers is configured to transmit, at substantially the same time, a respective spoofed response to the source device, wherein each spoofed response is generated using information from the intercepted packet. According to a specific implementation, the intercept server is configured to identify a successful client server which generated a spoofed response that was first received at the source device. The intercept server is further configured to bind an ID of the source device with an ID of the successful client server device. In this way, subsequent requests from the source device to access information from the host server may be forwarded to the successful client server for processing.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1A shows a conventional network configuration for implementing TCP over an IP network.
FIG. 1B shows a flow diagram illustrating a conventional TCP handshaking protocol between a client and host server.
FIG. 2 shows a block diagram of a data network 200 which may be used for implementing the technique of the present invention.
FIG. 5 shows a block diagram illustrating how synchronization may be achieved between each of the servers in the overlay network of the present invention.
FIGS. 6A, and 6B show flow diagrams illustrating how the technique of the present invention may be implemented in a data network which utilizes a TCP communication protocol.
FIG. 7 shows a flow diagram of a BCS Response Scaling Procedure 700 in accordance with a specific embodiment of the present invention.
FIG. 8 shows a block diagram of a network device 60 suitable for implementing the BOOM server or BOOM client server devices of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS In accordance with the several embodiments of the present invention described in this application, the technique of the present invention may be used to provide a solution to the problem of discovering a nearest replica or proxy server which has the smallest propagation delay to a particular client system, regardless of network changes or failures. A specific embodiment of the technique of the present invention is shown in FIGS. 2, 6A and 6B of the drawings, which illustrate how the technique of the present invention may be implemented in a data network which utilizes a TCP communication protocol. In order to gain a better understanding the TCP implementation of the present invention, it is helpful to review how TCP is implemented over conventional IP networks.
FIG. 1A shows a conventional network configuration for implementing TCP over an IP network. As shown in FIGURE IA, a client 102 communicates with host server 122 via internet 150. A detailed description of the Transmission Control Protocol (TCP) is described in RFC document number 793, incorporated herein by reference in its entirety for all purposes. A brief description of the conventional TCP handshaking protocol between the client and host server is shown in FIG. 1B of the drawings.
Referring to FIG. 1B, when a client 102 wishes to access host server 122, it first performs a three-way handshaking protocol 152 with the host server in order to establish a proper connection with the host server. Thus, as shown in FIG. 1B, the client first transmits (1) a synchronization (SYN) segment to the host server. The SYN segment will include a client sequence number (SEQ=n) which is generated by the client. When the host server receives the SYN segment, it responds (3) by providing a synchronization and acknowledgment (SYN, ACK) segment to the client. The SYN, ACK segment will include a host sequence number (SEQ=m) generated by the host server. The SYN, ACK segment will also include an acknowledgement (ACK=n+1) to the client sequence number, which, according to the conventional TCP protocol, should be equal to the value of the client sequence number (n) incremented by 1.
When the client receives the SYN, ACK segment from the host server, it then responds (5) with an ACK segment, which includes a client sequence number (SEQ=n+1), and an acknowledgment to the host sequence number (ACK=m+1). Once the host server receives the ACK segment from the client, the handshaking protocol between the client and host server is completed, and an open connection is established between the client and host server.
Once an open connection is established between the client and host server, the client may then access data from the host server such as, for example, by submitting (7) an HTTP request to the host server. As shown in the example of FIG. 1B, the HTTP request will also include an appropriate client sequence number (SEQ=n+1) and an appropriate acknowledgment sequence number (ACK=m+1). According to the standardized TCP protocol, it is important that both the client and host server transmit the proper acknowledgment number when responding to the other using the TCP protocol. For example, if the client transmits a sequence number SEQ=100, the host response should include an acknowledgment sequence number ACK=101. Similarly, if the host server transmits a sequence number SEQ=150, the client should respond with an acknowledgment sequence number ACK=151. According to the TCP protocol, if a device receives a packet which includes an improper acknowledgment sequence number, the device will disregard the packet.
FIGS. 2, 6A, and 6B illustrate how the technique of the present invention may be implemented in a data network which utilizes a TCP communication protocol. As shown in FIG. 2, the data network includes a client system 202, a host server 222, a BOOM server or intercept server 220, and a plurality of BOOM client servers 206 a, 206 b, 206 c. Together, the BOOM server 220 and plurality of BOOM client servers form an overlay network of the present invention. Each of the various devices shown in FIG. 2 may communicate with each other via a wide area network such as, for example, the Internet 150.
According to a specific embodiment, at least a portion of the BOOM client servers may be implemented as proxy or replica servers which automatically handle the complex task of retrieving and cashing desired information from the host server, and managing the retrieved data to ensure the cached data is up to date. Alternatively, one or more of the BOOM servers may be implemented as data caches which cache at least a portion of the data located on host server 222, and use the cached data to respond to a variety of different client requests such as, for example, HTTP requests. According to this embodiment, if a BOOM client server receives a request for data which is not cached on that server, the BOOM client server retrieves the desired data from the host server 222 and stores the retrieved data in the BOOM client server cache for servicing subsequent data requests.
FIGS. 6A and 6B illustrate a flow diagram of a specific embodiment for implementing the technique of the present invention over the data network 200 of FIG. 2. In the example of FIG. 6A, it is assumed that a client 202 has obtained the IP address of host server 222, and wishes to access data from the host server such as, for example, by submitting a HTTP request to the host server. However, before the client system is able to send an HTTP request to the host server, it must first initiate the TCP handshaking protocol described previously with respect to FIG. 1B.
Thus, referring to FIG. 6A, at 26, the client system 202 sends a SYN packet to the host server 222. The SYN packet comprises a client sequence number (SEQ=n), and a packet header which includes tuple information such as, for example, a source IP address, a destination IP address, a source port number, and a destination port number.
According to at least one embodiment, the BOOM server 220 is configured to sit in front of the host server 222, and inspect all or a portion of selected packets routed to the host server. When the SYN packet arrives at the host server 222, it is immediately inspected by the BOOM server 220. According to one embodiment, the BOOM server 220 intercepts (28) all packets destined for the host server 222. According to an alternate embodiment, the SYN packet may be intercepted (28) if the BOOM server determines that the source IP address of the SYN packet is not associated with any of the BOOM client servers in the overlay network.
As shown in the example of FIG. 6A, after the BOOM server has intercepted the SYN packet, the BOOM server analyzes the packet and identifies (30) the source device (e.g. client 202) associated with the packet. In an alternate embodiment, the identification of the source device may take place while the packet is being inspected by the BOOM server (e.g. before interception). According to at least one embodiment, the source device may be identified by inspecting the tuple information included in the packet header. Once the source device has been identified, the BOOM server determines (32) or selects the appropriate BOOM client servers (BCSs) for receiving a forwarded copy of the SYN packet. A detailed description relating to the technique of how the BOOM server selects the appropriate clients is presented in a latter section of this application, entitled Scaling Issues.
Additionally, according to a specific embodiment, the BOOM server may also assign (32) a unique starting sequence number for each selected BOOM client server. As explained in greater detail below, the starting sequence number assigned by the BOOM server may be used by a BOOM client server when generating a response to the source device. Moreover, using the assigned sequence number data, the BOOM server is able to subsequently identify a successful BOOM client server (of the selected BOOM client servers) which generated a response that was received first at the source device.
Next, as shown at 34, the BOOM server encapsulates the intercepted SYN packet in accordance with an encapsulation tunneling protocol so that the encapsulated packet may be tunneled to the selected BOOM client servers of the overlay network. According to a specific embodiment, the encapsulated packet will include all information relating to the originally intercepted SYN packet.
After the BOOM server has encapsulated the intercepted SYN packet, the BOOM server replicates the encapsulated packet, and transmits (36 a, 36 b) the encapsulated packet (along with other desired information) to the selected BOOM client servers in the overlay network using an encapsulation tunneling protocol. An example of an encapsulated packet is shown in FIG. 3 of the drawings.
FIG. 3 shows a block diagram of a packet 300 which has been encapsulated in accordance with an encapsulation tunneling protocol. As shown in FIG. 3, the encapsulated packet which is transmitted by the BOOM server 220 to the BOOM client servers 206 comprises a header portion 302, and a payload portion 310. The header portion 302 typically includes tuple data such as, for example, a source IP address, a destination IP address, a source port number, and a destination port number. The payload portion 310 includes all information from the original SYN packet intercepted by the BOOM server 220. Additionally the payload portion 310 may also include additional data generated by the BOOM server such as, for example, starting sequence number data to be used by the receiving BOOM client server in responding to the SYN packet (described in greater detail below), and trigger data relating to a specific time value at which the BOOM client server receiving the encapsulated packet is to transmit a response to the client 202. The encapsulated packet 300 of FIG. 3 may be implemented in accordance with a variety of encapsulation tunneling protocols, such as, for example, GRE, IP/IP, LP2, etc. Additional information relating to packet encapsulation and tunneling protocols is described in RFC document number 2026, incorporated herein by reference in its entirety for all purposes.
For purposes of simplification and clarity, the example of FIGS. 6A and 6B illustrate the BOOM server 220 tunneling a replica of the encapsulated SYN packet to BOOM client server A (206 a) and BOOM client server B (206 b). However, it will be appreciated that a replica of the encapsulated packet may be tunneled or transmitted to any desired number of client servers in the overlay network. For example, as explained in greater detail below, the BOOM server 220 may forward a replica of the encapsulated SYN packet to 10 specific BOOM client servers, a portion of which have been selected based upon the identity of the client which sent the SYN packet.
When the encapsulated SYN packet is received at each of the selected BOOM client servers, each BOOM client server processes the encapsulated SYN packet, and generates (38 a, 38 b) a respective spoofed response to the SYN segment. However, unlike the procedure followed by the conventional TCP protocol, the BOOM client server sequence number associated with the spoofed response includes information for identifying the particular BOOM client server which generated the spoofed response.
For example, according to one embodiment, the BOOM client server sequence number (SEQ) of the spoofed SYN, ACK response corresponds to the IP address of the BOOM client server which generated the spoofed response. According to an alternate embodiment, the BOOM server 220 may assign each BOOM client server with a unique starting sequence number. The BOOM server 220 may then include the assigned starting sequence number data in the encapsulated packet(s) transmitted to each selected BOOM client server.
As shown in the example of FIG. 6A, BOOM client server A 206 a generates a spoofed SYN, ACK response which includes a sequence number SEQ=<BCS(A) ID>, where<BCS(A) ID>represents an identifier unique to BOOM client server A such as, for example, the IP address of BOOM client server A. Similarly, as shown in FIG. 6A, BOOM client server B generates a spoofed SYN, ACK response which includes a sequence number SEQ=<BCS(B) ID>, which uniquely identifies BOOM client server B. According the embodiment of FIG. 6A, each spoofed response generated by a particular BOOM client server is configured to appear as thought the response were actually generated by the host server 222.
The technique of spoofing is commonly known to those having ordinary skill in the art, and is described, for example, in U.S. Pat. Nos. 6,016,388, 5,892,903, and 6,006,266, each of which is herein incorporated by reference in its entirety for all purposes. Additional server spoofing techniques are described in currently pending U.S. patent application Ser. No. 08/946,867 for METHOD AND APPARATUS FOR FACILITATING NETWORK DATA TRANSMISSIONS. filed Oct. 8, 1997; and U.S. Provisional Patent Application No. 60/168,862 for METHOD AND APPARATUS FOR REDIRECTING NETWORK TRAFFIC, filed Dec. 2, 1999, each of which is incorporated herein by reference in its entirety for all purposes.
Each spoofed SYN, ACK response is generated using the original, intercepted SYN packet included in the encapsulated packet. One reason for encapsulating and tunneling the SYN packet to the selected BOOM client servers is to enable the original packet to be routed appropriately, and to provide each of the selected BOOM client servers with the exact, original SYN segment intercepted by the BOOM server. It will be appreciated that because each BOOM client server spoofs the host server, the spoofed response to the client system will pierce any intervening fire walls.
As shown in FIG. 6A, BOOM client server A and BOOM client server B each transmit (39 a, 39 b) their respective spoofed SYN, ACK responses to client system 202 at substantially the same time. In this way, each of the selected BOOM client servers participate in a race to be the first one to provide a response to client 202. Presumably, the topologically closest BOOM client server will have the shortest propagation delay to the client. However, due to network congestion or other factors, the topologically closest BOOM client server to the client 202 may not necessarily win the response race. Fortunately, in accordance with the technique of the present invention, if the topologically closest BOOM client server (of the selected plurality of BOOM client servers participating in the race) does not win the response race to the client system, it will typically be the case that the next topologically closest BOOM client server (of the selected plurality of BOOM client servers) will win the race.
In accordance with the technique of the present invention, a variety of different techniques may be used to ensure that all of the selected BOOM client servers transmit their respective responses to the client 202 at substantially the same time. These techniques are described in greater detail in a latter section of this application, entitled Timing Issues.
Referring to the network topology example of FIG. 2, it is assumed that BOOM client server B 206 b has the shortest propagation delay to client 202. Thus, given that each of the BOOM client servers 206 a, 206 b, 206 c transmits a respective SYN, ACK response at substantially the same time to client 202, it is assumed that the SYN, ACK response transmitted by BOOM client server B 206 b is the first spoofed response to be received at client 202.
When the first spoofed SYN, ACK response is received at client 202, the client opens (40) a client-side connection to the desired destination IP address (e.g., the IP address of the host server 222) using data from the first received SYN, ACK response. After receiving the SYN, ACK segment, the client generates (42) an ACK response to the first received SYN, ACK segment. The ACK response will include a client sequence number (SEQ=n+1), and an acknowledgment sequence number. In accordance with the standard TCP protocol, the acknowledgment sequence number generated by client 202 is equal to the value of the host sequence number (specified in the SYN, ACK response) incremented by 1. Thus, according the embodiment of FIG. 6A, the acknowledgment sequence number generated by the client 202 will be equal to the numeric value of the IP address of BOOM client server B, incremented by 1 (e.g., ACK=<BCS(B) ID>+1).
According to a specific embodiment, the host server may be included as one of the BOOM client servers for purposes of implementing the technique of the present invention. However, it will be appreciated that the host server does not generate a spoofed response. Alternatively, according to a different embodiment, it may be preferable to minimize the amount of traffic interacting with the host server. Thus, according to a specific implementation, access to the host service may be restricted to the BOOM client servers of the overlay network. Alternatively, according to yet another embodiment of the present invention, the BOOM server forwards an intercepted request to the host server only after a specified time has elapsed. According to this later embodiment, the BOOM server first waits to see whether any one of the selected BOOM client servers is able to respond to the requesting client within a specified time window. If the selected BOOM client servers are not able to respond to the requesting client device within the specified time window, the BOOM server may then forward the intercepted SYN packet to the host server.
At some point after the first SYN, ACK packet is received at client 202, the client will begin receiving duplicate SYN, ACK responses from the other selected BOOM client servers. For example, as shown in FIG. 6A, client 202 will receive a duplicate SYN, ACK response from BOOM client server A. As shown at 44, the client responds to the duplicate SYN, ACK responses by generating an acknowledgment (ACK) response using the acknowledgment sequence number corresponding the first received SYN, ACK response (from BOOM client server B).
Each ACK segment generated by the client 202 is transmitted (46) to the host server 222, where it is intercepted by BOOM server 220. When the BOOM server receives the first ACK from client 202, it processes (48) the ACK segment and identifies the successful BOOM client server (e.g., BOOM client server B) which won the race. According to a specific embodiment the BOOM server identifies the successful BCS by analyzing the acknowledgment (ACK) sequence number provided in the first received ACK segment from client 202. For example, according to a specific implementation, the the BOOM server subtracts 1 from the acknowledgement sequence number in order to obtain the unique identity of the successful BOOM client server. The BOOM server then associates (50) the client tuple (e.g., client IP address and port information located in the header of the received ACK packet) with the identified, successful BOOM client server. Thereafter, the BOOM server will forward all subsequent packets related to that TCP flow to the identified, successful BOOM client server (e.g., BOOM client server B).
As shown at 51, the BOOM server encapsulates the first received ACK segment in accordance with an encapsulation tunneling protocol. The encapsulated ACK packet is then transmitted (52 a) by the BOOM server to the identified, successful BOOM client server (BOOM client server B) using an encapsulation tunneling protocol. When the BOOM client server B server receives the tunneled ACK segment, it completes the three-way TCP hand shaking protocol by opening up a server side connection with the identified client.
Additionally, as shown in the embodiment of FIG. 6A, after the BOOM server has identified the successful BOOM client server which won the race, the BOOM server transmits (52 b) a TCP reset request to each of the other selected BOOM client servers which participated in the race to thereby cause each of these BOOM client servers to reset (53) their respective TCP state machines associated with that particular TCP flow. Thereafter, any duplicate ACK packets received at the BOOM server relating to that TCP flow may be ignored.
After the TCP hand-shaking protocol between the client and server has been completed, the client may then access data from the server such as, for example, by way of an HTTP request. This is illustrated in FIG. 6B of the drawings.
Referring to the example of FIG. 6B, it is assumed that client 202 desires to send an HTTP request to host server 222 (FIG. 2). It is to be noted that, at this point, the client is still unaware that it has actually been receiving responses from BOOM client server B, rather than the host server 222. Accordingly, at 54, the client transmits an HTTP request to the host server 222. The BOOM server intercepts (56) the HTTP request, and analyses the packet to identify (58) the client tuple information associated with the intercepted packet. Using the TCP handshaking information (e.g. ACK segment) provided by client 202, the BOOM server identifies (60) the successful BOOM client server (BOOM client server B) associated with the identified client tuple. The intercepted HTTP request packet is then encapsulated (62) and transmitted (64) by the BOOM server, using an encapsulation tunneling protocol, to the identified, successful BOOM client server (e.g. BOOM client server B). The successful BOOM client server, seeing that it is spoofing the host server, reads (66) the HTTP request, but does not respond with data. Rather, the successful BOOM client server issues (68) a spoofed HTTP redirect response (e.g., 302 HTTP redirect) to the client, wherein the redirect address corresponds to the IP address of the successful BOOM client server (e.g., BOOM client server B). The client receives and processes (70) the redirect response, and subsequently transmits (72) the previous HTTP request to the specified redirect address, which is the IP address of the successful BOOM client server. From this point forward, the client may communicate directly with the successful BOOM client server using TCP.
Timing Issues As described previously with respect to the example of FIG. 6A, it is important that all of the selected BOOM client servers which receive a replica of the encapsulated SYN packet (from BOOM server 220) transmit their respective spoofed responses to the identified source device (e.g., client 202) at substantially the same time. The example of FIG. 4 helps illustrate the importance of this concept.
FIG. 4 shows an example of a specific topological configuration of various devices in a data network. Like the example of FIG. 2, the BOOM server 420 of FIG. 4 tunnels encapsulated client packets (received from client 402) to client servers 406 a and 406 b. The client servers process the encapsulated client packet and generate spoofed responses which are then transmitted back to the client 402. The one-way propagation delay time values between the various devices of FIG. 4 are identified by reference numbers 401, 403, 405, and 407. Thus, for example, the one-way propagation delay value between BOOM server 420 and client server A 406 a is 900 milliseconds; the one-way propagation delay value between BOOM server 420 and client server B 406 b is 100 milliseconds; the one-way propagation delay between client server A 406 a and client 402 is 100 milliseconds; and the one-way propagation delay between client server B 406 b and client 402 is 800 milliseconds.
According to at least one embodiment of the present invention, with each new flow, the BOOM server conducts a race between each of the selected client servers in order to determine which of the selected client servers is the first to respond to a particular client. Preferably, the race begins when each of the client servers (e.g., 406 a, 406 b) transmits its respective spoofed response to client 402 at substantially the same time. The client server associated with the spoofed response which is first received at client 402 is the winner of the race, and is designated the successful client server. In the example of FIG. 4, assuming that client server A and client server B each transmit their responses at substantially the same time, client server A will be designated the successful client server. However, it will be appreciated that if the race were to start from BOOM server 420 (e.g. from the time when the BOOM server forwards the intercepted client packet to the selected client servers), then, according to the example of FIG. 4, client server B would win the race since the total propagation delay of paths 405 and 407 is less than the total propagation delay of paths 401 and 403. Accordingly, it is preferable that any propagation delays which exist between the BOOM Server 420 and the plurality of client servers (406 a, 406 b) be normalized or mitigated in order to assure that each of the client servers responds to the client 402 at substantially the same time.
According to the technique of the present invention, there are several techniques for causing all selected client servers to simultaneously respond to a client request forwarded from the BOOM server 420. According to a first embodiment, the BOOM server 420 may periodically send trace packets to each of the client servers in the overlay network in order to determine the respective one-way propagation delay value associated with communicating with each of the client servers. Thus, for example, referring to FIG. 4, the BOOM server may send trace packets to client server A 406 a and client server B 406 b in order to determine a roundtrip propagation delay value to each of these client servers. Using the roundtrip propagation delay values, the BOOM server is then able to compute the one-way propagation delay value associated with communicating with each respective client server. Thereafter, the BOOM server 420 may stagger the transmission time of each replica of the encapsulated packet (e.g., SYN packet) to thereby cause the encapsulated packets to be received at each of the selected client servers at substantially the same time (e.g. within 10 milliseconds of each other). Thus, for example, at time T=0 ms the BOOM server may transmit the a first replica of the encapsulated client packet to client server A, and at time T=800 ms the BOOM server may transmit a second replica of the encapsulated client packet to client server B, resulting in client server A and client server each receiving a replica of the encapsulated client packet at time T=900 milliseconds. At this point, the race begins for each client server to be the first one to successfully transmit a spoofed response to the encapsulated packet that is first received at client 402.
Alternatively, rather than staggering the transmission times at BOOM server 420, the BOOM server may include a respective trigger time value in each encapsulated packet specifying a precise time in which a particular client server is to transmit its spoofed response. For example, at time T=0 ms, the BOOM server may forward a first replica of the encapsulated packet to client server A, along with a trigger delay time value Td=0 ms, which indicates that the client server A may immediately respond to the forwarded packet once received. Additionally, on or about time T=0 ms, the BOOM server also forwards a second replica of the encapsulated client packet to client server B, along with a trigger delay time value Td=800 ms, which causes client server B to delay transmitting its spoofed response to the client packet until 800 milliseconds have elapsed after the encapsulated packet has been received. In this way, each of the client servers 406 a and 406 b will transmit the respective spoofed responses to client machine 402 at or about time T=900 milliseconds.
According to an alternate embodiment of the present invention, the BOOM server and each of the client servers in the overlay network are all synchronized to a common time reference. For example, according to a specific implementation, additional hardware and/or software is provided for synchronizing the BOOM server and each of the respective BOOM client servers which allows each server to be synchronized to a common time reference associated, for example, with a global positioning satellite (GPS) system. In this example each of the servers in the overlay network may be configured to support a network time protocol (NTP), which is commonly known to one having ordinary skill in the art. A respective hardware device may additionally be installed at each server location which allows a server to receive Stratum 1 resolution time data using the NTP protocol. This is shown for example in FIG. 5 in the drawings.
FIG. 5 shows a block diagram illustrating how synchronization may be achieved between each of the servers in the overlay network of the present invention. A separate time server 554 may be connected to each server or device in the overlay network. The time server receives precise clock data (e.g., Stratum 1 resolution) from an orbiting satellite 552 which is part of a global satellite positioning system. The time server 554 converts a received time reference data into an NTP format which is then transmitted to the associated BOOM server or BOOM client server 556. According to a specific implementation time server device 554 may be implemented using a time server device manufactured by True Time, Inc., of Santa Rosa, Calif.
Assuming that synchronization has been achieved between each of the servers in the overlay network, the BOOM server 220 (FIG. 2) may then transmit, to selected BOOM client servers, encapsulated packets which include trigger information relating to a specific time at which each of the selected BOOM client servers is to transmit its response to the client 202. Thus, for example, referring to FIG. 4, during the time interval between time T=0 and T=10 milliseconds, the BOOM server may transmit encapsulated, tunneled packets to client server A and client server B. Each encapsulated packet will include information relating to the intercepted SYN packet, and additional information specifying, for example, the respective starting sequence number (SEQ) to be used by each BOOM client server, and a trigger time value of TT=1,000 ms. It is preferable that the specific trigger time value selected by the BOOM server be sufficiently far in advance to allow time for each of the selected client servers to receive the encapsulated packet and generate a spoofed response to the SYN packet. Thereafter, at the specified trigger time (e.g. T=1000 ms), the race begins, and each of the selected client servers transmits its spoofed response to client 402.
Scaling Issues As described previously, when the BOOM server intercepts a client packet, it forwards the intercepted packet to a selected portion of the client servers in the overlay network using a multicast technique. Thus, it will be appreciated that for every packet the BOOM server intercepts, it may forward the intercepted packet to N client servers in the overlay network. However, while the technique of the present invention works very well where N is relatively small (e.g., N<100), scaling problems may arise in situations where N is relatively large (e.g. N>10,000). For example, referring to FIG. 2, if the overlay network includes 10,000 BOOM client servers, and the BOOM server 220 forwards a copy of an intercepted SYN packet to each BOOM client server in the overlay network, the client 202 (which issued the SYN packet) may be bombarded with as many as 10,000 responses. This, in turn, may result in network congestion and/or failure at the client. While it may seem desirable to limit the size of N to a relatively small value, it will also be appreciated that, by increasing the size of N, there is an increased chance of selecting the optimal client server in the overlay network for servicing a particular client.
Accordingly, one problem to solve relates to determining an optimal value for N. Additionally a second problem to solve relates to determining which particular client servers should be included within the N client servers selected to respond to the intercepted packet. The optimal solution to these problems may require searching an enormous solution space. Moreover, as the number of BOOM client servers and/or clients increases, the solution space becomes exponentially larger. Even worse, since the Internet is a dynamic entity, the solutions may change in response to dynamic changes in the Internet topology such that a previously optimal solution may become a undesirable solution.
FIG. 7 shows a flow diagram of an BCS Response Scaling Procedure 700 in accordance with a specific embodiment of the present invention. The BCS Response Scaling Procedure 700 of FIG. 7 illustrates a specific embodiment of how the above-described scaling problems may be resolved in accordance with the technique of the present invention.
At 702, a client packet is intercepted by the BOOM server. The intercepted packet will typically be implemented using a specific protocol such as, for example, TCP, DNS, UDP, etc., and will also include information identifying the source device which sent the intercepted packet. For example, the intercepted packet may be a SYN packet generated by client 202 (FIG. 2). After intercepting the packet, the BOOM server analyzes the packet information to identify (704) the source device which issued the packet. In this example, the BOOM server would identify the source device as client 202. At 706, the BOOM server recalls all current optimal BOOM client server(s), if any, for the identified source device (e.g., client 202). According to at least one embodiment, an optimal BOOM client server corresponds to a successful BOOM client server which has recently won at least one response race to the identified source device. According to a specific implementation, the BOOM server maintains a record of the three most recent BOOM client servers which have succeeded in winning the response race to the identified source device. It will be appreciated, however, that the number of optimal BOOM client servers (BCSs) associated with a specific source device may vary, depending upon design preferences.
Once the BOOM server has identified a pre-determined number m (e.g., m=3) of optimal BCSs associated with the identified source device, the BOOM server forwards (708) an encapsulated copy of the intercepted packet to the m optimal BCSs, and additionally forwards replicas of the encapsulated packet to n random BCSs. According to a specific implementation, the BOOM server will forward an separate encapsulated copy of the intercepted packet to seven randomly selected BOOM client servers within the overlay network (not including the m optimal BOOM client servers). However, it will be appreciated that the number n may be adjusted as desired, depending upon design specifications.
After copies of the encapsulated packet have been forwarded to the selected BOOM client servers, a particular one of the selected BOOM client servers will be identified as the successful BCS which won the race in responding the identified source device. For example, as described in FIG. 6A of the drawings, the BOOM server determines the successful BOOM client server using the acknowledgement sequence number from the ACK segment sent by client 202. Thus, as shown at 710, the BOOM server identifies the successful BCS which won the race in responding to the identified source device.
After the BOOM server has identified the successful BCS, it determines (712) whether the successful BCS is already identified as an optimal BCS for the identified source device. If the successful BCS is already identified as an optimal BCS for the identified source device, no change is made to list of optimal BCSs associated with the identified source device. However, if the successful BCS is not identified as an optimal BCS for the identified source device, at 714, the BOOM server includes the successful BCS in the list of optimal BCSs associated with the identified source device. Additionally, according to a specific embodiment, when a new successful BCS is added to the list of optimal BCSs associated with a particular source device, a lowest ranking BCS from the optimal BCSs list is displaced. In one embodiment, the lowest ranking optimal BCS may be defined as the least recent optimal BCS to have won the response race to the identified source device.
Thus, according to at least one embodiment, the BCS Response Scaling Procedure 700 may be adapted to account for successful BCSs that die or suffer from network congestion by maintaining an �optimal BCS� list of the n most recent successful BCSs (e.g., n=3) for each identified source device in the data network. Additionally, the successful BCSs associated with a particular optimal BCS list may be sorted according to each BCS's most recent success, so that their status corresponds to a natural decay. Further, after the procedure 700 reaches a steady state for a particular source device (e.g., when there are no changes made to the optimal BCS list associated with a particular identified source device after a pre-determined number of cycles), the total number of BOOM client servers selected by the BOOM server to respond to an intercepted packet associated with the identified source device may be reduced (e.g., from a total of 10 forwarded packets to a total of 5 forwarded packets).
It will be appreciated that the BCS Response Scaling Procedure 700 of FIG. 7 may require a substantial amount of memory resources for implementation. For example, each possible source device in the data network may have associated with it 10 IP addresses and a plurality of data structure pointers. Additionally, because the procedure is continuously learning and improving, it may be preferable to occasionally save current results to a stable storage.
Moreover, the technique of the present invention for routing network traffic provides a number of other advantages over map-based algorithms, such as, for example, the above-described Akamai technique. For example, one advantage of the technique of the present invention is that it may be implemented using normal Internet routing protocols, and does not require the building or maintaining of a network map. Additionally, the technique of the present invention is able to provide more accurate results than conventional map-based techniques since routing decisions using the technique of the present invention are based upon current network conditions. In contrast, map-based routing techniques base their routing decisions on potentially outdated map information which may be minutes or hours old, depending upon the frequency and correctness of the map updates. Further, the technique of the present invention may be easily implemented and configured in an existing network. The technique of the present invention is also more scalable than map-based routing techniques. Additionally, the technique of the present invention offers flexibility in that it may be easily set up both locally (e.g. on an ISP network) and globally (e.g. on the Internet). Further, unlike conventional routing techniques such as Akamai, the technique of the present invention does not require modification of the original content of the host server and/or client servers of the overlay network.
Other Embodiments Generally, the technique of the present invention may be implemented on software and/or hardware. For example, it can be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, or on a network interface card. In a specific embodiment of this invention, the technique of the present invention is implemented in software such as an operating system or in an application running on an operating system.
A software or software/hardware hybrid implementation of the BOOM server and BOOM client servers of this invention may be implemented on a general-purpose programmable machine selectively activated or reconfigured by a computer program stored in memory. Such programmable machine may be a network device designed to handle network traffic. Such network devices typically have multiple network interfaces including frame relay and ISDN interfaces, for example. Specific examples of such network devices include routers and switches. For example, the BOOM server and BOOM client server devices of this invention may be specially configured routers or servers such as specially configured router models 1600, 25001 2600, 3600, 4500, 4700, 7200, 7500, and 12000 available from Cisco Systems, Inc. of San Jose, Calif. A general architecture for some of these machines will appear from the description given below. In an alternative embodiment, the BOOM server and BOOM client server devices may be implemented on a general-purpose network host machine such as a personal computer or workstation. Further, the invention may be at least partially implemented on a card (e.g., an interface card) for a network device or a general-purpose computing device.
Referring now to FIG. 8, a network device 60 suitable for implementing the BOOM server or BOOM client server devices of the present invention includes a master central processing unit (CPU) 62, interfaces 68, and a bus 67 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU 62 may be responsible for implementing specific functions associated with a particular device of the present invention. For example, when configured as a BOOM server, the CPU 62 may be responsible for intercepting and analyzing packets, encapsulating packets, forwarding packets to appropriate BOOM client servers, etc. When configured as a BOOM client server, the CPU 62 may be responsible for generating an appropriate spoofed response to an encapsulated packet received from the BOOM server. The CPU 62 preferably accomplishes all these functions under the control of software including an operating system (e.g. Windows NT), and any appropriate applications software.
Although the system shown in FIG. 8 is one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. Further, other types of interfaces and media could also be used with the network device.
Patentzitate Zitiertes PatentEingetragen Ver�ffentlichungsdatum Antragsteller TitelUS482741115. Juni 19872. Mai 1989International Business Machines CorporationMethod of maintaining a topology databaseUS496577215. Juni 198723. Okt. 1990International Business Machines CorporationMethod and apparatus for communication network alert message constructionUS54147045. Apr. 19949. Mai 1995Digital Equipment CorporationAddress lookup in packet data communications link, using hashing and content-addressable memoryUS545244721. Dez. 199219. Sept. 1995Sun Microsystems, Inc.Method and apparatus for a caching file serverUS548841231. M�rz 199430. Jan. 1996At&T Corp.Customer premises equipment receives high-speed downstream data over a cable television system and transmits lower speed upstream signaling on a separate channelUS550698724. M�rz 19949. Apr. 1996Digital Equipment CorporationAffinity scheduling of processes on symmetric multiprocessing systemsUS551120823. M�rz 199323. Apr. 1996International Business Machines CorporationLocating resources in computer networks having cache server nodesUS555524430. Juni 199410. Sept. 1996Integrated Network CorporationScalable multimedia networkUS558612121. Apr. 199517. Dez. 1996Hybrid Networks, Inc.Asymmetric hybrid access system and methodUS56110493. Juni 199211. M�rz 1997Pitts; William M.System for accessing distributed data cache channel at each network node to pass requests and dataUS567326529. Apr. 199630. Sept. 1997Integrated Network CorporationScalable multimedia networkUS575197112. Juli 199512. Mai 1998Cabletron Systems, Inc.Internet protocol (IP) work group routingUS57746605. Aug. 199630. Juni 1998Resonate, Inc.World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node networkUS578747018. Okt. 199628. Juli 1998At&T CorpInter-cache protocol for improved WEB performanceUS581884518. Jan. 19966. Okt. 1998Hybrid Networks, Inc.Hybrid access system having channel allocation and prioritized polling schemesUS582865521. Aug. 199627. Okt. 1998Hybrid Networks, Inc.Hybrid access system with quality-based channel switchingUS58482419. Jan. 19978. Dez. 1998Openframe Corporation Ltd.Resource sharing facility functions as a controller for secondary storage device and is accessible to all computers via inter system linksUS585271720. Nov. 199622. Dez. 1998Shiva CorporationPerformance optimizations for computer networks utilizing HTTPUS585985227. Aug. 199612. Jan. 1999Hybrid Networks, Inc.Hybrid access system with automated client-side configurationUS587277317. Mai 199616. Febr. 1999Lucent Technologies Inc.Virtual trees routing protocol for an ATM-based mobile networkUS589290312. Sept. 19966. Apr. 1999Internet Security Systems, Inc.Method and apparatus for detecting and identifying security vulnerabilities in an open network computer communication systemUS594604712. M�rz 199731. Aug. 1999Hybrid Networks, Inc.Network system for handling digital data over a TV channelUS594604812. M�rz 199731. Aug. 1999Hybrid Networks, Inc.Network device for handling digital data over a TV channelUS595020525. Sept. 19977. Sept. 1999Cisco Technology, Inc.Data transmission over the internet using a cache memory file systemUS595333518. Dez. 199714. Sept. 1999Advanced Micro Devices, Inc.Method and apparatus for selectively discarding packets for blocked output queues in the network switchUS595634622. Okt. 199621. Sept. 1999Hybrid Networks, Inc.Broadband communication system using TV channel roll-off spectrumUS595966026. Aug. 199628. Sept. 1999Hybrid Networks, Inc.Subchannelization scheme for use in a broadband communications systemUS595996830. Juli 199728. Sept. 1999Cisco Systems, Inc.Port aggregation protocolUS595999721. Aug. 199628. Sept. 1999Hybrid Networks, Inc.Hybrid access system with AGC control of upstream channel transmit powerUS598906025. Aug. 199723. Nov. 1999Cisco TechnologySystem and method for direct communication with a backup network device via a failover cableUS600626430. M�rz 199821. Dez. 1999Arrowpoint Communications, Inc.Method and system for directing a flow between a client and a serverUS600626621. Jan. 199721. Dez. 1999International Business Machines CorporationMultiplexing of clients and applications among multiple serversUS60163886. Mai 199818. Jan. 2000Hughes Electronics CorporationMethod and apparatus for requesting and retrieving information from a source computer using terrestrial and satellite interfacesUS60527187. Jan. 199718. Apr. 2000Sightpath, IncReplica routingUS60921783. Sept. 199818. Juli 2000Sun Microsystems, Inc.System for responding to a resource requestUS613112125. Sept. 199610. Okt. 2000Netspeak CorporationPoint-to-point computer network communication utility utilizing dynamically assigned network protocol addressesUS616743822. Mai 199726. Dez. 2000Trustees Of Boston UniversityMethod and system for distributed caching, prefetching and replicationUS61674463. Nov. 199826. Dez. 2000Inca Technology, Inc.Automatically configuring network-name-servicesUS618213923. Juni 199830. Jan. 2001Resonate Inc.Client-side resource-based load-balancing with delayed-resource-binding using TCP state migration to WWW server farmUS623019612. Nov. 19978. Mai 2001International Business Machines CorporationGeneration of smart HTML anchors in dynamic web page creationUS634529419. Apr. 19995. Febr. 2002Cisco Technology, Inc.Methods and apparatus for remote configuration of an appliance on a networkUS638946216. Dez. 199814. Mai 2002Lucent Technologies Inc.Method and apparatus for transparently directing requests for web objects to proxy cachesUS646347518. Jan. 20008. Okt. 20023Com CorporationMethod and device for tunnel switchingUS647752210. Juni 19995. Nov. 2002Gateway, Inc.Dynamic performance based server selectionUSRE3577416. Nov. 199421. Apr. 1998Hybrid Networks, Inc.Remote link adapter for use in TV broadcast data transmission systemWO1998031107A230. Dez. 199716. Juli 1998Gifford, David, K.Replica routingNichtpatentzitateReferenz1Aviani, Jr. et al., Wide Area Load Balancing Of Web Traffic, Filed Jun. 28, 2000, Application No. 09/606,418.2Cieslak et al., Network Cache-Based Content Routing, Filed Jun. 5, 2000, Application No. 09/588,027.3David M. Gifford, "Replica Routing," U.S. patent application No. 09/472,964, Filed Dec. 28, 1999, 37 pages.4Eager et al., "Adaptive Load Sharing in Homogeneous Distrubuted Systems," IEEE, Transactions on Software Engineering, vol. Se-12, No. 5, May 1986, PP 662-675.5Gourlay et al., Path Selection System, Filed: Dec. 19, 2001, Application No.: 10/034,368.6Gourlay et al., Phased Learning Approach To Determining Closest Content Serving Sites, Filed Aug. 31, 2000, Application No. 09/652,766.7Information Sciences Institute, Request for Comments No. 793, entitled, "Transmission Control Protocol-DARPA Internet Program-Protocol Specification," Sep., 1981, Internet Engineering Task Force, 49 pages.8Information Sciences Institute, Request for Comments No. 793, entitled, "Transmission Control Protocol�DARPA Internet Program�Protocol Specification," Sep., 1981, Internet Engineering Task Force, 49 pages.9Johnson et al., "Dynamic Server Organization," U.S. patent application No. 09/294,837, Filed Apr. 19, 1999, 42 Pages.10Johnson et al., "Method and Apparatus for Determining a Network Topology in the Presence of Network Address Translation," U.S. Provisional patent application No.: 60/178,062, Filed Jan. 24, 2000, 32 Pages.11Kirk Johnson, "A Method and Apparatus for Minimalist Approach to Implementing Server Selection," U.S. Provisional patent application No.: 60/177,415, Filed Jan. 21, 2000, 39 Pages.12Lu et al., "Automatic Network Addresses Assignment and Translation Interference," U.S. Provisional patent application No.: 60/160,535, Filed Oct. 20, 1999, 127 Pages.13Lu et al., "Method and Apparatus for Automatic Network Address Assignment," U.S. Provisional patent application No.: 60/178,063, Filed Jan. 24, 2000, 74 Pages.14Martin Arlitt, Ludmila Cherkasova, John Dilley, Rich Friedrich And Tai Jin, OF Hewlett-Packard Laboratories, "Evaluating Content Management Techniques For Web Proxy Caches," Apr. 30, 1999, 9 pages.15Meyer, et al., Request for Comments No. 2026, entitled , "Generic Routing Encapsulation (GRE)," Jan., 2000, Internet Engineering Task Force, 9 pages.16Meyer, et al., Request For Comments No. 2026, entitled, "Generic Routing Encapsulation (GRE)," Jan., 2000, Internet Engineering Task Force, 9 pages.17Mockapetris, P., Request For Comments No. 1034, entitled, "Domain Names-Concepts and Facilities," Nov., 1987, Internet Engineering Task Force, 31 pages.18Mockapetris, P., Request For Comments No. 1034, entitled, "Domain Names�Concepts and Facilities," Nov., 1987, Internet Engineering Task Force, 31 pages.19Ousterhout, John K., "A Trace-Driven Analysis of the UNIX 4.2 BSD File System," Jan. 2, 1993, Computer Science Division, Electrical Engineering and Computer Science, University of California, Berkeley, CA, pp. 1-12.20Ousterhout, John K., "Beating the I/O Bottleneck: A Case for Log-Structured File Systems," Jan. 30, 1992, Computer Science Division, Electrical Engineering anc Computer Sciences, University of California, Berkeley, CA, pp. 1-17.21U.S. patent application Ser. No. 08/779,770, Gifford, filed Jan. 7, 1997.22U.S. patent application Ser. No. 09/294,836, O'Toole et al., filed Apr. 19, 1999.23U.S. patent application Ser. No. 09/294,837, Johnson et al., filed Apr. 19, 1999.24U.S. patent application Ser. No. 09/472,964, Gifford, filed Dec. 28, 1999.25U.S. patent application Ser. No. 60/160,535, Lu et al., Oct. 20, 1999.26U.S. patent application Ser. No. 60/177,415, Johnson, Jan. 21, 2000.27U.S. patent application Ser. No. 60/177,985, O'Toole, Jan. 25, 2000.28U.S. patent application Ser. No. 60/178,062, Johnson et al., filed Jan. 24, 2000.29U.S. patent application Ser. No. 60/178,063, Lu et al., Jan. 24, 2000.30Valloppillil, Vinod, "Cache Array Routing Protocol v1.0", Oct. 20, 1997, Internet-Draft, http://ds1.internic/net/internet-drafts/draft-vinod-carp-v1-02.txt, pp. 1-6.31Welch, Brent, "A Comparison of the Vnode and Sprite File System Architectures," Proceedings of the File System Workshop, May 1992, pp. 29-44. Referenziert von Zitiert von PatentEingetragen Ver�ffentlichungsdatum Antragsteller TitelUS687703925. Apr. 20015. Apr. 2005Fujitsu LimitedSimplified pipeline writes over a networkUS695468018. Jan. 200211. Okt. 2005Siemens AktiengesellschaftMethod and system for the electronic provision of services for machines via a data communication linkUS698102917. Juli 200127. Dez. 2005Cisco Technology, Inc.System and method for processing a request for information in a networkUS70580584. Nov. 20046. Juni 2006Juniper Networks, Inc.Transparent optimization for transmission control protocol initial session establishmentUS708931220. Sept. 20018. Aug. 2006Intel CorporationSystem and method for reducing retransmissions due to tunneled TCP-in-TCP communication in a networkUS712417330. Apr. 200117. Okt. 2006Huawei Technologies Co., Ltd.Method and apparatus for intercepting performance metric packets for improved security and intrusion detectionUS712732217. Aug. 200524. Okt. 2006Siemens AktiengesellschaftMethod and system for the electronic provision of services for machines via a data communication linkUS71585227. M�rz 20062. Jan. 2007Juniper Networks, Inc.Transparent optimization for session establishment using characterized synchronization packetUS717794327. Dez. 200113. Febr. 2007Cisco Technology, Inc.System and method for processing packets in a multi-processor environmentUS723145827. Dez. 200112. Juni 2007Nortel Networks LimitedMethod and apparatus for discovering client proximity using race type translationsUS731363521. M�rz 200225. Dez. 2007Cisco TechnologyMethod and apparatus for simulating a load on an application server in a networkUS739512212. Sept. 20011. Juli 2008Siemens AktiengesellschaftData capture for electronically delivered automation servicesUS73953485. Juni 20001. Juli 2008Cisco Technology, Inc.Network cache-based content routingUS740115920. Mai 200415. Juli 2008Cisco Technology, Inc.Distributed network traffic load balancing technique implemented without gateway routerUS748337424. Okt. 200327. Jan. 2009Scalent Systems, Inc.Method and apparatus for achieving dynamic capacity and high availability in multi-stage data networks using adaptive flow-based routingUS75028368. Nov. 200510. M�rz 2009Cisco Technology, Inc.System and method for processing a request for information in a networkUS751268816. Aug. 200231. M�rz 2009Hitachi, Ltd.PPPoE network system that can distribute connection requests from PPPoE client terminals to specific PPPoE serversUS75292462. Jan. 20075. Mai 2009Juniper Networks, Inc.Transparent optimization for session establishment using characterized synchronization packetUS757775312. Febr. 200718. Aug. 2009Cisco Technology, Inc.System and method for processing packets in a multi-processor environmentUS761727420. Juli 200410. Nov. 2009Intel CorporationMethod and system for selecting a host in a communications networkUS768971012. Juni 200130. M�rz 2010Hewlett-Packard Development Company, L.P.Method and system for a front-end modular transmission control protocol (TCP) handoff design in a streams based transmission control protocol/internet protocol (TCP/IP) implementationUS768971823. Okt. 200730. M�rz 2010International Business Machines CorporationChannel subsystem server time protocol commands and system thereforUS772467019. Dez. 200825. Mai 2010Scalent Systems, Inc.Method and apparatus for achieving dynamic capacity and high availability in multi-stage data networks using adaptive flow-based routingUS77247462. Aug. 200625. Mai 2010Cisco Technology, Inc.Method and system for providing load balanced traffic in redundant infiniband ethernet gateways networkUS772559814. Apr. 200825. Mai 2010Cisco Technology, Inc.Network cache-based content routingUS777910922. Okt. 200717. Aug. 2010International Business Machines CorporationFacilitating synchronization of servers in a coordinated timing networkUS778373622. Okt. 200724. Aug. 2010International Business Machines CorporationDefinition of an active stratum-1 server in a coordinated timing networkUS778391322. Okt. 200724. Aug. 2010International Business Machines CorporationFacilitating recovery in a coordinated timing networkUS779741422. Okt. 200714. Sept. 2010International Business Machines CorporationEstablishing a logical path between servers in a coordinated timing networkUS783173112. Juni 20019. Nov. 2010Hewlett-Packard Development Company, L.P.Method and system for a modular transmission control protocol (TCP) rare-handoff design in a streams based transmission control protocol/internet protocol (TCP/IP) implementationUS787386221. Okt. 200818. Jan. 2011International Business Machines CorporationMaintaining a primary time server as the current time server in response to failure of time code receivers of the primary time serverUS789530315. Nov. 200722. Febr. 2011International Business Machines CorporationServer time protocol control messages and methodsUS789989430. Aug. 20061. M�rz 2011International Business Machines CorporationCoordinated timing network configuration parameter update procedureUS792569326. Jan. 200712. Apr. 2011Microsoft CorporationNAT access control with IPSecUS792591610. Apr. 200812. Apr. 2011International Business Machines CorporationFailsafe recovery facility in a coordinated timing networkUS794066515. Juli 200910. Mai 2011Juniper Networks, Inc.Transparent optimization for transmission control protocol flow controlUS795838414. Aug. 20097. Juni 2011International Business Machines CorporationBackup power source used in indicating that server may leave networkUS797859816. Apr. 200212. Juli 2011Cisco Technology, Inc.Connection replicationUS800122518. Mai 201016. Aug. 2011International Business Machines CorporationServer time protocol messages and methodsUS81407042. Juli 200820. M�rz 2012International Busniess Machines CorporationPacing network traffic among a plurality of compute nodes connected using a data communications networkUS821945131. Aug. 200910. Juli 2012Siemens AktiengesellschaftSystem and method for electronic delivery of content for industrial automation systemsWO2005003883A21. Juli 200413. Jan. 2005Adwise Ltd.Devices and methods for expediting requests in a computerized network by interceptionWO2008092777A222. Jan. 20087. Aug. 2008Carlson, ScottMethod and system for establishing a logical path between servers in a coordinated timing networkDrehenOriginalbildGoogle-Startseite - Sitemap - USPTO-Bulk-Downloads - Datenschutzerkl�rung - Nutzungsbedingungen - �ber Google Patente - Feedback gebenDaten bereitgestellt von IFI CLAIMS Patent Services.© 2012 Google