Technique for Handling Initiation Requests

Abstract

A technique is described for handling initiation requests directed to a contact host from a plurality of clients that enables the handling of large number of requests and provides design stage flexibility. A contact host receives the requests from the clients. Thereafter, an acknowledgment is sent to each requesting client so that direct data transfer may commence between the client and server bypassing the contact host. This acknowledgment may be generated and sent by either the contact host or by the associated server In some variations, each request is authenticated prior to the association of each request.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

Further details, embodiments, modifications and enhancements of the present invention may be obtained from consideration of the following description of various illustrative embodiments of the invention in conjunction with the drawings, in which:

FIG. 1 is a signaling diagram illustrating a conventional technique for exchanging initiation requests and acknowledgments between a client and a server;

FIG. 2 is a process flow diagram illustrating a method embodiment of the current invention;

FIG. 3 is a schematic diagram illustrating an apparatus embodiment of the current invention;

FIG. 4 is a schematic diagram of an example useful for understanding and the implementing the invention illustrating a client sending an initiation request to a contact host which subsequently forwards the request to a server which in turn sends an acknowledgement of the request to the client;

FIG. 5 is a schematic diagram of an example useful for understanding and the implementing the invention illustrating a client sending an initiation request to a contact host which sends an acknowledgement of the request identifying the server to the client;

FIG. 6 is a signaling diagram of an example useful for understanding and the implementing the invention illustrating a client sending an initiation request to a contact host which subsequently forwards the request to a server which in turn sends an acknowledgement of the request to the client so that data transfer may be commenced between the server and client bypassing the contact host; and

FIG. 7 is a signaling diagram of an example useful for understanding and the implementing the invention illustrating a client sending an initiation request to a contact host which in turn sends an acknowledgement of the request to the client identifying the server so that data transfer may be commenced between the server and client bypassing the contact host.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular sequences of steps and various configurations, etc. in order to provide a thorough understanding of the present invention. It will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. Moreover, those skilled in the art will appreciate that the functions explained herein below may be implemented using software functioning in conjunction with a programmed microprocessor or general purpose computer, and/or using an application specific integrated circuit (ASIC). It will also be appreciated that while the current invention is primarily described as a method, it may also be embodied in a computer program product or in a system comprising a computer processor and a memory coupled to the processor, the memory being encoded with one or more programs that may perform the methods disclosed herein. Furthermore, while the current invention may be described in relation to SCTP, the skilled artisan will appreciate that it may be utilized in connection with a variety of data transfer protocols and applications in which initiation requests are sent by clients prior to association between a client and a server.

With reference to FIG. 2, a process flow diagram 200 is illustrated relating to a method for handling initiation requests that are directed to a contact host from a plurality of clients. The method commences, at step 210, with the (server) contact host receiving the requests. After the requests have been received, at step 220, the contact host associates each request with a server. Thereafter, at step 230, an acknowledgment of the receipt of each request is sent to the requesting client so that data transfer may subsequently commence directly between the client and the associated server. Optionally, the contact host may also authenticate each request (and/or client sending request) to provide, inter alia, further protection against a DoS attack.

FIG. 3 illustrates a contact host 300 that is configured to handle initiation requests received from a plurality of clients. A receiving unit 310 receives the requests from the various clients. An association unit 320 associates each received request with a server, and an acknowledgment unit 330 initiates an acknowledgment to the requesting clients (either directly by the contact host or by the associated server). Optionally, the contact host 300 may further include an authentication unit 320 that authenticates each client sending a request (to, inter alia, further insulate the servers from a DoS attack). Variations to the embodiments of the current invention illustrated in FIGS. 2 and 3 as well as examples useful for understanding and implementing the current invention are discussed below and illustrated in FIGS. 4-7.

A schematic diagram 400 is illustrated in FIG. 4 that illustrates the relationship between a (server) contact host 410, a client 420, and at least one server 430 (or at least one cluster of servers), all of which are coupled via a network, such as an IP network 440. The client 420 may send an initiation request 450 (e.g., an INIT message in the case of SCTP) to the contact host 410 via the IP network 440. The contact host 410 may then authenticate the request (by, for example, determining whether the client 420 is allowed to communicate with the server 430). If the client 420 (and/or request 450) has not been authenticated, the contact host 410 may reply to the client 420 with an ABORT message (in the case of SCTP) or other termination message.

