WO2018032399A1

WO2018032399A1 - Server and method having high concurrency capability

Info

Publication number: WO2018032399A1
Application number: PCT/CN2016/095653
Authority: WO
Inventors: Zhongliang LI
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2016-08-17
Filing date: 2016-08-17
Publication date: 2018-02-22
Anticipated expiration: 2019-02-17

Abstract

A server comprising: a proxy comprising a network interface controller that is configured to receive data packets from clients, wherein the proxy is configured to copy the data packets from the network interface controller directly into user space; a protocol stack in user space, wherein the proxy is configured to send the data packets to the protocol stack; an event controller, wherein the protocol stack is configured to send events to the event controller, each event being at least partly based on information from one of the data packets; and one or more applications, wherein the event controller is configured to send an event notification batch to one of the one or more applications, wherein each event notification of the event notification batch corresponds to one of the events, wherein said one of the one or more applications is configured to batch process the event notification batch.

Description

SERVER AND METHOD HAVING HIGH CONCURRENCY CAPABILITY

TECHNICAL FIELD

The present invention relates to a high-concurrency server and method. More particularly, embodiments of the invention relate to internet gateway access technology and, in some embodiments, technology relating to data transmission and receipt using the Data Plane Development Kit (DPDK) .

BACKGROUND

There are many users of the world wide web. Furthermore, there are many different applications available in the world wide web, for example web sites and web services. An enormous number of requests need to be handled. In certain contexts, a huge number of requests are required to be handled by a single server. For example, in order to provide notification services to huge numbers of mobile devices, it is necessary to handle high numbers of connections in parallel.

In 1999 the C10K problem was raised for web servers, namely the problem of concurrently handling more than 10,000 connections or clients. This problem has been solved through the use of asynchronous non-blocking data transmission technology. However, higher-concurrency server systems still suffer from a number of restrictions.

For example, the procedure for the flow of sent and received data is complex and a higher performance is desirable. Furthermore, the known web server architecture has poor scalability, which negatively impacts on high-concurrency processing.

SUMMARY

According to the present invention there is provided a server comprising:

a proxy comprising a network interface controller that is configured to receive data packets from clients, wherein the proxy is configured to copy the data packets from the network interface controller directly into user space；

a protocol stack in user space, wherein the proxy is configured to send the data packets to the protocol stack；

an event controller, wherein the protocol stack is configured to send events to the event controller, each event being at least partly based on information from one of the data packets； and

one or more applications, wherein the event controller is configured to send an event notification batch to one of the one or more applications, wherein each event notification of the event notification batch corresponds to one of the events, wherein said one of the one or more applications is configured to batch process the event notification batch.

Optionally, the protocol stack is a distributed protocol stack comprising a plurality of protocol stack machines； and the proxy is configured to select a protocol stack machine to which to send the data packets.

Optionally, the protocol stack is configured to send acknowledgements directly to the clients bypassing the proxy in response to the data packets received from the clients via the proxy.

Optionally, each application is configured to determine an event type of the event notifications, wherein when the application determines that the event type is a new link for establishing a new link to a client, the application is configured to send to the event controller an indication of whether or not the application agrees to process that new link； and the event controller is configured to record for each new link whether or not the application agrees to process that new link.

Optionally, when the protocol stack receives a data packet comprising request data from a client via the proxy through an established link, the protocol stack is configured to enter the request data from the data packet into a database and to send a data event identifying where the request data can be found in the database to the event controller； the event controller is configured to send to said one of the one or more applications a data event notification corresponding to the data event to the application, so as to identify where the request data can be found in the database； and said one of the one or more applications is configured to extract the request data from the database based on the data event notification identifying where the request data can be found in the database.

Optionally, the protocol stack is a distributed protocol stack comprising a plurality of protocol stack machines； and the proxy is configured to determine a protocol stack machine to which to send the data packet comprising request data received through the established link based on information in the data packet such that the proxy assigns the data packet to the same selected protocol stack machine that handled the data packet for establishing the link.

Optionally, the proxy is configured to determine the selected protocol stack machine based on an IP address of the client, the IP address of the client being included in both the data packet for establishing the link and the data packet comprising the request data.

Optionally, the protocol stack is configured to identify the application, from among others of the applications, to which the event controller is to send the data event notification, based on an IP address of the application included in a session table generated for an established link.

Optionally, each application is configured to send response data in response to the request data directly to the client bypassing the proxy, the protocol stack and the event controller.

Optionally, each application is configured to analyse the request data and to determine whether the request data comprises an attack.

Optionally, when the protocol stack receives a data packet for establishing a new link from a client via the proxy, the protocol stack is configured to generate a session table comprising information from the data packet for establishing the new link.

Optionally, the server is configured to establish a connection to a third-party server that is separate from the proxy； when the protocol stack receives a data packet comprising third-party request data from the third-party server via the proxy, the protocol stack is configured to enter the third-party request data into a database and to send a data event identifying where the third-party request data can be found in the database from the protocol stack to the event controller； and the event controller is configured to send to said one of the one or more applications a data event notification corresponding to the data event, so as to identify where the third-party request data can be found in the database； and said one of the one or more applications is configured to extract the third- party request data from the database based on the data event notification identifying where the third-party request data can be found in the database.

Optionally, each application is configured to send data directly to the third-party server bypassing the proxy in response to the third-party request data.

Optionally, the proxy is configured to filter and discard any attack data from the data packets it receives from the clients before sending the data packets to the protocol stack.

Optionally, the application is configured to, in response to request data from a client, send a new link notification to the event controller； the event controller is configured to send a new link event to the protocol stack, the new link event corresponding to the new link notification； and the protocol stack is configured to send a synchronisation data packet to a third-party server, the synchronisation data packet being at least partly based on the new link event； wherein the application is configured to set a source IP address of the new link notification to an IP address of the client and to set a source port number of the new link notification to a port number of the client.

Optionally, the server is configured to use the Data Plane Development Kit, DPDK, for copying and sending data packets within the server.

Optionally, the protocol stack is configured to use Lightweight Internet Protocol, lwIP.

According to the present invention there is provided a method comprising:

receiving data packets at a network interface controller of a proxy；

copying the data packets from the network interface controller directly into user space；

sending the data packets to a protocol stack in user space；

sending events from the protocol stack to an event controller, each event being at least partly based on information from one of the data packets；

sending an event notification batch from the event controller to one of one or more applications, each event notification of the event notification batch corresponding to one of the events； and

said one of the one or more applications batch processing the event notification batch.

Optionally, the protocol stack is a distributed protocol stack comprising a plurality of protocol stack machines； and the proxy selects a protocol stack machine to which to send the data packets.

Optionally, the protocol stack sends acknowledgements directly to the clients bypassing the proxy in response to the data packets received from the clients via the proxy.

Optionally, each application determines an event type of the event notifications, wherein when the application determines that the event type is a new link for establishing a new link to a client, the application sends to the event controller an indication of whether or not the application agrees to process that new link； and the event controller records for each new link whether or not the application agrees to process that new link.

Optionally, when the protocol stack receives a data packet comprising request data from a client via the proxy through an established link, the protocol stack enters the request data from the data packet into a database and sends a data event identifying where the request data can be found in the database to the event controller； the event controller sends to said one of the one or more applications a data event notification corresponding to the data event to the application, so as to identify where the request data can be found in the database； and said one of the one or more applications extracts the request data from the database based on the data event notification identifying where the request data can be found in the database.

Optionally, the protocol stack is a distributed protocol stack comprising a plurality of protocol stack machines； and the proxy determines a protocol stack machine to which to send the data packet comprising request data received through the established link based on information in the data packet such that the proxy assigns the data packet to the same selected protocol stack machine that handled the data packet for establishing the link.

Optionally, the proxy determines the selected protocol stack machine based on an IP address of the client, the IP address of the client being included in both the data packet for establishing the link and the data packet comprising the request data.

Optionally, the protocol stack identifies the application, from among others of the applications, to which the event controller is to send the data event notification, based on an IP address of the application included in a session table generated for an established link.

