Programmatic determination of next-hop MAC address

Abstract

The system, media, and method can be used by a network acceleration application to determine layer 2 destination addresses that can be populated with data packets transmitted using accelerated networking techniques. The system and method provide a software application that runs on a computing device that controls a NIC interface to provide accelerated networking. The software application resides in the application layer of the network stack and interfaces with the kernel, network stack, and operating system (OS) functions via a virtual NIC or TUN / TAP device to determine layer 2 destination addresses for use by the accelerated network application. In combination, embodiments herein can describe firewall rules, static ARP entries, or other system administrator rules deployed for network operation.

Description

[Technical Field]

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 111,487, filed November 9, 2020, which is incorporated by reference herein in its entirety.

[0002] This application relates generally to routing data packets through a network and to routing such packets in an accelerated manner. [Background technology]

[0003] In a typical network environment, a client device requests and downloads content stored on a network server. The request is sent to the network server using routers, gateways, and other network infrastructure devices that send the request as packets over the network to the network server. Upon receiving the content request, the network server typically retrieves the requested content, divides the requested content into packets, and sends the packets to the requesting client device. The routers, gateways, and other network infrastructure then send these packets over the network to the client device. The client device, in turn, reassembles the content from the packets and presents the content to the user via an application on the client device.

[0004] The exchange of data between various devices may be performed according to a set of communication protocols. A communication protocol is a set of rules that defines the syntax, semantics, and synchronization of communication between devices and may be implemented as hardware and / or software. In protocol design, protocols are layered to form a protocol stack, with each layer provided to solve a class of communication problem. Exemplary protocol stacks include, but are not limited to, network stacks such as the Internet Protocol Suite (e.g., the TCP / IP protocol suite), the Internet Model, the TCP / IP 5-Layer Reference Model, the TCP / IP Model, the ARPA Network Reference Model, and the Open Systems Interconnection Model (OSI Model). Another example of a network stack is the network stack included in the Linux® operating system, which is a seven-layer stack, similar to the OSI model. The Linux® network stack is comprised of an application layer (e.g., layer 7), a system call interface layer (e.g., layer 6), a protocol-independent interface layer (e.g., layer 5), a network protocol layer (e.g., layer 4), a device-independent layer (e.g., layer 3), a device driver layer (e.g., layer 2), and a physical hardware layer (e.g., layer 1). The application layer may define the user space, and layers 2 through 6 may be implemented in the kernel.

[0005] FIG. 1 illustrates a schematic, exemplary flow diagram showing a software application 110 constructing and traversing a datagram packet (UDP) 120 through a network stack 130. The application may be installed on a computing device (e.g., computing device 500 of FIG. 5) and run under an operating system (e.g., Linux, Windows, macOS) that includes a kernel 140. The software application 110 may be configured to make system calls (e.g., layer 6 of the network stack 130) using a sockets application programming interface (API) (e.g., layer 5). The application 110 may also provide information to layer 7 and information required by layers 3 and 4 (e.g., destination Internet Protocol (IP) and destination UDP port). The network stack 130, in conjunction with the kernel 140, may be implemented to provide the remaining information to populate layers 2 through 4.

[0006] In step 1, an application 110 at the application layer creates a socket for sending UDP 120. For example, the application 110 generates a payload containing a request for data and populates the protocol header with a destination (DST) IP address and a DST port (shown in green). The remaining protocol headers are typically populated by the kernel 140 through one or more layers of the network stack in 150. The application makes the request to the kernel 140 through a socket API, for example, through the system call interface layer. The remaining layers of the network stack are configured to resolve the protocol header based on routing rules (such as network rules, security, or firewall measures) and populate the protocol header with a source (SRC) MAC address, SRC IP address, and SRC port (shown in green in step 2). However, the DST MAC address (e.g., the layer 2 destination address) is determined by layer 2 of the network stack (e.g., the device driver layer) through a resolution procedure protocol. The resolution procedure 160 may be implemented based on Request for Comments (RFC) standards, such as RFC 6747, RFC 826, and RFC 6575. An exemplary resolution procedure 160 may include accessing an Address Resolution Protocol (ARP) database 162 (e.g., a cache or other temporary data storage medium) that stores layer 2 destination addresses according to DST IP addresses based on network rules. For example, the ARP database 162 stores DST MAC addresses of next-hop destination addresses (e.g., switching elements, routers, gateways, etc.) used to send data packets to the DST IP addresses. The next-hop MAC addresses may be defined based on a predetermined rule set that describes routing rules, such as network rules, security measures, and / or firewall measures. These rules may be predefined by a network / system administrator.If the DST MAC address is in the ARP database for the DST IP address, layer 2 of the network stack populates the resolved DST destination address (e.g., the DST MAC address) into a layer 2 protocol header. Otherwise, layer 2 performs an ARP resolution exchange 164, which includes sending an ARP request packet based on the DST IP address and any network administrator rules that may be in place. The destination device responds to the ARP request with an ARP reply packet containing the DST destination address. Layer 2 then populates the layer 2 protocol header with the DST destination address and stores the DST destination address in the ARP database for use in subsequent steps. In step 3, UDP 120 is completed with each protocol header populated (as shown in green), and UDP 120 is provided to the network interface controller (NIC) for transmission over the network by the physical layer (which may be referred to herein as the NIC or NIC TX).

[0007] Networks can experience a variety of issues that affect the speed at which data is exchanged (e.g., upload and / or download speeds) over the network. These issues include the time it takes to populate each protocol header or a large number of requests, which slows down the speed at which data is uploaded and / or downloaded. To increase transmission speeds and reduce latency, network acceleration techniques can be employed by devices throughout the network (e.g., client devices, network servers, and / or intermediate network devices such as routers and gateways located between client devices and servers). These network acceleration techniques can be implemented as software and / or hardware and are used to increase the speed at which data flows between client devices and network servers. These techniques can address the issues described above or other issues that adversely affect data exchange speeds.