If the client 420 is authenticated (or if the contact host 410 is not configured to authenticate the client 420 and/or the request 450), the contact host 410 selects an appropriate server 430 to respond to and process the request 450. Once the server 430 has been selected, the contact host 410 forwards or otherwise relays the request 460 (or generates a new request having the required information) via the IP network 440 to the selected server 430 (which may require the exchange of several messages between the contact host 410 and the server 430 such as INIT and INIT ACK, etc. depending on the protocol). The server 430 may be selected based on a determination of how to balance/share the load among the various servers that are associated or otherwise coupled to the contact host 410 (e.g., based on performance statistics provided by each of the servers or by a load monitor that is coupled to the servers), or alternatively, the server 430 may be selected using a mechanism such as a round robin selection scheme. Alternatively, the server 430 may forward initiation messages to other members of a same cluster of servers until a suitable candidate among the various servers is identified.

The contact host 410, in order to ensure that the client 420 and the server 430 are associated (so that data may be transferred), may send an address configuration change message (ASCONF message in the case of SCTP) to the client 420 specifying the server 430 as the proper recipient of future messages. If an acknowledgment of the address configuration message (e.g., ASOCNF ACK in the case of SCTP, etc.) is received by the contact host 410, then the contact host 410 may then delete all state information related to the association. On the other hand, if the client 420 replies with an error message (e.g., ERROR in the case of SCTP) indicating an unrecognized chunk type, then the contact host 410 may silently discard incoming data messages and HEARTBEAT messages for the association. Thereafter, the client 420 may ultimately determine that the contact host 410 is inactive and will perform a fail-over to one of the other addresses belonging to the server 430.

The server 430, may send an acknowledgment 470 (e.g., INIT ACK message, etc.) in response to the request 450 via the IP network 440, so that an association 480 (e.g., a SCTP association, etc.) may be established between the server 430 and the client 420 (to facilitate, for example, data transfer between the server 430 and the client 420). Depending on the implementation, further hand-shaking signals may be exchanged between the server 430 and the client 420 prior to the commencement of the association. Furthermore, with this arrangement, any further messages related to the original request 450 received by the contact host 410 from the client 420, such as other initialization messages (e.g., COOKIE ECHO messages as described in RFC 2960, etc.) may be routed directly to the server 430 (so that the server 430 may directly respond thereto).

The acknowledgment 470 and/or other initialization messages by the server 430 to the client 420 includes a server address identifying the location where the server 430 will subsequently be contacted. The server address may be the “semi-permanently” assigned address belonging to the server 430, or it may be a dynamically assigned address. For example, the server 430 may dynamically assign addresses to some (or all) of its interfaces. This assignment may be generated through a technique such as Dynamic Host Configuration Protocol (DHCP), stateless/stateful automatic configuration, network address translation (NAT) or network address port translation (NAPT) or the like. With dynamic assignment, each association may be provided with its own real (IP address assigned to the server interfaces via DHCP) or virtual (address mapping via NAT) end point on the server 430.

FIG. 5 illustrates a schematic diagram 500 (where common signals and components of FIG. 4 are shown using the same reference numbers), where a client 410 sends a request to a contact host 430 and the contact host sends an acknowledgment 510 (e.g., INIT message, etc.) to the client. Thereafter, a server 420 and a client 410 establish an association 480. With this variation, the contact host 430 may perform the various steps relating to the initialization of the association 480 such as selecting the proper server 420 (which may include further signaling relating to the exchange of state information), preparing the state in the selected server 420 for a data transfer phase, and forcing the data transfer phase to be processed by the selected server 420 (e.g., by maintaining state information on the association and not answering to various chunks to act as a dead interface in order to force multi-homing in the client 410 to redirect traffic to the remaining addresses residing on the server 420). In contrast with the example of FIG. 4, the contact host 430 may optionally directly respond to various initialization messages (e.g., COOKIE ECHO messages, etc.) received from the client 410. Alternatively, the contact host 430 may simply discard messages other than initiation requests (e.g., DATA messages, HEARTBEAT messages, etc.), so that the contact host 430 is declared as unreachable by the client 410.