Optionally, each application sends response data in response to the request data directly to the client bypassing the proxy, the protocol stack and the event controller.

Optionally, each application analyses the request data and determines whether the request data comprises an attack.

Optionally, when the protocol stack receives a data packet for establishing a new link from a client via the proxy, the protocol stack generates a session table comprising information from the data packet for establishing the new link.

Optionally, the server establishes a connection to a third-party server that is separate from the proxy； when the protocol stack receives a data packet comprising third-party request data from the third-party server via the proxy, the protocol stack enters the third-party request data into a database and sends a data event identifying where the third-party request data can be found in the database from the protocol stack to the event controller； and the event controller sends to said one of the one or more applications a data event notification corresponding to the data event, so as to identify where the third-party request data can be found in the database； and said one of the one or more applications extracts the third-party request data from the database based on the data event notification identifying where the third-party request data can be found in the database.

Optionally, each application sends data directly to the third-party server bypassing the proxy in response to the third-party request data.

Optionally, the proxy filters and discards any attack data from the data packets it receives from the clients before sending the data packets to the protocol stack.

Optionally, the application, in response to request data from a client, sends a new link notification to the event controller； the event controller sends a new link event to the protocol stack, the new link event corresponding to the new link notification； and the protocol stack sends a synchronisation data packet to a third-party server, the synchronisation data packet being at least partly based on the new link event； wherein the application sets a source IP address of the new link notification to an IP address of the client and sets a source port number of the new link notification to a port number of the client.

Optionally, the server uses the Data Plane Development Kit, DPDK, for copying and sending data packets within the server.

Optionally, the protocol stack uses Lightweight Internet Protocol, lwIP.

By copying the data packets from the network interface controller directly into user space, the data transmission performance is improved. In particular this makes it possible to bypass the kernel of the proxy (for example a Linux kernel network) . This circumvents the performance limitations of the kernel network.

Furthermore, by providing that the protocol stack is in user space, it is easier to upgrade and/or extend the protocol stack compared to if the protocol stack were in the kernel space. In particular, the release cycle of operating systems is slow. Providing the protocol stack in user space means that it is not necessary to wait for a new release of the operating system. Instead, the protocol stack can be extended and/or upgraded more easily in user space.

Furthermore, by using a proxy, it is easier to implement high load sharing capability. Proxy processing logic is simple and reduces the loss of data packets (like a no-loss router) .

Furthermore, by sending events to an event controller that then sends an event notification batch to the application, the application can batch process (i.e. one-time process) multiple event at the same time. This helps implement asynchronous operation of the application, making better use of system resources and improving the concurrent processing capabilities of the application.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 schematically depicts the network topology of a computer network comprising a server according to an embodiment of the invention；

Figure 2 is a schematic network diagram of a server according to an embodiment of the invention；

Figure 3 is a table showing exemplary proxy mapping between Internet Protocol (IP) addresses and media access control (MAC) addresses；

Figure 4 is an example of an address resolution protocol (ARP) format；

Figure 5 is an example of an IP format；

Figure 6 is an example of a Transmission Control Protocol (TCP) format；

Figure 7 is a diagram of exemplary transitions between session states of a session of a connection between a client and a protocol stack according to an embodiment of the invention；

Figure 8 is a data interaction diagram of an embodiment of the invention；

Figure 9 is a schematic diagram showing the network topology of a computer network comprising a server according to an embodiment of the invention；

Figure 10 is a data interaction diagram of an embodiment of the invention；

Figure 11 is a schematic diagram showing the network topology of a computer network comprising a server according to an embodiment of the invention；

Figure 12 is a data interaction diagram of an embodiment of the invention；

Figure 13 schematically shows a computer network in which a server of an embodiment of the invention may be implemented； and

Figure 14 is a data interaction diagram of an embodiment of the invention.

DETAILED DESCRIPTION

Figure 1 schematically depicts the network topology of a computer network comprising a server 20 according to an embodiment of the invention. Figure 2 schematically depicts a diagram of an exemplary internal network of a server 20 according to an embodiment of the invention. As shown in Figure 1, the server 20 is for establishing links (i.e. connections) to clients 11 over a network 12.

Components of the server 20 will be described in detail below. For ease of understanding, reference will be made to Figure 8, which illustrates the transmission of data packets according to an exemplary process flow in which a server 20 according to an embodiment of the invention is used. However, it is to be noted that the process flow depicted in Figure 8 is merely one example of a process flow using a server 20 of an embodiment of the invention. Other process flows can also be implemented and may involve some of the same data transmission steps shown in Figure 8.

As depicted in Figure 2, in an embodiment the server 20 comprises a proxy 21. The proxy 21 functions as the front end processor of the server 20. The proxy 21 functions as a proxy server that acts as an intermediary for requests from clients 11 seeking resources (e.g. access to web sites or web services) from the application 30. Each client 11 connects to the proxy 21 through the network 12, which may be the Internet. In an embodiment the server 20 is a web server and the application 30 is a web application such as a web site or a web service.

Optionally, the server 20 comprises a plurality of applications 30. For example, the different applications may correspond to different web sites or different web services. Optionally, the server 20 is configured to connect to further applications that are external to the server 20. In this way the server 20 can provide clients 11 with access to a wide variety of web sites and/or web services.

As depicted in Figure 1, the computer network that comprises the server 20 optionally comprises a firewall 13. The firewall 13 is configured to monitor and control the incoming and outgoing network traffic based on predetermined security rules. According to some embodiments of the invention, the server 20 performs the functions of the firewall 13. When the server 20 functions as a firewall, the firewall 13 shown in Figure 1 may not be necessary.

Optionally, the server 20 is connected to the network 12 via a router 14. The router 14 is configured to forward data packets between the server 20 and the network 12.

As shown in Figure 2, the server 20 comprises a network interface controller (NIC) 26, which may also be called a network interface card or a network card, for example. The NIC 26 connects the server 20 to the network 12 depicted in Figure 1. Optionally, the proxy 21 comprises the NIC 26, as shown in Figure 2. The NIC 26 is configured to receive data packets from clients 11 through the network 12.

For example, when a new link (i.e. connection) is to be established between the server 20 and a client 11 (e.g. so that the client 11 can access services from the application 30) , the client 11 may send a data packet called a synchronisation packet (SYN) to the server 20. This is labelled as step 803 in Figure 8. The SYN is received at the server 20 by the NIC 26. Once a link has been established, the client 11 may send another data packet comprising request data for requesting a service from the application 30. This is labelled as step 810 in Figure 8. The data packet comprising the request data is received at the server 20 by the NIC 26. The NIC 26 can receive other types of data packets such as acknowledgements, for example.

In an embodiment the proxy 21 is configured to copy the data packets from the NIC 26 directly into user space. The user space is the memory area of the server 20 where application software and some drivers execute. In contrast, kernel space is reserved for running a privileged operating system kernel, kernel extensions and most device drivers.

By copying the data packets from the NIC 26 directly into user space, the kernel space of the server 20 is bypassed. An embodiment of the invention is expected to achieve an improvement in data transmission performance, i.e. an improvement in speed of data transmission through the server 20. In particular, the present inventors have found that the speed of kernel networking in Linux (or other operating systems) is not sufficient for some workloads. Typically a NIC is capable of handling a much higher throughput than the Linux kernel. By working around (i.e. avoiding) the kernel networking stack, throughput can be improved. Bypassing the kernel network circumvents the performance limitations of the kernel network.

Merely as an example, an embodiment of the invention bypasses the kernel network by using the Data Plane Development Kit (DPDK) . This allows the invention to take advantage of the high data transmission capabilities of the DPDK. The DPDK refers to the data plane development tools provided by

intended to provide library functions and driver support for high-efficiency data packet processing in the user space within