[0008] An exemplary network acceleration technique is to provide a software application that is installed on a client device and configured to bypass the network stack. The application is configured to populate protocol headers at the application layer, thereby directly managing packet flow to the network. That is, instructions within the application can be executed to programmatically populate one or more protocol headers. Examples of network acceleration applications include Data Plane Development Kit (DPDK), PFRING_ZC, and NETMAP.

[0009] Figure 2 shows a schematic flow diagram of a network acceleration application. Similar to Figure 1, Figure 2 shows an application 210 and a network stack 130 included in an operating system. The network stack 130 may be the same as or substantially similar to the network stack 130 of Figure 1. However, the application 210 at the application layer is configured to directly control the NIC, rather than being controlled by the kernel 140 as described above in Figure 1. This modification allows the application 210 to bypass the network stack 130 and directly send packets over the network at an accelerated rate.

[0010] As a result of bypassing the network stack 130 (also known as “kernel bypass”), the application 210 must populate the protocol headers of each packet (e.g., UDP 220) for transmission over the network. However, challenges arise because there are many network protocols, Request for Comments (RFCs), and standards that applications must implement to properly populate the second and third protocol headers in order to participate in layer 2 / 3 switched networks. One example approach is to use DPDK, which provides libraries to accelerate packet processing, facilitating the population of the SRC MAC address, SRS IP address, and SRC port (as shown in orange in FIG. 1 and green in FIG. 2). One example approach used by DPDK is to use virtual network interface controllers (VNICs) to provide an interface within the kernel to NICs currently controlled by applications. DPDK provides the VNIC concept (KNI) to enable network interfaces integrated into network stacks such as Linux. Implementing a VNIC therefore provides an interface for the kernel to send packets to a physical / real NIC controlled by the application. Thus, application 210 may participate in network functions (e.g., ARP resolution, DNS, PING / ICMP, etc.). These network functions are procedures that nodes participating in the network must perform. For example, when a server receives a "ping" packet (a type of ICMP), the server must respond with a specific type of packet that contains predetermined expected content. ARP resolution is another example of a network function / procedure. These procedures for these different types of functions are defined in various RFCs, but are also subject to system administrator policies (e.g., a system administrator may enable a policy that restricts servers from responding to ICMP (ping packets)).Further examples of virtual NICs include, but are not limited to, TUN / TAP virtual NICs. Embodiments herein are not limited to the listed NICs, but encompass any NIC (virtual or non-virtual) that can be directly controlled by application 210, thereby bypassing other layers of network stack 130.

[0011] However, there is no way to programmatically determine the destination MAC address via software implementation, as is done in switched and routed networks, without re-implementing network stack functions for each packet (thus reinventing the wheel every time). Thus, in the case of fast path (e.g., network path bypass), even if the application 210 utilizes the VNIC described above that provides a kernel interface as outlined above, without the facility of network functions performed by the operating system, the application 210 cannot determine the layer 2 destination MAC address (e.g., the next-hop MAC address).

[0012] For example, in Linux®, the network stack does not have an API to programmatically query what the layer 2 destination address should be. Therefore, an application 210 cannot query this address and instead must proceed through the network stack as outlined in FIG. 1. In other words, there is no way to integrate a KNI / virtual interface with the network stack that bypasses any kind of network stack API call. Therefore, the only way to ask for an ARP request in Linux® is to create a socket and request that an IP packet be sent according to the process described above in connection with FIG. 1. This causes ARP resolution 160 (FIG. 1) to occur (if necessary).

[0013] Even if such an API exists in an operating system (such as Windows®), the API does not address whether ARP needs to be requested or not. This is because various network rules, security, or firewall measures may have been put in place by the network / system administrator, which may result in different responses. Therefore, if an application decides to "hard-code" or somehow pre-populate the destination MAC address, it effectively bypasses any security or firewall measures (which the network stack applies based on network rules) that may have been put in place by the network / system administrator. Summary of the Invention

[0014] The following summary is not intended to define all aspects of the invention; other features and advantages of the present disclosure will become apparent from the following detailed description, including the drawings. This disclosure is intended to be linked as an integrated document, and it should be understood that all combinations of features described herein are contemplated, even if the combinations of features are not found together in the same sentence or paragraph or section of the disclosure. Furthermore, the present disclosure includes, as an additional aspect, all embodiments of the invention that are narrower in scope in any respect than the variations specifically mentioned herein.