FIG. 6 illustrates an SCTP-based signaling diagram 600 among a client 610 (end point EP A) having associated IP addresses {IP A1, . . . , IP An} and a port P A, a contact host 620 (end point EP C) having associated IP addresses {IP C1, . . . , IP Co} and a port P Z, and a server 630 (end point EP Z) having associated IP addresses {IP Z1, . . . , IP Zm} and a port P Z. The client 610 may send an initiation request 640 to the contact host 620. This initiation request 640 may include information such as the following: destination IP address=IP Cw; source IP address=IP Ax (source port P A; destination port=P Z; chunk=INIT; end point IP addresses={IP A1, . . . , IP An}). After the contact host 620 determines to send the request to the server 630 (in a manner as described above), the request is forwarded 650 (or another message is generated containing the information within the request) to the server 630. The server 630 then responds to the client 610 with an acknowledgment 660 that may contain information such as the following: destination IP address=IP Ax; source IP address=IP Zz (source port=P Z; destination port=P A; chunk=INIT ACK; end point IP addresses={IP Z1, . . . , IP Zm}). Thereafter, the client 610 and the server 630 may commence data transfer (or other association) that bypasses or otherwise does not utilize the functionalities of the contact host 620.

FIG. 7 illustrates a further SCTP-based signaling diagram 700 among a client 710 (end point EP A) having associated IP addresses {IP A1, . . . , IP An} and a port P A, a contact host 720 (end point EP C) having associated IP addresses {IP C1, . . . , IP Co} and a port P Z, and a server 730 (end point EP Z) having associated IP addresses {IP Z1, . . . , IP Zm} and a port P Z. The client 710 may send an initiation request 740 to the contact host 720. This initiation request 740 may include information such as the following: destination IP address=IP Cw; source IP address=IP Ax (source port=P A; destination port=P Z; chunk=INIT; end point IP addresses={IP A1, . . . , IP An}). After the contact host 720 determines to send the request to the server 630 (in a manner as described above), and sends an acknowledgement 750 to the client 710. The acknowledgement 750 may contain information such as the following: destination IP address=IP Ax; source IP address=IP Zz (source port=P Z; destination port=P A; chunk=INIT ACK; end point IP addresses={IP Z1, . . . , IP Zm}). Thereafter, the client 710 and the server 730 may commence data transfer that bypasses or otherwise does not utilize the contact host 720.

Depending on the desired implementation, various modifications may be made to the configuration of the invention. For example, the contact host may be a dedicated machine that resided on a separate physical resource than the server. In other variations, the contact host is located on the same physical resource as the server (although such server may not ultimately be selected or associated by the contact host). Furthermore, the servers may belong to the same network node (i.e., they all offer connectivity to the same application service, such as the application layer above SCTP). In contrast, the servers may belong to different network nodes while offering the same application service.

Load balancing may be accomplished by determining various characteristics of the servers associated with the contact host, such as protocol processing capability (i.e., the processing performance occupied by processing a protocol packet), memory occupation (i.e., memory required for queue processing), and link capacity. In addition, the contact host may periodically poll the various servers, or in the alternative, a load balancing monitor, to determine where to allocate future associations.

As can be appreciated from the above, the use of a contact host shields the servers from attacks by acting like a firewall (i.e., by filtering unwanted requests). The IP addresses of the actual servers are not provided to the client prior to the publication in an initiation message such as INIT. Therefore, on-going data transfers (e.g., SCTP associations), are not affected by unwanted requests which tend to occupy server processing characteristics. Furthermore, the contact host offers a single contact address and hides a potential server distribution over several resources to the requesting clients. This distribution may be conducted in a manner of techniques, such as load balancing or round robin distribution, to more evenly apply load sharing.

Moreover, as the contact host facilitates the generation of an acknowledgment to each request, for example by (i) routing each request to an associated server and having the associated server acknowledge the request; or (ii) responding itself to each request with an acknowledgment (including the transport address(es) of an associated server), data transfer may be initiated directly between the client and the associated server without further intervention or mediation by the contact host. Although in some variations, the contact host may route or otherwise handle messages relating to the initiation of data transfer, there is no direct involvement by the contact host during data transfer (it may in this context be bypassed). In contrast, routers or other devices handle data during various stages of data transfer. By limiting messaging transactions handled by the contact hosts to the initiation of data transfer, rather than data transfer itself, the processing power of the contact hosts is not detrimentally affected during transfer of large amounts of data and they can continue to accept requests from numerous clients and facilitate the generation of acknowledgments that will subsequently be used to initiate data transfer.