processor architecture. The DPDK differs from the Linux universal design model and instead focuses on network application of high-performance data processing capabilities. It has already been verified that the DPDK can run on most Linux operating systems, including FreeBSD 9.2, Fedora release18, Ubuntu 12.04 LTS, RedHat Enterprise Linux 6.3 and Suse Enterprise Linux 11 SP2. DPDK uses the BSD licence, greatly increasing the convenience of the fundamental way businesses realise their protocol stacks and applications. Hence, the DPDK is a set of data plane libraries and network interface control drivers for fast packet processing. The DPDK is a networking framework written in C, created especially for

chips.

As explained above, in an embodiment the proxy 21 is configured to copy the data packets from the NIC 26 directly into user space. When a data packet is in user space, the data packet is user-mode data. User-mode data is data in user space. Hence, an embodiment of the invention involves directly copying data from the NIC 26 into user-mode data. This bypasses the complex process of the Linux kernel protocol stack procedure. As a result the overall performance of the data transmission is improved. The direct copying of data from the NIC 26 into user-mode data may be performed using DPDK technology. The DPDK has been found to be a particularly efficient technology.

Alternatively, any other suitable method or technology may be used to perform the same functionality.

When the DPDK is used, the server 20 may comprise the DPDK data frame memory pool. The DPDK data frame memory pool is configured to store data packets. The DPDK data frame memory pool is a set of resources for memory management that allows data packets to be allocated to the DPDK data frame memory pool. In an exemplary embodiment, when a data packet (such as a SYN or a data packet comprising request data) is received by the NIC 26, the data packet is copied into a buffer area of the DPDK data frame memory pool.

In an embodiment the server 20 comprises a data frame address queue. When the data packet is copied into the buffer area of the DPDK data frame memory pool, the data frame address is simultaneously (or nearly simultaneously) stored in the data frame address queue. The data frame address identifies how the data frame can be found in the data frame memory pool.

The proxy 21 is configured to monitor the data frame address queue. When the proxy 21 finds a data frame address in the data frame address queue, the proxy 21 extracts the data packet from the DPDK data frame memory pool based on (i.e. using) the data frame address. The proxy 21 processes the extracted data packet, as described below. Optionally, the proxy 21 is configured to determine a protocol format of the data packet. Optionally the data packet has a packet structure comprising a plurality of headers. For example, an Internet Protocol (IP) header and a Transmission Control Protocol (TCP) header. Different data packets may have different packet structures and may have different headers. For example, another data packet may have an address resolution protocol (ARP) header. The packet structure may depend on the purpose of the data packet. For example, a data packet for establishing a link to the server 20 may comprise an IP header and a TCP header. A data packet for identifying the correspondence between a MAC address and an IP address may comprise an ARP header.

In an embodiment, the proxy 21 is configured to analyse the data packet to determine the protocol format of each header. For example, the proxy 21 may determine whether the protocol format of the header of the data packet is ARP, IP or another protocol format. Optionally, the proxy 21 is configured to process only data packets corresponding to certain protocol formats. In other words, the proxy 21 may have configuration limits. If the proxy 21 determines that the protocol format of the data packet is not within the configuration limits (i.e. when the header of the data packet is not a format that is to be handled by the proxy 21) , the proxy 21 is configured to discard the data packet.

Figure 4 shows an exemplary format of part of a data packet comprising an ARP header. As shown in Figure 4, the header comprises a protocol type field. Typically, a value of 0x0806 in the protocol type field indicates that the protocol type of the next section (i.e. the next header) of the data packet is ARP. A value of 0x0800 in the protocol type field would indicate IP. Optionally, the proxy 21 is configured to read the value of the protocol type field and to discard any data packet that has a value other than 0x0806 or 0x0800.

If the value in the protocol type field indicates that the protocol type is ARP (e.g. as shown in Figure 4) , then the proxy 21 is configured to respond to the data packet in accordance with ARP. In accordance with the protocol type field indicating ARP, the data packet section shown in Figure 4 comprises an Ethernet ARP segment that shows the correspondence between MAC addresses and IP addresses. IP addresses can also be called network addresses. MAC addresses can also be called hardware addresses (e.g. as in Figure 4) or physical addresses.

The response of the proxy 21 may be to map the correspondence between the MAC addresses and the IP addresses. For example, the example shown in Figure 4 shows a data packet that has an ARP segment that shows the correspondence between the MAC address of the source (e.g. the client 11) and the IP address of the source. The ARP segment also shows the correspondence between the MAC address of the destination (e.g. the application 30) and the IP address of the destination.

If the value in the protocol type field indicates IP, then the data packet contains a header according to the IP format, for example as shown in Figure 5. Figure 5 shows an example of a specific type of IP format called Internet Protocol version 4 (IPv4) format.

As shown in Figure 5, in the IPv4 format there is a protocol field. The protocol field identifies the protocol of the next level (i.e. the next header) in the data packet. As shown in Figure 5, the protocol field is typically an 8-bit field. It is not necessary for IPv4 to be used. The present invention can be implemented to transmit data packets according to other protocols or other versions of protocols. For example, Internet Protocol version 6 (IPv6) may be used, in which the equivalent field to the protocol field of IPv4 is called the next header field. In IPv4, the protocol of the next header in the data packet is identified by a decimal in the protocol field. For example, if the decimal is 6, then the protocol of the next header is TCP. An exemplary TCP format for the next header in the data packet is shown in Figure 6.

The proxy 21 is configured to send the data packets to the protocol stack 22. For example, the proxy 21 is configured to send a SYN to the protocol stack, as labelled as step S804 in Figure 8. As another example, the proxy 21 is configured to send a data packet that comprises request data to the protocol stack 22, as labelled as step 806 in Figure 8.

The protocol stack 22 is provided in user space of the server 20. Accordingly, an embodiment of the invention is expected to achieve a user-mode based protocol stack 22. The protocol stack 22 is user-mode based because the protocol stack 22 is established in user space of the server 20. This allows the transmission and receipt of data by the protocol stack 22 to bypass the operating system in the kernel space of the server 20. This avoids the need for data to switch between kernel mode data and user mode data, thereby improving the speed of data transmission and receipt.

As depicted in Figure 2, in an embodiment the protocol stack 22 is a distributed protocol stack comprising a plurality of protocol stack machines 23. In the example shown in Figure 2, there are three protocol stack machines 23. However, this need not necessarily be the case. The number of the protocol stack machines 23 is not particularly limited. For example, the number of protocol stack machines 23 may be two, more than three or only one (if the protocol stack 22 is not a distributed protocol stack) .

Optionally, the proxy 21 is configured to select a protocol stack machine 23 to which to send the data packet. The data packet is sent to the selected protocol stack machine 23.

For example, if the proxy 21 determines that the protocol format of a header of the data packet is IP, then the proxy 21 is configured to extract data from the source IP address field in the IPv4 header. Optionally, the proxy 21 is configured to extract data from the source IP address field according to a hash function. The proxy 21 is configured to select a protocol stack machine 23 to which to send the data packet based on the source IP address of the data packet. In an alternative embodiment, the proxy 21 is configured to select a protocol stack machine 23 to which to send the data packet based on other information such as the destination IP address.

The proxy 21 is configured to send the data packet to the selected protocol stack machine 23. Optionally, the proxy 21 is configured to map the data packet to the selected protocol stack machine 23 according to a hash function. Optionally, the proxy 21 already knows the IP address of each of the protocol stack machines 23. In an embodiment the proxy 21 is configured to determine the MAC address of each protocol stack machine 23 based on the known IP address by using ARP. The proxy 21 is configured to use the ARP for mapping an IP address of each protocol stack machine 22 to a MAC address.

For example, in an embodiment the proxy 21 is configured to read data packets when it is powered on. The proxy 21 is configured to analyse the ARP segment of the data packets to determine the MAC address corresponding to the IP address of each protocol stack machine 23. The proxy 21 is configured to generate a map between the IP addresses and the MAC addresses in the memory of the proxy 21. Figure 3 is a table showing an exemplary implementation of the mapping between the IP addresses and the MAC addresses of the protocol stack machines 23.