[0015] Accordingly, embodiments disclosed herein address these problems by providing systems, media, and methods that can be used by network acceleration applications to determine layer 2 destination addresses that can populate data packets transmitted using accelerated networking techniques. Various embodiments described herein provide a software application that executes on a computing device that controls a NIC interface to provide accelerated networking. The software application resides at the application layer of the network stack and interfaces with the kernel, network stack, and operating system (OS) functions via a virtual NIC or TUN / TAP device to determine layer 2 destination addresses for use by the accelerated network application. In combination, embodiments herein can account for firewall rules, static ARP entries, or other system administrator rules that have been put in place for network operation. For example, a virtual NIC interface (such as DPDK's KNI, TUN / TAP virtual NIC, or post-routing rules provided by iptables or netfilter), controlled by a software application that interfaces with the kernel and network stack and OS functions through a virtual NIC or TUN / TAP device, determines the next-hop MAC address, stores the resolved MAC address in a database, and uses the stored MAC address to populate the layer 2 header of data packets, accelerating the transmission of subsequent packets.

[0016] An embodiment includes a method for accelerating transmission of packets by an application at an application layer in a system having a kernel with a protocol stack by programmatically determining at least one next-hop MAC address for packets to be transmitted within a network. Such a method includes creating a phantom datagram (UDP) having a protocol header, populating one or more protocol headers of the phantom UDP while leaving a next-hop MAC address header unpopulated, submitting the phantom UDP to the kernel for traversing the protocol stack, receiving the phantom UDP from the kernel with the next-hop MAC address header populated by the kernel, recognizing the phantom UDP based on one or more predetermined characteristics, storing the next-hop MAC address header from the phantom UDP, and not transmitting the phantom UDP.

[0017] Such a method also includes creating a next UDP, obtaining the stored next hop MAC address, and populating a header of the next UDP with the obtained next hop MAC address.

[0018] Additionally, the kernel's protocol stack determines the next hop MAC address header based on a predetermined rule set describing routing rules, the predetermined rule set describing one or more of network rules, security measures, and firewall measures.

[0019] Additionally, if the application controls the NIC, such a method can further instruct the NIC to drop the phantom UDP. Such a method can further bypass the kernel and populate the next UDP with a stored next-hop MAC address header and provide the next UDP to the NIC.

[0020] Further, such a method creates a socket using bind and connect calls with the kernel, obtains and stores the source IP and source destination from a phantom UDP populated by the kernel, and populates the header of the next UDP with the stored source IP and source destination.

[0021] Embodiments also include a method for programmatically determining at least one layer 2 destination address of packets sent within a network by an application at an application layer in a system having a kernel, such a method operates by creating a phantom packet, leaving the layer 2 destination address unpopulated and populating one or more of the phantom packet's protocol headers, submitting the phantom packet to the kernel, receiving the phantom packet from the kernel with the layer 2 destination address header populated by the kernel, recognizing the phantom packet, storing the layer 2 destination address from the phantom packet, creating a next packet, and populating the next packet's header with the stored layer 2 destination address.

[0022] Embodiments further include a system for accelerating transmission of packets over a network by programmatically determining a layer 2 destination address, such a system including at least one processor and a memory in communication with the at least one processor that stores instructions that, when executed by the at least one processor, cause the at least one processor to perform one or more of the methods described above.

[0023] Details of embodiments of the present disclosure, both as to their structure and operation, can be gleaned in part from study of the accompanying drawings, in which like reference numerals refer to like parts and / or functions. [Brief explanation of the drawings]

[0024] [Figure 1]1 shows a high-level functional flow diagram of a software application for building and sending datagram packets (UDP) through a network stack. [Figure 2] 1 shows a schematic functional flow diagram of a network acceleration application. [Figure 3A] 1 shows a schematic functional flow diagram of a network acceleration application. [Figure 3B] 1 shows a schematic functional flow diagram of a network acceleration application. [Figure 4] FIG. 1 is a functional block diagram of an infrastructure in which embodiments of the disclosed systems, methods, and media may operate, according to embodiments disclosed herein. [Figure 5] FIG. 1 is a functional block diagram illustrating an example of a wired or wireless processing system that may be used in connection with various embodiments described herein. DETAILED DESCRIPTION OF THE INVENTION

[0025] 3A and 3B illustrate a general functional flow diagram of a network acceleration application 310 configured to determine a layer 2 DST address according to embodiments disclosed herein. Similar to FIG. 2, FIG. 3 illustrates an application 310 and a network stack 130 included in an operating system. The network stack 130 may be substantially similar to the network stack 130 of FIG. 1. The application 310 may be similar to the application 210 of FIG. 2 in that it resides at the application layer of the network stack 130 and is configured to directly control the NIC (the NIC is illustratively shown within the application 310) to accelerate data packet exchanges. Thus, similar to the application 210, the application 310 can directly transmit data packets, bypassing the kernel 140 and the layers of the network stack implemented thereby.

[0026] Application 310 is also configured to determine a layer 2 DST address for use in the accelerated transmission of the packet. For example, application 310 is configured to utilize kernel 140 and network stack 130 to determine the layer 2 DST address and store the layer 2 DST address in ARP database 362 (e.g., an ARP cache or other temporary data storage medium). The layer 2 DST address can then be programmatically obtained by application 310 and used to programmatically populate the layer 2 header of accelerated UDP 420 (as shown in FIG. 3B). UDP 420 can be substantially similar to UDP 220 of FIG. 2 in that both UDPs are accelerated packets directly controlled and transmitted by the respective applications.

[0027] For example, in step 1 (indicated by the large number 1), application 310 is configured to create and creates a phantom packet, such as phantom UDP 320. In one embodiment, the payload of phantom UDP 320 is populated with a unique identifier (UID). The UID can be any globally unique identifier (GUID) that can uniquely identify phantom UDP 320. For example, in some embodiments, the UID may be a 64-bit pseudo-random value. However, the UID can be any bit length and can be pseudo-random, random, or non-random as desired by the operator. Alternatively, other methods for application 310 to recognize phantom UDP 320 can be used. For example, if application 310 is sending only accelerated packets, all UDPs from the kernel must be phantom UDPs. As yet another example, the source IP in the phantom UDP's header can be set to a predefined address. More generally, any criterion or set of criteria known to application 310 as indicating a phantom UDP 320 can be used.

[0028] Phantom UDP 320 is used to resolve the layer 2 DST address before creating an accelerated UDP (e.g., UDP220 and / or UDP420) for transmission over the network. Application 310 can populate one or more protocol headers as described above in connection with FIG. 2. Alternatively, one or more protocol headers of phantom UDP 320 are left unpopulated. In particular, layer 2 header 324 is not populated because it cannot be programmatically determined. FIG. 3A shows that application 310 has populated all headers except for header 324 (DST MAC, shown in bold). Once phantom UDP 320 is created, it is socketed or submitted to kernel 140 as described above in connection with FIG. 1.

[0029] In step 2 (indicated by the large numeral 2), any protocol headers not populated by application 310 at the application layer are resolved, e.g., populated by kernel 140, as described above in connection with FIG. 1. Specifically, because layer 2 header 324 is not populated, layer 150 within the kernel (e.g., the device driver layer or layer 2 of network stack 130) resolves the layer 2 DST address. For example, layer 2 of network stack 130 performs resolution process 360, which may be the same as or substantially similar to resolution process 160 described above. As phantom UDP 320 traverses network stack 130, any security measures, firewall measures, and / or routing rules are applied to the information populated by the network stack. Thus, phantom UDP 320 takes such measures into account and does not circumvent security protocols in place.

[0030] For example, the resolution procedure 360 ​​may include accessing an Address Resolution Protocol (ARP) database 362 (e.g., a cache or other temporary data storage medium) that stores layer 2 destination addresses according to the DST IP address according to network rules. For example, the ARP database 362 stores the DST MAC address of the next-hop destination address (e.g., a switching element, router, gateway, etc.) used to send the data packet to the DST IP address. The next-hop MAC address may be based on a predefined rule set that describes routing rules, such as network rules, security measures, and / or firewall measures. These rules may be predefined by a network / system administrator. If the DST MAC address is in the APP database 362 of DST IP addresses populated in the phantom UDP 320, the network stack 130 populates the resolved DST MAC address into the layer 2 protocol header. Otherwise, an ARP resolution exchange 364 (which may be similar to exchange 164) is performed. Similar to exchange 164, ARP resolution exchange 364 includes layer 2 of the network stack that sends ARP request packets based on the DST IP address in place and network administrator rules. The destination device responds to the ARP request with an ARP reply packet that includes the DST MAC address of the next-hop destination device. In step 3, the network stack (e.g., the device driver layer or layer 2) populates layer 2 protocol header 324 with the DST MAC address.

[0031] In step 3 (indicated by the large numeral 3), the phantom UDP 320 is provided to a virtual NIC (e.g., NIC TX). An application 310 controlling the virtual NIC is configured to recognize the UID in the payload 322 and recognize the packet as a phantom UDP based on the UID recognition. The application 310 may include a set of rules that are applied to the payload to recognize the UID and thus recognize the UDP as a phantom UDP. Once the phantom UDP 320 is recognized, the application 310 extracts associated protocol header information, e.g., information that the application was not able to pre-populate in step 1, and stores the extracted information in a data storage device 370. For example, in step 4 (indicated by the large numeral 4), the application 310 extracts a layer 2 DST address from the layer 2 header 324 of the phantom UDP 320 and stores the layer 2 DST address in a data storage device 370. In some embodiments, the data storage device 370 is a cache memory or other temporary storage medium.

[0032] Also, in step 4, the virtual NIC and / or actual NIC (commonly referred to as NIC) under the control of application 310 determines whether to submit the given UDP to the physical layer for transmission. For example, application 310 recognizes the packet as phantom UDP 320 based on the UID in the payload, and the virtual NIC determines that phantom UDP 320 should not be transmitted over the network and is dropped.

[0033] Once the information is stored in data storage device 370, the information can be used to programmatically populate the protocol headers of the UDP to accelerate transmission. For example, as shown in FIG. 3B, application 310 creates accelerated UDP 420 and populates each protocol header, including the layer 2 header, by retrieving the relevant information from data storage device 370. UDP 420 and application 310 at step 5 (indicated by the large numeral 5) can be similar to UDP 220 and application 210 of FIG. 2, except that the layer 2 headers are also populated by application 310. Application 310 can continuously transmit packets at a high data rate, completely bypassing kernel 140 and the layers of network stack 130 implemented thereby.

[0034] A non-limiting advantage of the embodiments described herein is that the application 310 can determine the next-hop MAC address by utilizing any firewall rules / measures, IP table functions, ARP resolution procedures, or any other configurations populated by a network / system administrator without unnecessarily sending data packets over the network. Unnecessary packets slow down the data exchange rate / speed because each packet, whether necessary or not, requires network resources for transmission. In other words, the embodiments described herein can overcome the shortcomings of APIs present in the OS to determine the next-hop MAC address. Similarly, even if an API exists, the embodiments described herein can account for security measures implemented by a network / system administrator.

[0035] Such network stack (kernel) bypasses (such as those using dpdk) along with other applications that use the kernel network stack must ensure that connections established by the kernel bypass solution do not interfere with "normal" network stack connections. One potential contention area is the layer 4 ports used in socket connections, such as UDP and TCP sockets. The following example embodiment describes how network stacks (such as BSD and Linux) reserve ports used in both server and client connections, and how this conflicts with kernel bypass solutions. In this example, the method used to "reserve" a port used in socket communication is to call bind().

[0036] When a connection is established, the operating system must select an unused source port number. For example, Linux, by default, selects a port from the ephemeral port range, which is set to the range 32768-61000 (28K of ports to choose from). In Linux, the ephemeral port range is a global resource. In practice, port numbers are 16 bits long, which allows the port range to extend to 64K of possible choices. Using multiple destination addresses, a nearly unlimited number of connections can be established. However, attempting to establish more than 64K simultaneous connections (28K with the default ephemeral port range) to a single (destination IP, destination port) pair will fail.

[0037] You can ask the kernel to select a specific source IP and port by calling bind() before calling connect(), for example: s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)# Let the source address be 192.168.1.21:1234. s.bind((“192.168.1.21”,1234)) s.connect((www.google.com,80))