While the current invention has been described with respect to particular embodiments (including certain system arrangements and certain orders of steps within various methods), those skilled in the art will recognize that the current invention is not limited to the specific embodiments described and illustrated herein. Therefore, while the present invention has been described in relation to its preferred embodiments, it is to be understood that this disclosure is only illustrative. Accordingly, it is intended that the invention be limited only by the scope of the claims appended hereto.

Claims

1. A method for handling initiation requests directed to a contact host from a plurality of clients, the method comprising the steps of: receiving, by the contact host, the initiation requests;associating, by the contact host, each initiation request from the plurality of clients with a server; andacknowledging the receipt of each request to initiate data transfer directly between the plurality of clients and each of the plurality of clients' associated server.

2. The method of claim 1, wherein the each of the plurality of clients' associated server acknowledges the request to each associated server's corresponding client.

3. The method of claim 1, further comprising the step of: receiving, by the each associated server from the each associated server's corresponding client, a confirmation that data transfer is to commence.

4. The method of claim 1, further comprising the step of: routing, by the contact host each of the initiation requests to the associated servers so that the associated servers may acknowledge each request.

5. The method of claim 1, wherein the contact host acknowledges the initiation requests to the plurality of clients.

6. The method of claim 5, further comprising the step of: receiving, by the contact host from the plurality of clients confirmation that data transfer is to commence.

7. The method of claim 5, further comprising the step of: forwarding any messages from each of the plurality of clients, by the contact host to the associated servers, after the data transfer has commenced.

8. The method of claim 5, further comprising the step of: discarding any messages received by the contact host from a client after the data transfer has commenced.

9. The method of claim 5, wherein each acknowledgment includes at least one IP address for the associated server.

10. The method of claim 9, wherein each associated server is multi-homed.

11. The method of claim 5, wherein the association step selects the associated server according to a round robin scheme.

12. The method of claim 1, wherein the association step determines the loads on the associated servers and selects the associated server according to a load balancing scheme.

13. The method of claim 1, further comprising the step of: dynamically assigning, by the contact host, addresses to the servers.

14. The method of claim 1, wherein the transport protocol is Streaming Control Transmission Protocol.

15. The method of claim 1, further comprising the step of: authenticating, by the contact host, each initiation request.

16. The method of claim 1, further comprising the initial step of: providing the contact host with a single address to accept requests to initially prevent direct access to the servers by the clients.

17.-19. (canceled)

20. A contact host for handling initiation requests received from a plurality of clients, the contact host comprising: a receiving unit for receiving the requests;an association unit for associating each request with a server; andan acknowledgment unit for initiating an acknowledgment to each requesting client.

21. A system, comprising: a plurality of clients for generating data transfer initiation requests;a plurality of servers for handling the data transfer requested by said plurality of clients; anda contact host for handling initiation requests received from said plurality of clients having: a receiving unit for receiving the requests;an association unit for associating each request with a server; andan acknowledgment unit for initiating an acknowledgment to each requesting client.

22. The system of claim 21, wherein each of the plurality of clients' associated server acknowledges the request to each associated server's corresponding client.

23. The system of claim 21, further comprising each of the plurality of servers having means for receiving from each associated server's corresponding client, a confirmation that data transfer is to commence.

24. The system of claim 21, further comprising means for routing, by the contact host, each of the initiation requests to the associated servers so that the associated servers may acknowledge each request.

25. The system of claim 21, further comprising means for receiving, by the contact host from the plurality of clients, confirmation that data transfer is to commence.

26. The system of claim 25, further comprising means for forwarding any messages from each of the plurality of clients, by the contact host to the associated servers, after the data transfer has commenced.

27. The system of claim 25, further comprising means for discarding any messages received by the contact host from a client after the data transfer has commenced.

28. The system of claim 25, wherein each acknowledgment includes at least one IP address for the associated server.

29. The system of claim 28, wherein each associated server is multi-homed.

30. The system of claim 25, wherein the association unit selects the associated server according to a round robin scheme.

31. The system of claim 21, wherein the association unit determines the loads on the associated servers and selects the associated server according to a load balancing scheme.

32. The system of claim 21, further comprising means for dynamically assigning, by the contact host, addresses to the servers.

33. The system of claim 21, wherein the transport protocol is Streaming Control Transmission Protocol.

34. The system of claim 21, further comprising means for authenticating, by the contact host, each initiation request.

35. The system of claim 21, further comprising means for providing the contact host with a single address to accept requests to initially prevent direct access to the servers by the clients.