Of course other formats for the mapping may be used. The addresses shown in Figure 3 are merely exemplary. The invention can be implemented with protocol stack machines have any IP address or MAC address. It is not necessary for the proxy 21 to use ARP to determine the MAC addresses of the protocol stack machines 23. In an alternative embodiment the IP addresses and the MAC addresses of the protocol stack machines 23 are already stored in the proxy 21.

In an embodiment the proxy is configured to determine the MAC address of the selected protocol stack machine 23 based on the IP address of the selected protocol stack machine 23 using the mapping stored in the proxy 21. For example if the IP address of the selected protocol stack machine 23 is 192.168.1.2, then the MAC address obtained will be 0C: 35: 62: A4: 54: 46 (in accordance with the mapping shown in Figure 3) .

In an embodiment the proxy 21 is configured to modify the data packet by writing the MAC address of the selected protocol stack machine 23 into the destination hardware address field of the data packet. The network switch for the server is configured to read the destination hardware address field of the data packet and to send the data packet to the selected protocol stack machine 23 based on the destination hardware address (i.e. the MAC address of the selected protocol stack machine 23. Optionally, the server 20 comprises the network switch. Alternatively, the network switch may be external to the server 20. Optionally, the data packet is sent to the selected protocol stack machine 23 using application programming interface (API) of the DPDK.

As shown in Figure 2, the protocol stack 22 is in communication with the application 30 via the event controller 24. Optionally, the protocol stack 22 is in communication with a plurality of applications 30 via the event controller 24. In order to establish a relationship between the protocol stack and an application 30, the protocol stack 22 and the application 30 may be configured to performs a listen registration process. The listen registration in labelled as step 801 in Figure 8. The listen registration is for registering an application 30 to the protocol stack 22. When an application 30 has been registered to the protocol stack 22, the protocol stack 22 can send requests to the application 30 for processing.

An exemplary implementation of the listen registration process will now be described in more detail. Optionally, the listen registration process comprises the protocol stack 22 opening a registration interface for the application 30. The application 30 sends registration information to the protocol stack 22. For example, the registration information may comprise the MAC address of the application 30, the IP address of the application 30 and/or available port numbers of the application 30.

Optionally, the application 30 has a listen mode. When the application 30 is operating in the listen mode, the application 30 is configured to send the registration information to the protocol stack 22. When the application 30 is not operating in the listen mode, the application 30 is configured to not send the registration information to the protocol stack 22.

When the protocol stack 22 receives a data packet (e.g. a SYN for establishing a connection to a particular application 30) , the protocol stack 22 can check whether that application 30 identified in the data packet is registered. The application 30 may be identified in the data packet by a destination IP address and a port number in the data packet. For example the destination IP address may be stored in the IPv4 header of the data packet and the destination port number may be stored in the TCP header of the data packet.

If the application 30 is registered, then the protocol stack 22 is configured to proceed with processing the data packet to access services of the application 30 (e.g. to establish a new link with the application 30 or to request data from the application 30) . Optionally, the protocol stack 22 is configured to discard the data packet if the application 30 identified in the data packet is not registered with the protocol stack 22. When the application 30 identified in the data packet is registered, the stored data packet is then processed.

Optionally, the protocol stack 22 is configured to generate a table for storing the registration information of all applications 30 registered to the protocol stack 22. The table comprises the registration information for each application 30.

When the protocol stack 22 receives a data packet from the proxy 21, the protocol stack 22 is configured to analyse the data packet. The protocol stack 22 is configured to analyse the table of registration information to determine whether the application 30 corresponding to the destination port number and destination IP address contained in the data packet is registered.

The way that the protocol stack 22 processes the data packets depends on the type of data packet. For example, the protocol stack 22 is configured to process the data packet differently depending on whether the data packet is a SYN for establishing a new link, an acknowledgement for a new link, a data packet comprising request data received on an established link, an acknowledgement of response data received or an acknowledgement of a link closure (FIN ACK) . During a process flow, the protocol stack 22 may receive each of these types of data packet. The processes performed are described in more detail below, with reference to Figure 8.

Optionally, the protocol stack 22 is configured to determine the type of data packet. When the protocol stack 22 receives a SYN (i.e. a data packet for establishing a new link) from a client 11 via the proxy 21, the protocol stack 22 is configured to generate a session table. The session table comprises information read from the SYN.

For example, in an embodiment the protocol stack 22 is configured to read and store in the session table the source port number, the source IP address, the destination port number, the destination IP address and the protocol type from the data packet. For example, the source port number and the destination port number may be stored in the TCP header. The source destination IP address and the destination IP address may be stored in the IPv4 header.

The destination port number is for specifying the service that the client 11 is intending to use from the application 30. For example, optionally the application 30 offers a plurality of services such as HTTP, FTP and telnet. The destination port number of the data packet specifies which of these services is required. For example, typically the port number for HTTP is 80, the port number for FTP is 21 and the port number for telnet is 23. However, it is not necessary for the protocol stack 22 to read and store the destination port number in the session table. For example, in an alternative embodiment the application 30 offers only one service, such that it is not necessary for the service to be specified by any destination port number.

When a data packet is sent from the server 20 back to the client 11, the source port number can be used as the destination port number. The client 11 can identify that the data packet is a response to the data packet that the client 11 previously sent to the server 20 because the destination port number of the response data packet corresponds to the source port number of the data packet that the client 11 sent.

The session table comprises information related to the link being formed between the client 11 and the server 20. For example, the session table comprises the source port number, the source IP address, the destination port number and the destination IP address, as explained above. In an embodiment the session table comprises the protocol type of the data packet. For example, the protocol type may be TCP.

However, this is not necessarily the case. For example, in an alternative embodiment the server is configured to support only TCP based connections, in which case it is not necessary to store the protocol type. In a further alternative embodiment, the server 20 is configured to support connections based on various different protocols but the protocol type is not stored in the session table.

Exemplary contents for the session table established by the protocol stack 22 is set out in the table below. As shown in the table, the information contained in the SYN may be referred to as five element information.

The session table contents are as follows:

As shown in the exemplary session table above, optionally the session table comprises the source MAC address. This allows the application 30 (to which the information in the session table is sent as an event notification described below) to send data directly to the client 11, bypassing the proxy 21 and the protocol stack 22.

As shown in the exemplary session table above, optionally the session table comprises the SYN serial number. The SYN serial number uniquely identifies the SYN sent by the client 11. Hence, the SYN serial number uniquely identifies the link that is established with the client 11. Later in the process flow, the application 30 may send data directly to the client 11. From the point of view of the client 11, the data is received from the application 30 in the same way that the client 11 would receive data from the proxy 21. The client 11 does not receive any indication that the data is received from a machine that is different from the proxy 21 to which the client 11 sent the SYN (or the data packet that comprises request data) .

As shown in the exemplary session table above, optionally the session table comprises the SYN ACK serial number. The SYN ACK serial number uniquely identifies the synchronization acknowledgement packet that the protocol stack 22 sends to the client 11 in response to the SYN. Hence, the SYN ACK serial number uniquely identifies the link that is established with the client 11. Later in the process flow, the application 30 may send data directly to the client 11. From the point of view of the client 11, the data is received from the application 30 in the same way that the client 11 would receive data from the proxy 21. The client 11 does not receive any indication that the data is received from a machine that is different from the proxy 21 to which the client 11 sent the SYN (or the data packet that comprises request data) .

However, it is not necessary for the protocol stack 22 to store both the SYN serial number and the SYN ACK serial number in the session table. In an alternative embodiment the protocol stack 22 is configured to store only one of the SYN serial number and the SYN ACK serial number in the session table.

As shown in the exemplary session table above, optionally the session table comprises a database index. The database index is information identifying where a particular piece of data may be found in a database 25 (shown in Figure 2) . In particular, for data packets containing request data, the request data may be stored in a database 25, in which case the database index identifies the address of the request data in the database 25. However, for a SYN, it is not necessary to store data in the database 25. Accordingly, the database index field of the session table above is empty (i.e. NULL) .

Although not shown in the session table above, in an embodiment the session table comprises a session state indicator. Session state indicators can be: LISTEN, SYN_RCVD, ESTBLISHED, CLOSE_WAIT, LAST_ACK and CLOSED. The session states are explained below.

Figure 7 schematically depicts a server link transmission diagram for the TCP. TCP processes, such as the process illustrated in Figure 8, may be divided into three phases. Links should be properly established in a multi-step handshake process (link establishment) before entering the data transfer phase. After data transmission is completed, the link closure closes established virtual circuits and releases all allocated resources. The three phases are hence link establishment, data transfer and link closure. In Figure 8, the link establishment phase is represented by steps 803 to 809, the data transfer phase is represented by steps 810 to 813. The link closure phase is represented by steps 814 to 816.

During the lifetime of the TCP process the session state changes. The LISTEN state means that the protocol stack 22 is waiting for a SYN from a client 11. The SYN_RCVD state means that the protocol stack 22 has received a SYN, sent a SYN ACK in response and is waiting for an acknowledgement (ACK) of the SYN ACK from the client 11. The ESTABLISHED state represents an open link with the client 11. This is the normal state for the data transfer phase of the process. The CLOSE_WAIT state means that the protocol stack 22 is waiting for a link closure event from the application 30. The LAST_ACK state means that the protocol stack 22 is waiting for an acknowledgment of the link closure (FIN ACK) from the client 11. The CLOSED state means that there is no link state at all.

The link establishment phase of the process is explained below. To establish a link, a three-way handshake may be used. The three-way handshake is described as follows. The client 11 sends the SYN to the protocol stack 22 via the proxy 21 (see steps 803 and 804 in Figure 8) . In response, the protocol stack 22 sends a SYN ACK (see step 805 in Figure 8) . The SYN ACK may be sent from the protocol stack directly to the client 11 bypassing the proxy 21 in response to the SYN. The client 11 cannot detect that this SYN ACK was sent from another machine (i.e. a different machine from the proxy 21 to which the client 11 sent the SYN) .

Finally, the client 11 sends an ACK back to the protocol stack 22 via the proxy 21 (see step 806 in Figure 8) . At this point, both the client 11 and the protocol stack 22 have received an acknowledgment of the connection. The steps of sending the SYN and responding with the SYN ACK establish the SYN serial number for one direction and this is acknowledged. The steps of sending the SYN ACK and the ACK establish the SYN ACK serial number for the other direction and this is acknowledged. Both the SYN serial number and the SYN ACK serial number uniquely identify the link. With these steps, a full duplex communication is established.

The protocol stack 22 is configured to send events to the event controller 24 of the server 20. The protocol stack 22 is configured to send events of different types to the event controller 24.

For example, once the three-way handshake described above is completed, the protocol stack 22 is configured to send a new link event to the event controller 24 (see step 807 in Figure 8) . A new link event is an event that has an event type of new link. When the protocol stack 22 receives a data packet that comprises request data on an established link, the protocol stack 22 is configured to send a data event to the event controller 24 (see step 811 in Figure 8) . A data event is an event having an event type of data.

The protocol stack 22 is configured to send events to the event controller 24. Each event is at least partly based on information from one of the data packets. For example, a new link event is based on information form a SYN. A data event is based on information from a data packet that comprises request data.

For example, in an embodiment the event comprises the data packet information, namely the source IP address, the source port number, the destination IP address, the destination port number and the protocol type.

Exemplary contents of an event are set out in the table below.

As shown in the example above, optionally the event comprises the SYN serial number and/or the SYN ACK serial number. As shown in the example above, optionally the event comprises the database index (primarily used for data events) .

As shown in the example above, optionally the event comprises the event type. For example, the event shown above is a new link. The event type of the event may not be based on information in the data packet. Instead, the protocol stack 22 is configured to assign the event type to the event. For this reason, the event may not be completely based on information from one of the data packets. Instead, the event may be only partly based on information from one of the data packets. Optionally, the event type field may be populated by three different possible codes. Code 0x01 represents a new link event. Code 0x02 represents a data event. Code 0x03 represents a link closure event.

Optionally, the DPDK is used for the step of sending the new link event from the protocol stack 22 to the event controller 24.

Optionally, the event controller 24 comprises a received data queue. The received data queue stores the events received by the event controller 24 from the protocol stack 22. The received data queue may be a DPDK received data queue. When the event controller 24 receives an event, the event controller 24 is configured to determine the event type of the event. For example, the event controller 24 may read the event type field of the event to determine the event type. The event controller 24 is configured to process the event depending on the event type.

The event controller 24 is configured to generate an event notification corresponding to the event. In an embodiment the event controller 24 is configured to generate the event notification based on the event type of an event. For a new link event, the event controller 24 is configured to generate a new link notification that contains the same information as the new link event (e.g. as shown in the exemplary new link event above) . The event controller 24 is configured to store the event notification in an event notification batch.

The event controller 24 is configured to send an event notification batch to the application 30. Each event notification of the event notification batch corresponds to one of the events (i.e. a corresponding event) . The event controller 24 is configured to send the event notification batch (which may be referred to as an event queue) to the application 30 in the form of data. An example of the format in which the event controller 24 sends the event notification batch to the application 30 is shown below. Optionally, the DPDK is used for the step of sending the new link notification from the event controller 24 to the application 30.

When the application 30 receives the event notification batch, the application 30 is configured to batch process the event notification batch. The application 30 is configured to one-time process a plurality of event notifications.

Hence the event controller 24 is configured to send to the application 30 a plurality of event notifications simultaneously. This helps to implement asynchronous operation of the application 30, making full use of system resources and improving the concurrent processing capabilities of the application 30.

The three-way handshake event of the event controller 24 for high-concurrency will as far as possible send several events at the same time to the application 30. The application 30 will then one-time process all of the event notifications (e.g. process n new link notifications) .

For a new link notification, the application 30 is configured to determine whether or not to accept the request for the new link. In particular, the application 30 is configured to determine an event type of each event notification. When the application 30 determines that the event type is a new link for establishing a new link to a client, the application 30 is configured to send to the event controller 24 an indication of whether or not the application 30 agrees to process that new link.

The event controller 24 is configured to record for each new link whether or not the application 30 agrees to process that new link. Optionally, the event controller 24 stores the new link events agreed for processing with the application 30 in a hash table, and stores the new link events not agreed for processing with the application 30 in another hash table. The storage in the hash tables increases the efficiency of the search performed when following up on sent new link notifications.

Optionally, the application 30 is configured to send to the event controller 24 information about the number of event notifications processed and whether or not the processing was successful.

Once the link has been established, data can be transmitted between the application 30 and the client 11 over the network 12. This is the data transfer phase of the process and is described below.

In particular the client 11 may send a data packet comprising request data to the proxy 21 (see step 810 in Figure 8) . The proxy 21 assigns the request data to the same selected protocol stack machine 23 to which the SYN was assigned (see step 810 in Figure 8) . For example, the proxy 21 may determine the selected protocol stack machine 23 based on an IP address of the client 11 (i.e. the source IP address in the data packet) , the IP address of the client 11 being included in both the SYN and the data packet that comprises request data. The proxy 21 may hash the request data to the same protocol stack machine 23.

The protocol stack 22 has previously generated a session table for the link to the client 11. The protocol stack 22 is configured to find the application 30 in the session table based on the destination IP address and destination port number included in the data packet that comprises the request data. In particular, the destination IP address identifies the machine and the destination port number identifies the service (e.g. web site or web service) .

Optionally, the protocol stack 22 is configured to send an acknowledgement (ACK) of the data packet that comprises the request data directly to the client 11, bypassing the proxy 21.

The protocol stack 22 is configured to determine that the received data packet comprises request data and is on an established link (rather than being a SYN, for example) . When the protocol stack 22 receives a data packet comprising request data from a client 11 via the proxy 21 through an established link, the protocol stack 22 is configured to enter the request data from the data packet into a database 25. In an embodiment the database 25 is part of the server 20. In an alternative embodiment the database 25 is external to the server 20.

The protocol stack 22 is configured to send a data event identifying where the request data can be found in the database to the event controller 24. For example the data event may include a database index. Optionally, the protocol stack 22 identifies the application 30, from among other applications, to which to the data event notification (corresponding to the data event) is to be sent, based on a destination IP address of the application 30 and/or a destination port number for the application 30 included in the session table. As shown in the exemplary session table above, the destination IP address may be included in the session table. The protocol stack 22 is configured to include in the data event information identifying which application 30 the event controller 24 is to send the data event notification.

Optionally, the event controller 24 finds the information from the hash table that stores new link events agreed for processing with the application 30. The event controller 24 then packages the information from the hash table into a data event notification and sends the data event notification to the application 30 (see step 811 in Figure 8) . The data event notification corresponds to the data event. The data event notification is for identifying the request data in the database 25 so that the application 30 can later extract the request data from the database 25. The data event notification may include the database index.

The application 30 is configured to extract the request data from the database 25 based on the data event notification identifying where the request data can be found in the database 25 (see step 812 in Figure 8) . For example, the application 30 may use the database index.

In an alternative embodiment, the database 25 is not necessary. For example, the request data may be included as part of the data event and the data event notification. When the application 30 finishes the processing, the request data is uploaded. Optionally, the method of transmitting data comprises sending response data in response to the request data directly from the application 30 to the client 11, bypassing the proxy 21, the protocol stack 22 and the event controller 24. For example, the request data may require that the data is sent to the client 11. The response data is packaged and sent directly to the client 11 (see step 813 in Figure 8) . The client 11 receives the response data. The client 11 will recognise the response data as a data packet on the same link established through sending the SYN. This is because of the one-to-one correspondence between the SYN serial number (and/or the SYN ACK serial number) and the established connection.

Optionally, the client 11 sends an acknowledgment of receiving the response data to the proxy 21. The proxy 21 sends the acknowledgment to the protocol stack 22. The protocol stack 22 sends a confirmation message to the application 30. This completes confirmation of receipt of the response data.

Optionally, the client 11 implements a checksum mechanism during sending to ensure data reliability. If the checksum mechanism reveals a problem, the checksum mechanism can allocate to the application 30 a send function response retry code, so that the application 30 can later retry sending the response data.

Optionally, the method comprises closing the link. When the application 30 closes the link, the application 30 packages a link closure notification (event type 0x03) and sends the link closure notification to the event controller 24 (see step 814 in Figure 8) . The event controller 24 notifies the protocol stack 22 of the link closure event. The protocol stack 22 sends a FIN packet to the client 11 (see step 815 in Figure 8) . The client 11 receives the FIN packet and responds with a FIN ACK packet to the protocol stack 22 via the proxy 21. The protocol stack 22 then responds with an ACK to the client 11, thereby finishing the link closure process (see step 816 in Figure 8) .

Figure 8 is a data interaction table for an implementation of a process according to an embodiment of the invention. This is merely an exemplary embodiment. Steps in the process are explained below.

In step 801, the application 30 sends registration information to the protocol stack 22. The registration information may be for listen port 80, for example. Port 80 is for the hypertext transfer protocol (HTTP) .

In step 802 (not shown in Figure 8) , the protocol stack 22 sets up a registration table for registering information about the application 30. For example, the information stored in the information table may include the MAC address of the application 30, available port numbers and the IP address of the application 30.

In step 803, the client 11 sends the SYN to the proxy 21.

In step 804, the proxy 21 selects a protocol stack machine 23 based on contents of the SYN, sends the SYN to the selected protocol stack machine 23 and generates a session table. The session table establishes a relationship between the information contained in the SYN and the protocol stack machine 23.

In step 805, after the protocol stack 22 has received the SYN, the protocol stack 22 enquires whether it has the appropriate application 30 registered based on the destination IP address and the destination port listed in the SYN. If the application 30 is not registered, the protocol stack 22 drops the SYN. If the application 30 is registered, then the protocol stack 22 sends the SYN ACK directly to the client 11.

In step 806, the client 11 sends an ACK to the protocol stack 22 via the proxy 21. The protocol stack 22 internally finalises the three-way handshake for the link set up session.

In step 807, the protocol stack 22 sends a new link event to the event controller 24.

In step 808, the event controller 24 sends the new link notification to the application 30.

In step 809, the application 30 agrees to process the link (e.g. the application 30 is ready to start receiving data) and sends a notification to the event controller 24. The event controller 24 sends the indication that the application 30 is ready to start processing to the protocol stack 22. The “start processing” notification shown in Figure 8 is the indication of the application 30 agreeing to process the new link.

In step 810, the client 11 sends a data packet comprising request data to the proxy 21. The proxy 21 sends the data packet that comprises request data to the appropriate protocol stack machine 23.

In step 811, the protocol stack 22 enters the request data into the database 25. The protocol stack 22 creates a data event and sends the data event to the event controller 24. The event controller 24 sends a corresponding data event notification to the application 30.

In step 812, the application 30 extracts the request data from the database 25. This is based on information included in the data event notification identifying the request data in the database 25. That information may be a unique database index, which may be called a key. The application 30 begins logic processing on the extracted request data.

In step 813, the application 30 sends response data directly to the client 11.

In step 814, the application 30 has finished sending the response data. The application 30 sends a link closure notification to the event controller 24.

In step 815, the event controller 24 sends a corresponding link closure event to the protocol stack 22. The protocol stack 22 creates a FIN packet and sends the FIN packet directly to the client 11.

In step 816, the client 11 sends a FIN ACK packet to the protocol stack 22 via the proxy 21. The protocol stack 22 sends an ACK packet to the client 11.

In step 817 (not shows in Figure 8) , the protocol stack 22 starts deleting the session information for this link.

Figure 9 schematically depicts another computer network comprising a server 20 according to an embodiment of the invention. As depicted in Figure 9 (and also shown in Figure 1) , the computer network may comprise a router 14. In the computer network shown in Figure 9, one or more third-

party servers

41, 42, 43 are connected to the same router 14 to which the server 20 is connected.

Figure 10 shows a data interaction table for the computer network shown in Figure 9. In Figure 10, the “server” in the left side of Figure 10 corresponds to one of the third-

party servers

41, 42, 43 shown in Figure 9. The process depicted in Figure 10 according to an embodiment of the invention is described below.

In step 901, steps 801 to 812 are performed.

Steps 902 to 913 are extra steps (compared to the process depicted in Figure 8) for the extra process of sending information to a third-

party server

41, 42, 43. This extra process is demarcated by the dashed box in Figure 10.

In step 902, the application 30 sends a new link notification to the event controller 24. The event controller 24 sends the corresponding new link event to the protocol stack 22. The protocol stack 22 sends a SYN to the proxy 21.

In step 903, the proxy 21 stores information about the SYN. For example, the proxy 21 may store information about the protocol stack that the SYN was sent from. The proxy 21 sets up a relationship with the information from the SYN, for example by establishing a session table. The proxy 21 sends the SYN to the third-

party server

41, 42, 43.

In step 904, the proxy 21 receives the SYN ACK from the third-

party server

41, 42, 43. The proxy 21 determines which protocol stack machine 21 to which to send the SYN ACK. The proxy 21 sends the SYN ACK to the determined protocol stack machine 23.

In step 905, the protocol stack 22 has received the SYN ACK. The protocol stack 22 sends an ACK directly to the third-

party server

41, 42, 43. This completes the three-way handshake.

In step 906, the protocol stack 22 sends a link ready notification to the event controller 24.

In step 907, the event controller 24 sends a link set up notification to the application 30.

In step 908, the application 30 sends data directly to the third-

party server

41, 42, 43. The application 30 bypasses the proxy 21.

In step 909, the

third party server

41, 42, 43 sends an ACK in return to the proxy 21. The proxy 21 determines which protocol stack machine 23 to send the ACK to. The proxy 21 sends the ACK to the determined protocol stack machine 23.

In step 910, the protocol stack 22 sends the ACK to the application 30.

In step 911, the third-

party server

41, 42, 43 sends data to the proxy 21. The proxy selects which protocol stack machines 23 to which to send the data. The proxy 21 sends the data to the selected protocol stack machine 23. The protocol stack 22 stores the data in a database 25, which may be the same or different from the database 25 in which the request data is earlier stored. The protocol stack 22 sends a data event to the event controller 24. The event controller 24 sends a corresponding data event notification to the application 30.

In step 912, the protocol stack 22 sends an ACK to the third-

party server

41, 42, 43.

In step 913, the application 30 extracts the data from the database 25. The application 30 begins service logic processing on the data.

In step 914, steps 813 to 817 are performed.

Figure 11 schematically depicts another computer network in which a server 20 of an embodiment of the present invention may be implemented. In the computer network shown in Figure 11, third-

party servers

51, 52, 53 are connected to the internet 12. Figure 12 schematically depicts a data interaction diagram for a process that may be performed within the computer network shown in Figure 11. As can be seen from a comparison between Figure 12 and Figure 10, the process is largely the same.

In the processes shown in the dashed box area of Figure 12, the application 30 starts to establish a link to the third-

party server

51, 52, 53. The application 30 sets the source IP address as the client IP address, the source port as the client port and starts to send a setup notification to the event controller 24. As a result the client 11 does not know the existence of the server 20, which means that the server 20 can be used as a transparent proxy. Otherwise the processes are as shown in Figure 10 and described above.

Hence, the application 30 is configured to, in response to request data from a client 11, send a new link notification to the event controller. The event controller 24 is configured to send a new link event to the protocol stack 22. The new link event corresponds to the new link notification received from the application 30. The protocol stack 22 is configured to send a SYN to the third-

party server

51, 52, 53. The SYN is at least partly based on the new link event.

The application 30 is configured to set a source IP address of the new link notification to an IP address of the client 11 and to set a source port number of the new link notification to a port number of the client 11.

Figure 13 schematically depicts a further implementation of a server 20 according to an embodiment of the invention. As depicted in Figure 13, in an embodiment the server 20 is connected to a request client 61. In the embodiment shown in Figure 13, the server 20 can function as a firewall. The server 20 is connected between the request client 61 and a third-party server 62. The server 20 functions as a firewall between the request client 61 and the third-party server 62.

Figure 14 schematically depicts a data interaction diagram for a process that can be performed in the network shown in Figure 13. In Figure 14, the “server” on the left hand side is the third-party server 62 shown in Figure 13. In Figure 14, the “client” is the request client 61 shown in Figure 13.

In step 1301, steps 801 to 803 are performed.

In step 1302, the proxy 21 filters the SYN for any attack data. The proxy 21 filters out any attack data and discards it, thereby improving security.

In step 1303, steps 804 to 818 are performed.

In step 1304, the application 30 analyses the request data. The application 30 determines whether or not the request data comprises any SQL-insertion attack. The application 30 evaluates the attack in the request data and then forwards the request data to a REAL server, thereby improving security. The REAL Server is a relational database management system.

In step 1305, steps 813 to 817 are performed.

The server 20 can function as a firewall because the system involves both TCP/IP level and application level operations. Hence, the invention can be used for TCP/IP level security. An embodiment of the invention is expected to make it possible to distinguish whether there is anything suspicious or aggressive in the content of request data. This makes the invention different from normal firewalls which can only provide security at either TCP/IP level or application level (but not both) .

An embodiment of the invention provides a DPDK-based solution for high-concurrency links. An embodiment of the invention relates to an event-based method. An embodiment of the invention comprises a distributed protocol stack. An embodiment of the invention implements separate control data and service data processing technology, thereby realising a high-concurrency server. In particular, link management and service data management are separated. This leads to an improvement in performance.

In an embodiment, in upstream dataflow, a database 25 is used between the protocol stack 22 and the application 30 to store request data. An event management notification system is also added, realising a synchronous operation of the application, making full use of system resources and improving application concurrent processing capabilities.

In downstream dataflow, service data is sent directly to the client, reducing the number of nodes in the data circuit and improving performance.

Optionally, when the proxy 21 is powered on, the proxy 21 reads configuration information into its memory. For example, the configuration information may comprise information about what types of protocol the proxy 21 is configured to support (i.e. which protocols the proxy 21 should accept data packets for, rather than discarding them) , hash functions and the IP addresses of the protocol stack machines 23.

As mentioned above, in an embodiment the proxy 21 uses the DPDK for data transmission. In such an embodiment, when the proxy 21 is powered on, the resources required for the DPDK data transmission are initialised. The resources required for the DPDK data transmission comprise the received data frame address queue and the memory pool in which data packets (e.g. the SYN) are stored before they are extracted for processing.

Optionally, when the protocol stack 22 is powered on, the protocol stack 22 reads configuration information into its memory. The configuration information may comprise information about the maximum size of a queue of SYNs.

Optionally the protocol stack 22 is configured to perform its functions based on open source lightweight Internet Protocol (lwIP) , reusing the reliable TCP/IP transmission mechanism of the lwIP, connecting the low-level data transmission interface to the DPDK date transmission interface.

The lwIP can run with or without the support of the operating system. The key to achieving the lwIP is in maintaining the function of TCP by fundamentally reducing RAM occupancy, and the lwIP requires only a few dozen kB of RAM and 40 kB or so of ROM, making the LwIP stack suitable for use in low-end embedded systems, for example. The lwIP reduces memory use and code size in order to allow its implementation in smaller platforms with limited resources, such as embedded systems. In order to simplify processing and memory requirements, the lwIP cuts down on the API, making it unnecessary to copy some of the data.

However, it is not necessary for the lwIP to be used. The protocol stack procedure performed by the protocol stack 22 may be performed using a different suitable protocol. For example, in an embodiment the kernel protocol stack of Linux is used.

Optionally, the different protocol stack machines 23 are implemented in different pieces of hardware. Optionally, the different protocol stack machines 23 are virtual machines, in which case they may be implemented in a single piece of hardware.

Optionally, the proxy 23, the protocol stack 22, the event controller 24, the database 25 and the application 30 are implemented in different pieces of hardware. Optionally, the proxy 23, the protocol stack 22, the event controller 24, the database 25 and the application 30 are virtual machines, in which case two or more of them may be implemented in a single piece of hardware.

Of course, the proxy 23, the protocol stack 22, the event controller 24, the database 25 and the application 30 may be also implemented by specific logical circuits. In the embodiments of the invention, the methods may be stored in a computer readable storage medium if implemented in the form of a software functional module and sold or used as an independent product. Embodiments of the invention may be embodied in the form of a software product which is stored in storage medium and includes a number of instructions for allowing a computer device (which may be a personal computer, a server, a network device, or the like) to execute all or part of the methods in various embodiments of the disclosure. Possible storage media include a U disk, a mobile hard disk, a ROM, a magnetic disk, an optical disk and the like. Thus, the embodiments of the invention are not limited to any specific combination of hardware and software.

Correspondingly, an embodiment of the invention further provides a non-transient computer readable storage medium. The computer readable storage medium stores computer executable instructions used for executing methods according to an embodiment of the invention.

The above description is for only preferred embodiments of the invention. The description of specific exemplary embodiments is not intended to limit the scope of the claims. Variations and equivalent structures or equivalent flows to the specific embodiments described above are within the scope of the claims.

Claims

A server comprising:

a proxy comprising a network interface controller that is configured to receive data packets from clients, wherein the proxy is configured to copy the data packets from the network interface controller directly into user space；

a protocol stack in user space, wherein the proxy is configured to send the data packets to the protocol stack；

an event controller, wherein the protocol stack is configured to send events to the event controller, each event being at least partly based on information from one of the data packets； and

one or more applications, wherein the event controller is configured to send an event notification batch to one of the one or more applications, wherein each event notification of the event notification batch corresponds to one of the events, wherein said one of the one or more applications is configured to batch process the event notification batch.
The server of claim 1, wherein:

the protocol stack is a distributed protocol stack comprising a plurality of protocol stack machines； and

the proxy is configured to select a protocol stack machine to which to send the data packets.
The server of claim 1 or 2, wherein:

the protocol stack is configured to send acknowledgements directly to the clients bypassing the proxy in response to the data packets received from the clients via the proxy.
The server of any preceding claim, wherein:

each application is configured to determine an event type of the event notifications, wherein when the application determines that the event type is a new link for establishing a new link to a client, the application is configured to send to the event controller an indication of whether or not the application agrees to process that new link； and

the event controller is configured to record for each new link whether or not the application agrees to process that new link.
The server of any preceding claim, wherein:

when the protocol stack receives a data packet comprising request data from a client via the proxy through an established link, the protocol stack is configured to enter the request data from the data packet into a database and to send a data event identifying where the request data can be found in the database to the event controller；

the event controller is configured to send to said one of the one or more applications a data event notification corresponding to the data event to the application, so as to identify where the request data can be found in the database； and

said one of the one or more applications is configured to extract the request data from the database based on the data event notification identifying where the request data can be found in the database.
The server of claim 5, wherein:

the protocol stack is a distributed protocol stack comprising a plurality of protocol stack machines； and

the proxy is configured to determine a protocol stack machine to which to send the data packet comprising request data received through the established link based on information in the data packet such that the proxy assigns the data packet to the same selected protocol stack machine that handled the data packet for establishing the link.
The server of claim 6, wherein:

the proxy is configured to determine the selected protocol stack machine based on an IP address of the client, the IP address of the client being included in both the data packet for establishing the link and the data packet comprising the request data.
The server of any of claims 5 to 7, wherein:

the protocol stack is configured to identify the application, from among others of the applications, to which the event controller is to send the data event notification, based on an IP address of the application included in a session table generated for an established link.
The server of any of claims 5 to 8, wherein:

each application is configured to send response data in response to the request data directly to the client bypassing the proxy, the protocol stack and the event controller.
The server of any of claims 5 to 9, wherein:

each application is configured to analyse the request data and to determine whether the request data comprises an attack.
The server of any preceding claim, wherein:

when the protocol stack receives a data packet for establishing a new link from a client via the proxy, the protocol stack is configured to generate a session table comprising information from the data packet for establishing the new link.
The server of any preceding claim, wherein:

the server is configured to establish a connection to a third-party server that is separate from the proxy；

when the protocol stack receives a data packet comprising third-party request data from the third-party server via the proxy, the protocol stack is configured to enter the third-party request data into a database and to send a data event identifying where the third-party request data can be found in the database from the protocol stack to the event controller； and

the event controller is configured to send to said one of the one or more applications a data event notification corresponding to the data event, so as to identify where the third-party request data can be found in the database； and

said one of the one or more applications is configured to extract the third-party request data from the database based on the data event notification identifying where the third-party request data can be found in the database.
The server of claim 12, wherein:

each application is configured to send data directly to the third-party server bypassing the proxy in response to the third-party request data.
The server of any preceding claim, wherein:

the proxy is configured to filter and discard any attack data from the data packets it receives from the clients before sending the data packets to the protocol stack.
The server of any preceding claim, wherein:

the application is configured to, in response to request data from a client, send a new link notification to the event controller；

the event controller is configured to send a new link event to the protocol stack, the new link event corresponding to the new link notification； and

the protocol stack is configured to send a synchronisation data packet to a third-party server, the synchronisation data packet being at least partly based on the new link event；

wherein the application is configured to set a source IP address of the new link notification to an IP address of the client and to set a source port number of the new link notification to a port number of the client.
The server of any preceding claim, wherein the server is configured to use the Data Plane Development Kit, DPDK, for copying and sending data packets within the server.
The server of any preceding claim, wherein the protocol stack is configured to use Lightweight Internet Protocol, lwIP.
A method comprising:

receiving data packets at a network interface controller of a proxy；

copying the data packets from the network interface controller directly into user space；

sending the data packets to a protocol stack in user space；

sending events from the protocol stack to an event controller, each event being at least partly based on information from one of the data packets；

sending an event notification batch from the event controller to one of one or more applications, each event notification of the event notification batch corresponding to one of the events； and

said one of the one or more applications batch processing the event notification batch.
The method of claim 18, wherein:

the protocol stack is a distributed protocol stack comprising a plurality of protocol stack machines； and

the proxy selects a protocol stack machine to which to send the data packets.
The method of claim 18 or 19, wherein:

the protocol stack sends acknowledgements directly to the clients bypassing the proxy in response to the data packets received from the clients via the proxy.
The method of any of claims 18 to 20, wherein:

each application determines an event type of the event notifications, wherein when the application determines that the event type is a new link for establishing a new link to a client, the application sends to the event controller an indication of whether or not the application agrees to process that new link； and

the event controller records for each new link whether or not the application agrees to process that new link.
The method of any of claims 18 to 21, wherein:

when the protocol stack receives a data packet comprising request data from a client via the proxy through an established link, the protocol stack enters the request data from the data packet into a database and sends a data event identifying where the request data can be found in the database to the event controller；

the event controller sends to said one of the one or more applications a data event notification corresponding to the data event to the application, so as to identify where the request data can be found in the database； and

said one of the one or more applications extracts the request data from the database based on the data event notification identifying where the request data can be found in the database.
The method of claim 22, wherein:

the protocol stack is a distributed protocol stack comprising a plurality of protocol stack machines； and

the proxy determines a protocol stack machine to which to send the data packet comprising request data received through the established link based on information in the data packet such that the proxy assigns the data packet to the same selected protocol stack machine that handled the data packet for establishing the link.
The method of claim 23, wherein:

the proxy determines the selected protocol stack machine based on an IP address of the client, the IP address of the client being included in both the data packet for establishing the link and the data packet comprising the request data.
The method of any of claims 22 to 24, wherein:

the protocol stack identifies the application, from among others of the applications, to which the event controller is to send the data event notification, based on an IP address of the application included in a session table generated for an established link.
The method of any of claims 22 to 25, wherein:

each application sends response data in response to the request data directly to the client bypassing the proxy, the protocol stack and the event controller.
The method of any of claims 22 to 26, wherein:

each application analyses the request data and determines whether the request data comprises an attack.
The method of any of claims 18 to 27, wherein:

when the protocol stack receives a data packet for establishing a new link from a client via the proxy, the protocol stack generates a session table comprising information from the data packet for establishing the new link.
The method of any of claims 18 to 28, wherein:

the server establishes a connection to a third-party server that is separate from the proxy；

when the protocol stack receives a data packet comprising third-party request data from the third-party server via the proxy, the protocol stack enters the third-party request data into a database and sends a data event identifying where the third-party request data can be found in the database from the protocol stack to the event controller； and

the event controller sends to said one of the one or more applications a data event notification corresponding to the data event, so as to identify where the third-party request data can be found in the database； and

said one of the one or more applications extracts the third-party request data from the database based on the data event notification identifying where the third-party request data can be found in the database.
The method of claim 29, wherein:

each application sends data directly to the third-party server bypassing the proxy in response to the third-party request data.
The method of any of claims 18 to 30, wherein:

the proxy filters and discards any attack data from the data packets it receives from the clients before sending the data packets to the protocol stack.
The method of any of claims 18 to 31, wherein:

the application, in response to request data from a client, sends a new link notification to the event controller；

the event controller sends a new link event to the protocol stack, the new link event corresponding to the new link notification； and

the protocol stack sends a synchronisation data packet to a third-party server, the synchronisation data packet being at least partly based on the new link event；

wherein the application sets a source IP address of the new link notification to an IP address of the client and sets a source port number of the new link notification to a port number of the client.
The method of any of claims 18 to 32, wherein the server uses the Data Plane Development Kit, DPDK, for copying and sending data packets within the server.
The method of any of claims 18 to 33, wherein the protocol stack uses Lightweight Internet Protocol, lwIP.