[0038] This approach is often called "bind before connect". Specifying a port number of 0 means that the kernel must handle the port allocation for the requesting application. For example: s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.bind((“192.168.1.21”,0)) s.connect((www.google.com,80))

[0039] This method is well known, but there is a catch: because bind is usually called to listen on a socket, the kernel needs to make sure that the source address is not shared with other users. That's a problem. When using this technique in this form, it is impossible to establish more than 64k total outgoing connections (the ephemeral port range). Any subsequent attempts to call bind() will fail with an EADDRINUSE error, i.e., all source ports are busy.

[0040] To overcome this catch, an application can use the SO_REUSEADDR setting. By setting SO_REUSEADDR, the application informs the kernel of its intention to share the bound port with other users, but only if the sharing does not cause a conflict at the protocol layer.

[0041] Below is an example of usage. s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1) s.bind(( “192.168.1.21”,0)) s.connect((www.google.com,80))

[0042] In this example, the kernel will find a port that does not directly conflict with other sockets, but in contrast to the absence of SO_REUSEADDR setting, ports in TIME_WAIT and ports used by already established connections may be reused. Thus, by setting the SO_REUSEADDR flag, you can have more than 64k (the ephemeral port range) outgoing connections to multiple destinations from one IP of your choice.

[0043] But there's another catch: when an application calls bind(), the kernel only knows the source address the application is requesting. The application only tells the kernel the destination address when it later calls connect(). This can cause problems, because the kernel might reuse a source port already used in another connection to the same destination the application wants to use. In such cases, connect() will fail with the EADDRNOTAVAIL error.

[0044] When an application wants to establish more than 64k connections (the ephemeral port range) to a single destination, it must use all of the approaches mentioned above. Tweak your kernel parameters to increase the ephemeral port range. Use bind before connect and manually specify many source IP addresses. Set the SO_REUSEADDR flag on the outgoing connection. Check for EADDRINUSE errors in bind() in case the kernel runs out of available ports. If there is a connection conflict, check connect() for an EADDRNOTAVAIL error and retry if necessary.

[0045] Unfortunately, connections established with regular connect() and connections established with bind-before-connect do not mix well. Outgoing ports used with one technique are not reused with another. Establishing 64k connections using connect() will cause bind() to fail with EADDRINUSE. Conversely, if thousands of connections are using bind before connect, straight connects may fail with EADDRNOTAVAIL.

[0046] In systems where other applications do not use bind-before-connect, the aforementioned bind-before-connect approach to reserving ephemeral ports may conflict with such applications. Therefore, the application 310 uses the network stack to create a socket using the normal bind / connect calls made to socket connections, and then sends a phantom UDP through the kernel 140 and network stack 150 layers in a manner similar to that described above. The application remembers the source port and, optionally, the source IP from the phantom UDP's header and uses them for subsequent kernel bypass packets. A single phantom UDP 320 can be used to obtain the DST MAC address and source port (and, optionally, the source IP), or a separate phantom UDP can be used.

[0047] The application recognizes the phantom UDP when it returns it to the NIC using the above techniques. The NIC drops the phantom UDP and does not transmit it. Furthermore, the application 310 must keep the socket open during the kernel bypass packet transmission to keep the port allocation "reserved." For example, the application does not close the socket until the period of the kernel bypass packet transmission has ended.

[0048] While embodiments herein are described with reference to the network stack included in the Linux® OS, it is understood that embodiments are not limited to the Linux® network stack and may be equally applicable to network stacks included in other operating systems (e.g., macOS®, Windows®, etc.). Furthermore, embodiments herein are also not limited to the seven-layer protocol stack described herein and apply equally to other protocol stacks, such as the Internet Protocol Suite (e.g., the TCP / IP protocol suite), the Internet model, the TCP / IP five-layer reference model, the TCP / IP model, the ARPANET reference model, the Open Systems Interconnection model (OSI model), etc.

[0049] 4 illustrates a functional block diagram of an infrastructure in which embodiments of the disclosed system, method, and media may operate, according to embodiments disclosed herein. The infrastructure may include a client computing device 410 with application(s) 412 (e.g., application 310), data storage device(s) 414, and a network stack 416. The computing device 410 may be communicatively connected to one or more network nodes 430 for transmitting data packets from the computing device 410 to network server(s) 450 and / or one or more network server(s) 450 via one or more networks 420.

[0050] The computing device(s) 410 and the network server 450 may include any type of computing device capable of wired and / or wireless communication, including, but not limited to, desktop computers, laptop computers, tablet computers, smartphones or other mobile phones, servers, game consoles, televisions, set-top boxes, and electronic kiosks. Similarly, the node(s) 430 may include any type of computing device capable of wired and / or wireless communication. The node(s) 430 may be implemented as any hardware device that acts as a gate between networks, forming a link through which data flows from one computing device to another, for example, by routing or transmitting data packets from a packet source device (e.g., the computing device 410) to a destination device (e.g., the network server 450) or vice versa. The node(s) 430 may be implemented as a router, firewall, server, hub, gateway, or any device that allows traffic to enter and exit a network. Furthermore, each node 430 may be communicatively connected to one or more devices and / or other nodes 430. It is understood that the infrastructure may include any number of gateway(s), device(s), user system(s), platform(s), set of server(s), and database(s). An exemplary wired or wireless system that may be implemented as computing device 410 and network server 450 is shown as wired or wireless system 500 in FIG.

[0051] The application(s) 412 and the network stack 416 are stored as instructions in the data storage device(s) 414 and executed by the computing device 410 to perform functions thereon. As described above, the network stack 416 includes a kernel included in an operating system executed by the computing device 410. The network stack 416 may be similar to the network stack 430 described above in connection with FIGS. 1-3B or may be similar to any other type of communication protocol stack. The application(s) 412 may be one or more of the application 410, the application 210, and / or the application 310. For example, the application 310 may be installed on the computing device 410 as one of the application(s) 414 and executed for the accelerated networking application for high data rate transmission described in connection with FIGS. 3A and 3B. Accordingly, the computing device 410 may transmit data packets to the network server(s) 450 as described herein in connection with FIGS. 3A and 3B.

[0052] Network(s) 420 may include the Internet, and server(s) 450 may communicate with nodes 430 and computing devices 410 over the Internet using standard transmission protocols such as Hypertext Transfer Protocol (HTTP), Secure HTTP (HTTPS), File Transfer Protocol, FTP Secure (FTPS), SSH FTP (SFTP), and other proprietary protocols. Although platform 410 is shown as connected to various systems through a single set of network(s) 420, it will be understood that platform 410 may be connected to various systems through a different set of one or more networks.

[0053] Network server(s) 450 may include web servers that host one or more websites, web services, and / or web content. In embodiments in which a website is provided, the website may include one or more user interfaces, including, for example, web pages generated in Hypertext Markup Language (HTML) or other languages ​​(e.g., graphics-based and / or text-based languages). Network server(s) 450 transmit or provide these user interfaces in response to requests from computing device 410. Data requests and responses to network server(s) 450 may be communicated over network(s) 420, which may include the Internet, using standard communication protocols (e.g., HTTP, HTTPS). Responses and requests may be received by communication node 430 and routed by communication node 430 to network server 450 according to routing rules. The routing rules may be referenced, for example, when populating protocol headers of data packets, as described above.

[0054] Computing device 410 may request content and data from network server(s) 450. The requests may be sent in the form of data packets and are sent to network server(s) 450 using node(s) 430, which transmit the requests as packets over network 420. Upon receiving the request packets, network server(s) typically obtains the requested content, divides the requested content into packets, and transmits the packets to the requesting client device 410. Node(s) 430 transmits these packets over the network to client device 410.

[0055] Exemplary platforms that may include the components shown in FIG. 4 include, but are not limited to, Channelizer®, Combiner®, quantumRadio®, quantumRX Wideband Software Receiver®, DataDefender®, and similar products offered by Kratos Defence & Security Solutions, Inc. Such products may be implemented to achieve high data rates and small packet size transfers by utilizing embodiments disclosed herein. For example, a system herein may achieve packet transmission rates of 3 Gbps or greater using a maximum transmission unit (MTU) for each packet that may be 1500 bytes. However, it is understood that other platforms from other manufacturers may also utilize embodiments herein to achieve accelerated data transmission rates with small packet sizes.

[0056] FIG. 5 is a functional block diagram illustrating an example of a wired or wireless processing system 500 that may be used in connection with various embodiments described herein. For example, system 500 may be used as or in conjunction with one or more of the mechanisms, processes, methods, or functions described above (e.g., storing and / or executing one or more software modules) and may represent components of computing device 410, server(s) 450, communication node(s) 430, and / or other devices described herein. System 500 may be a server or any conventional personal computer, or any other processor-enabled device capable of wired or wireless data communication. As will be apparent to those skilled in the art, other computer systems and / or architectures may also be used. Furthermore, while system 500 is illustrated with certain elements, it is understood that it may include fewer or more elements than those shown, depending on the specific components it represents. For example, a system 500 without wireless communication capabilities may not include baseband 560, radio 565, and antenna 570.

[0057] System 500 preferably includes one or more processors, such as processor 510. Additional processors may be provided, such as auxiliary processors for managing input / output, auxiliary processors for performing floating-point mathematical operations, dedicated microprocessors (e.g., digital signal processors) with architectures suitable for high-speed execution of signal processing algorithms, slave processors (e.g., back-end processors) subordinate to the main processing system, additional microprocessors or controllers for dual or multiprocessor systems, or coprocessors. Such auxiliary processors may be discrete processors or may be integrated with processor 510. Examples of processors for use with system 500 include, but are not limited to, Pentium® processors, Core i7® processors, Xeon® processors, and other models available from Intel Corporation of Santa Clara, California, and hardware processors from other manufacturers, such as Advanced Micro Devices of Sunnyvale, California.

[0058] The processor 510 is preferably connected to a communication bus 505. The communication bus 505 may include a data channel that facilitates information transfer between storage and other peripheral components of the system 500. Additionally, the communication bus 505 may provide a set of signals used to communicate with the processor 510, including a data bus, an address bus, and a control bus (not shown). The communication bus 505 may include any standard or non-standard bus architecture, such as the Industry Standard Architecture (ISA), the Extended Industry Standard Architecture (EISA), the MicroChannel Architecture (MCA), a Peripheral Component Interconnect (PCI) local bus, or a bus architecture conforming to a standard promulgated by the Institute of Electrical and Electronics Engineers (IEEE), including IEEE 488 General Purpose Interface Bus (GPIB), IEEE 696 / S-100, etc.

[0059] System 500 preferably includes a main memory 515 and may also include a secondary memory 520. Main memory 515 is a non-transitory computer-readable medium that provides storage of instructions and data for programs executed on processor 510, such as one or more of the functions and / or modules discussed above and illustrated in at least FIGS. 1-3B. It is understood that the programs stored in memory and executed by processor 510 may be written and / or compiled according to any suitable language, including, but not limited to, C / C++, Java, JavaScript, Perl, Visual Basic.NET, proprietary visual scripting languages, proprietary scripting languages, etc. Main memory 515 is typically semiconductor-based memory, such as dynamic random access memory (DRAM) and / or static random access memory (SRAM). Other semiconductor-based memory types include, for example, synchronous dynamic random access memory (SDRAM), including read-only memory (ROM), Rambus dynamic random access memory (RDRAM), ferroelectric random access memory (FRAM), etc.

[0060] Secondary memory 520 may optionally include internal memory 525 and / or removable media 530, such as a floppy disk drive, magnetic tape drive, compact disk (CD) drive, digital versatile disk (DVD) drive, other optical drive, flash memory drive, microSD, etc. Removable media 530 may be read and / or written in a well-known manner. Removable storage media 530 may be, for example, a floppy disk, magnetic tape, CD, DVD, SD card, thumb drive, etc.

[0061] The removable storage medium 530 is a non-transitory computer-readable medium that stores computer-executable code (i.e., software) and / or data. The computer software or data stored on the removable storage medium 530 is loaded into the system 500 for execution by the processor 510.

[0062] In alternative embodiments, secondary memory 520 may include other similar means for allowing computer programs or other data or instructions to be loaded into system 500. Such means may include, for example, external storage medium 595 and interface 540. Examples of external storage medium 595 may include an external hard disk drive, an external optical drive, or an external magneto-optical drive.

[0063] Other examples of secondary memory 520 may include semiconductor-based memory such as programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), or flash memory (a block-oriented memory similar to EEPROM), as well as any other removable storage medium 530 and communication interface 540 that allow software and data to be transferred from external media 560 to system 500.

[0064] System 500 may include a communications interface 540. Communications interface 540 allows software and data to be transferred between system 500 and an external device (e.g., a printer), a network, or an information source. For example, computer software or executable code may be transferred to system 500 from a network or a cloud server via communications interface 540. Examples of communications interface 540 include a built-in network adapter, a network interface card (NIC), a Personal Computer Memory Card International Association (PCMCIA) network card, a cardbus network adapter, a wireless network adapter, a universal serial bus (USB) network adapter, a modem, a network interface card (NIC), a wireless data card, a communications port, an infrared interface, an IEEE 1394 Firewire, or any other device capable of interfacing system 500 with a network or another computing device.

[0065] Communications interface 540 preferably implements industry-promulgated protocol standards such as the Ethernet IEEE 802 standard, Fibre Channel, Digital Subscriber Line (DSL), Asymmetric Digital Subscriber Line (ADSL), Frame Relay, Asynchronous Transfer Mode, Integrated Services Digital Network (ISDN), Personal Communications Services (PCS), Transmission Control Protocol / Internet Protocol (TCP / IP), Serial Line Internet Protocol / Point-to-Point Protocol (SLIP / PPP), and may also implement customized or non-standard interface protocols.

[0066] The software and data transferred via communications interface 540 are typically in the form of electrical communications signals 555. These signals 555 are preferably provided to communications interface 540 via communications channel 550. In one embodiment, communications channel 550 may be a wired or wireless network or any of a variety of other communications links. Communications channel 550 carries signals 555 and is implemented using a variety of wired or wireless communications means, including wire or cable, optical fiber, conventional telephone line, cellular phone link, wireless data communications link, radio frequency (“RF”) link, or infrared link, to name just a few.

[0067] Computer-executable code (i.e., computer programs or software, such as the disclosed applications) is stored in main memory 515 and / or secondary memory 520. Computer programs may also be received via communications interface 540 and stored in main memory 515 and / or secondary memory 520. Such computer programs, when executed, enable system 500 to perform the various functions of the present invention as previously described.

[0068] In this specification, the terms “computer-readable medium,” “storage medium,” and “medium” are used to refer to any non-transitory computer-readable storage medium used to provide computer-executable code (e.g., software and computer programs) to system 500. Examples of these media include main memory 515, secondary memory 520 (including internal memory 525, removable media 530, and external storage media 595), and any peripherals (including network information servers or other network devices) communicatively coupled to communication interface 540. These non-transitory computer-readable media are the means by which executable code, programming instructions, and software are provided to system 500.

[0069] In embodiments implemented using software, the software may be stored on a computer-readable medium and loaded into system 500 via removable medium 530, I / O interface 535, or communication interface 540. In such embodiments, the software is loaded into system 500 in the form of electrical communication signals 555. The software, when executed by processor 510, preferably causes processor 510 to perform the features and functions of the invention previously described herein.

[0070] In one embodiment, I / O interface 535 provides an interface between one or more components of system 500 and one or more input and / or output devices. Examples of input devices include, but are not limited to, keyboards, touch screens or other touch-sensitive devices, biometric sensing devices, computer mice, trackballs, pen-based pointing devices, etc. Examples of output devices include, but are not limited to, cathode ray tubes (CRTs), plasma displays, light-emitting diode (LED) displays, liquid crystal displays (LCDs), printers, vacuum fluorescent displays (VFDs), surface-conduction electron-emitter displays (SEDs), field-emission displays (FEDs), etc.

[0071] System 500 also includes optional wireless communication components that facilitate wireless communication over voice and data networks. The wireless communication components include an antenna system 570, a radio system 565, and a baseband system 560. In system 500, radio frequency (RF) signals are transmitted and received wirelessly by antenna system 570 under the control of radio system 565.

[0072] In one embodiment, antenna system 570 may include one or more antennas and one or more multiplexers (not shown) that perform a switching function to provide transmit and receive signal paths for antenna system 570. In the receive path, the received RF signal may be coupled from the multiplexer to a low noise amplifier (not shown) that amplifies the received RF signal and transmits the amplified signal to radio system 565.

[0073] In alternative embodiments, the radio system 565 may include one or more radios configured to communicate over various frequencies and protocols. In one embodiment, the radio system 565 may combine a demodulator (not shown) and a modulator (not shown) into a single integrated circuit (IC). The demodulator and modulator may also be separate components. In the incoming path, the demodulator strips out the RF carrier signal, leaving a baseband received audio signal that is transmitted from the radio system 565 to the baseband system 560.

[0074] If the received signal contains audio information, the baseband system 560 decodes the signal and converts it to an analog signal. The signal is then amplified and transmitted to a speaker. The baseband system 560 also receives analog audio signals from a microphone. These analog audio signals are converted to digital signals and encoded by the baseband system 560. The baseband system 560 also encodes the digital signals for transmission and generates baseband transmit audio signals that are routed to a modulator portion of the radio system 565. The modulator mixes the baseband transmit audio signal with an RF carrier signal to generate an RF transmit signal. The RF transmit signal is routed to an antenna system and may pass through a power amplifier (not shown). The power amplifier amplifies the RF transmit signal and routes it to the antenna system 570 where the signal is switched to an antenna port for transmission.

[0075] Baseband system 560 is also communicatively coupled to processor 510. Central processing unit 510 has access to data storage areas 515 and 520. Central processing unit 510 is preferably configured to execute instructions (i.e., computer programs or software), which may be stored in memory 515 or secondary memory 520. Computer programs may also be received from baseband system 560 and stored in data storage area 515 or secondary memory 520, or executed upon receipt. Such computer programs, when executed, enable system 500 to perform the various functions of the present invention as previously described. For example, data storage area 515 may include various software modules (not shown).

[0076] Various embodiments may also be implemented primarily in hardware using, for example, components such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). Implementations of hardware state machines capable of performing the functions described herein will also be apparent to those skilled in the art. Various embodiments may also be implemented using a combination of both hardware and software.

[0077] Furthermore, those skilled in the art will appreciate that the various illustrative logical and / or functional blocks, modules, circuits, and method steps described in connection with the above figures and the embodiments disclosed herein are often implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the invention. Furthermore, the grouping of functions within a module, block, circuit, or step is for ease of description. Particular functions or steps may be moved from one module, block, or circuit to another module, block, or circuit without departing from the invention.

[0078] Furthermore, the various illustrative logical blocks, modules, functions, and methods described in connection with the embodiments disclosed herein may be implemented or performed by, for example, a general-purpose processor, a digital signal processor (DSP), an ASIC, an FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but the processor may alternatively be any processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as, for example, a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such combination of components.

[0079] Furthermore, the steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium, including a network storage medium. An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may also reside in an ASIC.

[0080] Any of the software components described herein may take a variety of forms. For example, a component may be a standalone software package or a software package incorporated as a "tool" into a larger software product. It may be downloaded from a network, such as a website, as a standalone product or as an add-on package for installation into an existing software application. It may also be available as a client-server software application, a web-enabled software application, and / or a mobile application.

[0081] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the invention. Various modifications to those embodiments will be readily apparent to those skilled in the art, and the general principles described herein may be applied to other embodiments without departing from the spirit or scope of the invention. It will therefore be understood that the description and drawings presented herein represent presently preferred embodiments of the invention and, therefore, represent the subject matter broadly contemplated by the present invention. Furthermore, it will be understood that the scope of the present invention fully encompasses other embodiments that may become apparent to those skilled in the art, and therefore, the scope of the present invention is not limited.

Claims

1. 1. A method for accelerating transmission of packets by programmatically determining at least one next-hop MAC address for packets to be transmitted within a network by an application at an application layer in a system having a kernel with a protocol stack, the method comprising: Creating a phantom datagram (UDP) having a protocol header; leaving the next hop MAC address header unpopulated and populating one or more of the phantom UDP protocol headers; submitting the phantom UDP to the kernel to traverse the protocol stack; receiving the phantom UDP from the kernel with the next hop MAC address header populated by the kernel; recognizing the phantom UDP based on one or more predetermined characteristics; storing the next hop MAC address header from the phantom UDP; not transmitting the phantom UDP; A method comprising:

2. 2. The method of claim 1, further comprising: creating a next UDP; obtaining a stored next-hop MAC address; and populating a header of the next UDP with the obtained next-hop MAC address.

3. 3. The method of claim 2, wherein the kernel protocol stack determines the next hop MAC address header based on a predetermined rule set that describes routing rules.

4. The method of claim 3 , wherein the predetermined rule set describes one or more of a network rule, a security measure, and a firewall measure.

5. The method of claim 2 , further comprising the application controlling a NIC and instructing the NIC to drop the phantom UDP.

6. 6. The method of claim 5, further comprising: bypassing the kernel, populating a stored next-hop MAC address header into a next UDP, and providing the next UDP to the NIC.

7. creating a socket using a bind call and a connect call with the kernel; obtaining and storing a source IP and a source destination from a phantom UDP populated by said kernel; populating the header of the next UDP packet with the stored source IP and source destination; The method of claim 2 further comprising:

8. 1. A method for programmatically determining at least one layer 2 destination address of a packet transmitted within a network by an application at an application layer in a system having a kernel, the method comprising: creating a phantom packet; populating one or more protocol headers of the phantom packet while leaving the layer 2 destination address unpopulated; submitting the phantom packet to the kernel; receiving the phantom packet from the kernel with the layer 2 destination address header populated by the kernel; Recognizing the phantom packet; storing the layer 2 destination address from the phantom packet; Creating a packet: populating the header of the next packet with the stored layer 2 destination address; A method comprising:

9. 9. The method of claim 8, wherein the kernel includes a protocol stack, and further comprising: the kernel's protocol stack determining the layer 2 destination address based on a predetermined rule set that describes routing rules.

10. The method of claim 9 , wherein the predetermined rule set describes one or more of a network rule, a security measure, and a firewall measure.

11. The method of claim 8 , further comprising the application controlling a network interface controller (NIC) to drop the phantom packets.

12. 12. The method of claim 11, further comprising: bypassing the kernel and providing the next packet to the NIC.

13. creating a socket using a bind call and a connect call with the kernel; obtaining and storing a source IP and a source destination from a phantom packet populated by said kernel; populating the header of the next packet with the stored source IP and the source destination; The method of claim 8 further comprising:

14. 1. A system for accelerating transmission of packets over a network by programmatically determining a layer 2 destination address, the system comprising: at least one processor; a memory in communication with the at least one processor and storing instructions that, when executed by the at least one processor, cause the at least one processor to execute an application in an application layer using an operating system having a kernel, the application comprising: Create a phantom packet, populating one or more protocol headers of the phantom packet while leaving the layer 2 destination address unpopulated; Sending the phantom packet to the kernel; receiving the phantom packet from the kernel with the layer 2 destination address header populated by the kernel; Recognizing the phantom packet; storing the layer 2 destination address from the phantom packet; Create the following packet: Populating the header of said next packet with the stored layer 2 destination address. a memory operable to: Including, the system.

15. 15. The system of claim 14, wherein the kernel includes a protocol stack, the protocol stack of the kernel configured to determine the layer 2 destination address based on a predetermined rule set that describes routing rules.

16. The system of claim 15 , wherein the predetermined rule set describes one or more of a network rule, a security measure, and a firewall measure.

17. 15. The system of claim 14, wherein the application is further operable to control a network interface controller, the network interface controller dropping the phantom packet.

18. 15. The system of claim 14, wherein the application is further operable to bypass the kernel and provide the next packet to a network interface controller.

19. The application may further comprise: Creating a socket using a bind call and a connect call with the kernel; Obtaining and storing a source IP and a source destination from a phantom packet populated by the kernel; Populate the header of the next packet with the stored source IP and the source destination.

15. The system of claim 14, wherein the system is operable to:

20. 15. The system of claim 14, wherein the application is further operable to populate a payload of the phantom packet with a recognizer, and recognizing the phantom packet further comprises recognizing the recognizer.

Images