阅读说明：本技术 节点路径上的双向数据包交换的方法 (Method for bidirectional data packet switching on node path ) 是由 G·菲尔德 于 2018-05-08 设计创作，主要内容包括：一种节点系统，实现了用于节点中继通信的方法。接收对包括流中的地址和私有密钥的流条目的描述。将该流条目和该私有密钥存储在索引到流ID的数据库中。接收数据包，该数据包包括验证码以及包括数据包序列信息和流ID的数据包数据。在与该数据包的该流ID对应的流条目的该数据库中执行查找。根据该查找的结果，忽略该数据包或者将该数据包转发到该流中的该地址。(A node system implements a method for node relay communication. A description of a flow entry including an address in a flow and a private key is received. The stream entry and the private key are stored in a database indexed to the stream ID. A packet is received, the packet including an authentication code and packet data including packet sequence information and a stream ID. A lookup is performed in the database of flow entries corresponding to the flow ID of the packet. Depending on the result of the lookup, the packet is ignored or forwarded to the address in the flow.)

1. A node system comprising;

processor with a memory having a plurality of memory cells

Memory device

Wherein the node system is configured to implement a method for node relay communication, the method comprising:

a) receiving a description of a flow entry, the flow entry including an address in a flow and a private key;

b) storing the stream entry and the private key in a database indexed to a stream ID;

c) receiving a data packet, wherein the data packet comprises an authentication code and data packet comprising data packet sequence information and a stream ID;

d) performing a lookup in the database of flow entries corresponding to the flow ID of the data packet; and

e) ignoring the data packet or forwarding the data packet to the address in the flow according to the result of the lookup.

2. The system of claim 1, wherein e) comprises: if no flow entry exists, the packet is ignored.

3. The system of claim 1, wherein in d), performing a lookup in the database further comprises: checking whether the verification code of the packet indicates that the packet data is signed with a flow private key that matches the private key in the flow entry in the database.

4. The system of claim 3, wherein e) comprises: ignoring the packet data if the packet data is not signed with a flow private key that matches the private key in the flow entry.

5. The system of claim 3, wherein e) further comprises: testing a packet sequence number for a replay protection buffer for a packet received from a next node if the packet data is signed with a stream private key matching the private key in the stream entry in the database; and ignoring the data packet if the data packet has been received or is old.

6. The system of claim 5, wherein e) further comprises: forwarding the packet data to a previous node and/or a next node in the flow without modification if the packet data is signed with a flow private key that matches the private key in the flow entry in the database and the packet has not been received and is not old.

7. The system of claim 6, further comprising updating a timestamp in the flow entry of a last received packet to a current timestamp.

8. The system of claim 6, wherein the data packet is received from the previous node and the system forwards the data packet to the next node without modification.

9. The system of claim 6, wherein the data packet is received from the next node and the system forwards the data packet to the previous node without modification.

10. The system of claim 6, further comprising: f) removing the flow entry from the database if a data packet having the flow ID corresponding to the flow entry is not received from the previous node and/or the next node within a predetermined period of time; and stopping forwarding packets having the flow ID corresponding to the removed flow entry.

11. The system of claim 1, wherein the database is further indexed to a stream version.

12. The system of claim 1, wherein the data packet comprises a stream version.

13. The system of claim 11, wherein performing the lookup in the database comprises performing a lookup using a version of a flow in the data packet.

14. The method of claim 1, wherein a) comprises: receiving the description of the flow entry from a host server.

15. The method of claim 1, wherein a) comprises: receiving the description of the flow entry in a data packet from another node containing one or more flow tokens, each flow token including the flow ID, a flow version, address and port information for one or more other nodes in the flow, and a flow private key.

16. The method of claim 15, wherein the data packet from the other node comprises an expiration timestamp, a previous node IP address and port, a next node IP address and port.

17. The method of claim 15, further comprising: attempting to decrypt a first flow token in the data packet from the other node using a node private key and a master server public key; and

modifying the data packet by removing the first flow token and forwarding the resulting modified data packet to a next node IP address and port in the first flow token when the attempt to decrypt the first flow token is successful.

18. A non-transitory computer readable medium having computer readable instructions embodied therein, the computer readable instructions configured to implement a node relay communication method when executing the node relay communication method, the method comprising;

a) receiving a description of a flow entry comprising an address in a flow and a private key;

b) storing the stream entry and the private key in a database indexed to a stream ID;

c) receiving a data packet, wherein the data packet comprises an authentication code and data packet comprising a data packet sequence and a stream ID;

d) performing a lookup in the database of flow entries corresponding to the flow ID of the data packet; and

e) ignoring the data packet or forwarding the data packet to the address in the flow according to the result of the lookup.

19. The non-transitory computer-readable medium of claim 18, wherein e) comprises: if no flow entry exists, the packet is ignored.

20. The non-transitory computer-readable medium of claim 15, wherein performing a lookup in the database at d) further comprises: checking whether the verification code of the packet indicates that the packet data (sequence number, flow ID, flow version) is signed with a flow private key that matches the private key in the flow entry in the database.

21. The non-transitory computer-readable medium of claim 20, wherein e) comprises: ignoring the packet data if the packet data is not signed with a flow private key that matches the private key in the flow entry.

22. The non-transitory computer-readable medium of claim 20, wherein e) further comprises: testing a packet sequence number for a replay protection buffer for a packet received from a next node if the packet data is signed with a stream private key matching the private key in the stream entry in the database; and ignoring the data packet if the data packet has been received or is old.

23. The non-transitory computer-readable medium of claim 22, wherein e) further comprises: forwarding the packet to a previous node and/or a next node without modification if the packet data is signed with a flow private key that matches the private key in the flow entry in the database and the packet has not been received and is not old.

24. The non-transitory computer-readable medium of claim 23, further comprising updating a timestamp in the flow entry of a last received packet to a current timestamp.

25. The non-transitory computer-readable medium of claim 23, wherein the data packet is received from the previous node and the system forwards the data packet to the next node without modification.

26. The non-transitory computer-readable medium of claim 23, wherein the data packet is received from the next node and the system forwards the data packet to the previous node without modification.

27. The non-transitory computer-readable medium of claim 23, further comprising: f) removing the flow entry from the database if a data packet having the flow ID corresponding to the flow entry is not received from the previous node and/or the next node within a predetermined period of time; and stopping forwarding packets having the flow ID corresponding to the removed flow entry.

28. The non-transitory computer-readable medium of claim 18, wherein the database is further indexed to a stream version.

29. The non-transitory computer-readable medium of claim 18, wherein the data packet comprises a stream version.

30. The non-transitory computer-readable medium of claim 29, wherein performing the lookup in the database comprises performing a lookup using a version of a flow in the data packet

31. The non-transitory computer-readable medium of claim 18, wherein a) further comprises: receiving the description of the flow entry from a host server.

32. The non-transitory computer-readable medium of claim 18, wherein a) comprises: receiving the description of the flow entry in a data packet from another node containing one or more flow tokens, each flow token including the flow ID, a flow version, address and port information for one or more other nodes in the flow, and a flow private key.

33. The non-transitory computer-readable medium of claim 32, wherein the data packet from the other node comprises an expiration timestamp, a previous node IP address and port, a next node IP address and port.

34. The non-transitory computer-readable medium of claim 32, further comprising: attempting to decrypt a first flow token in the data packet from the other node using a node private key and a master server public key; and

modifying the data packet by removing the first flow token and forwarding the resulting modified data packet to a next node IP address and port in the first flow token when the attempt to decrypt the first flow token is successful.

35. A primary server system comprising:

a processor;

a memory;

wherein the master server system is configured to implement a method for node relay communication, the method comprising:

a) receiving node information from a node in a network;

b) determining one or more flow paths between a starting node and an ending node according to node information, wherein the flow paths comprise one or more nodes in the network;

c) transmitting flow path information to one or more nodes, wherein the flow path information comprises one or more flow tokens corresponding to each of the one or more nodes in the flow path and a flow token for the server, and wherein each flow token comprises a flow ID, a flow version, an expiration timestamp, a flow private key, and a next and/or previous node IP address and port.

36. A matcher server system comprising:

a processor;

memory device

Wherein the matcher server system is configured to implement a method for node relay communication, the method comprising:

a) receiving a request from a client to connect to one or more servers;

b) requesting one or more flow paths between the client and one or more servers from a master server;

b) receiving, from the master server, flow path information for one or more flow paths between the client and the one or more servers, wherein the flow path information includes a flow token for the client, one or more flow tokens corresponding to each of one or more repeaters in the flow path, and a flow token for the server, and wherein each flow token includes a flow ID, a flow version, an expiration timestamp, a flow private key, a previous and/or next node IP address and port.

Technical Field

The field of the disclosure is network communications.

Background

The background description includes information that may be useful in understanding the present invention. There is no admission that any of the information provided in this application is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.

Real-time multiplayer games typically operate by sending unreliable unordered packets, e.g., as User Datagram Protocol (UDP) packets, over the internet in a bi-directional streaming mode in which packets are sent at a certain rate, such as 10, 20, 30, or 60 packets per second, in both directions from client to server and from server to client.

The data packets exchanged between the client and the server are extremely sensitive to delay, jitter and/or data packet loss. Collectively referred to as quality of service or "QoS".

Typically, a client connects to a dedicated server by sending and receiving data packets directly to the server's IP address, but this makes the dedicated server vulnerable to distributed denial of service (DDoS) attacks because the server's IP address is public.

In addition, when the data packet is transmitted through the public internet, the route taken by the data packet between the client and the server is not directly controlled by the client or the server. Packets take the cheapest route rather than the route that optimizes QoS.

Similarly, when exchanging data packets over the internet, a client or server will not be able to adjust the route taken by the data packet between the client and server if the route taken by the data packet between the client and server degrades or a better route becomes available.

There is therefore a need for an improved method of connecting a client to a dedicated server that does not disclose the IP address of the server and provides some degree of control over the route taken by packets between the client and the server.

Drawings

Fig. 1 shows a dedicated server reporting information to the matcher (matchmaker).

Fig. 2 illustrates relaying report information to a primary server.

Figure 3 shows a client requesting a connection to a dedicated server.

FIG. 4 shows the primary server returning a series of streams to the client.

Fig. 5A shows a flow path.

Fig. 5B shows a flow token.

Fig. 6 shows a client sending a request packet to a dedicated server.

Figure 7 shows a response packet sent to a client in response to a request packet received from the client.

Fig. 8A shows a cache of a repeater.

Fig. 8B shows entry data in the cache of the repeater.

FIG. 9A illustrates a cache of a server.

Fig. 9B shows token data in the cache of the server.

FIG. 10 shows a client requesting an updated flow path.

FIG. 11 shows a primary server sending an updated flow path to a client.

Fig. 12 illustrates a request packet for an updated route passed from a client to a server while preserving an existing route for a payload packet.

Fig. 13 shows a response packet sent to a client in response to an updated request packet received from the client.

Fig. 14 illustrates a session token in accordance with aspects of the present disclosure.

Fig. 15 illustrates a system that can be utilized to implement a node relay communication method in accordance with an aspect of the disclosure.

Detailed Description

The following discussion provides exemplary embodiments of the present subject matter. While each embodiment represents a single combination of inventive elements, the inventive subject matter is considered to include all possible combinations of the disclosed elements. Thus, if one embodiment includes elements A, B and C, and a second embodiment includes elements B and D, then even if not explicitly disclosed, the inventive subject matter is considered to include A, B, C or the other remaining combinations of D.

The meaning of "a", "an", and "the" as used in the description of this application and throughout the claims that follow, unless the context clearly dictates otherwise, includes a plurality of reference objects. In addition, the meaning of "in … …" as used in the description of the present application includes "in … …" and "on … …" unless the context clearly indicates otherwise.

In addition, as used in this application and unless the context dictates otherwise, the term "coupled to" is intended to include both direct coupling (in which two elements coupled to each other are in contact with each other) and indirect coupling (in which at least one additional element is located between the two elements). Thus, the terms "coupled to" and "coupled with … …" are used synonymously.

In some embodiments, numerical values representing quantities of ingredients, properties (such as concentrations, reaction conditions, and the like) used to describe and claim certain embodiments of the present invention are to be understood as being modified in some instances by the term "about". Accordingly, in some embodiments, the numerical parameters set forth in the written description and attached claims are approximations that may vary depending upon the desired properties sought to be obtained by a particular embodiment. In some implementations, numerical parameters should be interpreted according to the number of reported significant bits and by applying general rounding techniques. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of some embodiments of the invention are approximations, the numerical values set forth in the specific examples are reported as precisely as possible. Numerical values presented in some embodiments of the invention can contain certain errors necessarily resulting from the standard deviation found in their respective testing measurements. Moreover, and unless the context indicates to the contrary, all ranges set forth in this application should be construed as including the endpoints thereof, and open ranges should be construed as including only values of commercial utility. Similarly, all lists of values should be considered as including intermediate values unless the context indicates otherwise.

It should be noted that any language directed to a computer should be understood to include any suitable combination of computing devices, including servers, interfaces, systems, databases, agents, peers, engines, controllers, or other types of computing devices operating alone or in combination. It should be understood that the computing device includes a processor configured to execute software instructions stored on a tangible, non-transitory computer readable storage medium (e.g., hard disk drive, solid state drive, RAM, flash memory, ROM, etc.). The software instructions preferably configure the computing device to provide the roles, responsibilities, or other functions as discussed below with respect to the disclosed apparatus. In particularly preferred embodiments, the various servers, systems, databases, or interfaces exchange data using standardized protocols or algorithms, which may be based on HTTP, HTTPs, AES, public-private key exchanges, web services Application Program Interfaces (APIs), known financial transaction protocols, or other electronic information exchange methods. The data exchange is preferably performed over a packet-switched network, the internet, a LAN, a WAN, a VPN, or other type of packet-switched network. The following description includes information that may be useful in understanding the present invention. There is no admission that any of the information provided in this application is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.

The subject matter of the present invention includes a system and method for connecting two computers via a stream path such that neither computer knows the IP address of the other. It is contemplated that the subject matter of this invention can be implemented as a safeguard in the field of online gaming to ensure that no client (e.g., game player) is able to know the IP address of a dedicated server (e.g., game hosting server).

To ensure that the client cannot know the identity or location (e.g., IP address and port) of the server, at least one repeater may be implemented as an intermediary to facilitate packet switching. By locating the relay between the client and the server, the client only needs to know that it must send data packets to the relay, and the relay in turn knows that it receives data packets from the client and sends data packets to the server. In the same way, the server only knows that it receives packets from the relay and in turn sends packets to the relay.

It may be advantageous to include additional repeaters. In a system including more than one relay, the relays, clients, and servers may all be referred to as "nodes". The ultimate goal is to enable packet exchange between the client and the server via the flow path in such a way that the client never knows the IP address and port of the server, while also optimizing the routing according to some metric.

More specifically, embodiments of the present subject matter provide optimized routing between a client and a dedicated server by locating routes on the public internet to "relay" therebetween. The routing may be optimized to reduce delay, reduce packet loss, or improve any other QoS (quality of service) metric, for example, as needed. As long as there are multiple relay routes between the client and the server, and each relay route has different characteristics, the best route can be selected. This is similar to route finding software such as google maps, apple maps, Waze, etc., as the desired end result is to select and establish the fastest route to the destination.

Embodiments of the inventive subject matter also provide DDoS protection by hiding the IP address of the dedicated server from clients communicating with the dedicated server. This makes it impossible to attack a dedicated server in a conventional DDoS attack. Embodiments also provide the ability to dynamically change routes while clients continue to exchange packets with the dedicated server. For example, if a better route becomes available, or if the current route has repeaters that are attacked by DDoS along the way, the client's session (e.g., game session) can continue uninterrupted on the dedicated server even though it has dynamically adjusted its route, by dynamically changing the route without stopping the exchange of data packets between the client and the server on the existing route.

Embodiments of the inventive subject matter also improve security. A malicious third party cannot hijack the repeater of the present subject matter to send data packets therebetween. The subject matter of the present invention makes it unimportant that the system rejects data packets that do not originate from a valid client or server.

Fig. 1 and 2 illustrate several background polling operations. Dedicated server s₁,...,s_jA dedicated game server (e.g., a headless version of a game running in a data center such as a private cloud (e.g., a data center or "bare metal") or a public cloud such as google computing, amazon EC2, or microsoft Azure) reports its IP address, port, and public key to the matcher periodically (e.g., at regular or irregular intervals). FIG. 1 shows a dedicated server s₁s₂...s_jSpecial-purpose server s₁s₂...s_jTheir IP addresses and ports and their public keys are reported 104 to the matcher 101. The reporting is done periodically (e.g., at regular or irregular intervals). For example, each dedicated server s₁s₂...s_jIts IP address and port may be reported 104 to matcher 101 every 1-5 minutes. Special servers s are also envisaged₁s₂...s_jThe reports to matcher 101 may be made at other intervals including every 1-30 seconds, 30-59 seconds, or even multiple times per second (e.g., 2-10 Hz). The periodic reports 104 enable the queue-based optimized microservice architecture to handle a large number of dedicated servers.

The matcher 101 maintains this list and updates it as needed (e.g. if a dedicated server s₁s₂...s_jStop reporting, matcher 101 removes the dedicated server from the list it maintains, or if a new dedicated server reports using a new IP address and port, the matcher adds this information to its database). The data for each dedicated server contains at least the IP address, port, and public key for each dedicated server, but may also include other criteria that may be used to determine which dedicated servers best satisfy the client's request (e.g., game version number, number of players currently connected to the server, total number of players allowed to connect to the server, area in which the server is located, game mode in which the server is currently running (e.g., "flag-grab" (CTF) or "death competition" (death) "), skill level of players currently connected to the server, etc.).

Matcher 101 may be operated by, for example, a video game company. The matcher 101 has some kind of authentication that allows it to communicate with the primary server 102, otherwise the primary server 102 is not publicly accessible. The role of the matcher 101 is to accept a request from a client 103 to play a game and to find a set of dedicated server IP addresses and ports for the client to connect to satisfy the client's request. This could be, for example, a server running the same game mode requested by the client or a group of players in the same area as the client 103, with the same game version number and similar skills as the client player, or any other standard server.

For purposes of this application, a "flow path" is a node path that links a client to a server. A "flow" describes a packet that is exchanged on a "stream path" once established.

FIG. 2 shows a repeater r reporting its IP address and port and its public key to a host server₁,r₂...r_i. The primary server performs 102 the same functions as the matcher 101 with this capability: it stores IP addresses and ports and repeaters r₁,r₂...r_iAnd updates this information as needed. As with matcher 101, reporting 201 occurs periodically (e.g., at regular or irregular intervals). For example, each repeater r₁,r₂...r_iThe IP address and port of each repeater may be reported 201 to the master server every 1-5 minutes. It is also contemplated that the repeater may report 201 to the primary server 102 at other intervals including every 1-30 seconds, 30-59 seconds, or even multiple times per second (e.g., 2-10 Hz). The periodic reports 201 enable the queue-based optimized microservice architecture to handle a large number of repeaters.

Further, consider a repeater r₁,r₂...r_iAuthentication may be performed with the host server 102 to ensure that unauthorized repeaters cannot register with the host server 102.

At a minimum, the data for each repeater includes the IP address + port and public key for that repeater, but may also contain additional information that can be used to create a flow path that is optimized based on different criteria (e.g., longitude/latitude of each repeater, nearby repeaters, current measurement round trip time to nearby repeaters, etc.).

The role of the main server 102 is to generate a flow path between two endpoints (e.g., a path from a client to a dedicated server via a series of repeaters). The node paths may be identified by an algorithm in an attempt to identify a flow path that is optimized based on one or more factors (e.g., minimizing delay, minimizing packet loss, minimizing jitter, or any combination thereof). The main server 102 is available for the matcher 101 to query using, for example, the REST API.

Before discussing the process of establishing a flow, it is important to introduce the different packet types that are encompassed by embodiments of the inventive subject matter. In an embodiment of the present subject matter, a data packet sent over a network is prefixed with one byte that identifies the type of the data packet. There are four packet types: 0. 1, 2 and 3. Packet type 0 indicates a request packet. The format of packet type 0 is [0] [ flow token 0, flow token 1, …, flow token n-1], and corresponds to a stream data structure prefixed with zero bytes. Packet type 1 indicates a response packet. Packet type 2 indicates the payload packet passed from the client to the server. Packet type 3 indicates the payload packet delivered from the server to the client. The packet sequence number only applies to response packets and payload packets. Packet type 1 has the following form: [1] [ packet sequence ] [ stream ID ] [ stream version ] [ hash information verification code (hmac) ], and packet types 2 and 3 have the following form: [1, 2, or 3] [ packet sequence ] [ stream ID ] [ stream version ] [ hmac ] (payload data).

Client state

First, a client can exist in several states:

FLOW_CLIENT_STATE_INVALID_FLOW_ROUTE	2
		FLOW_CLIENT_STATE_TIMED_OUT	1
FLOW_CLIENT_STATE_StopPED
		FLOW_CLIENT_STATE_REQUESTED
FLOW_CLIENT_STATE_ESTABLISHED

the client starts in a "stop" state (state 0) and when the user needs to establish a flow, the user passes the flow path to the client. The client then attempts to decrypt the first flow token in the flow path using its private key and the public key of the master server (which it knows). If the flow token cannot be decrypted, has expired, or is invalid for any reason, the client will enter an invalid flow state (state-2). Otherwise, the client enters the "request" state (state 1). While in this state, the client sends a request packet to the first repeater at a certain frequency (e.g., 10 Hz). If the client receives a response packet from the first repeater while in the "request" state, the client transitions to the "established" state (state 2). When in the "established state", the client stops sending the "request packet". If a client in the "request" or "established" state does not receive a packet from the first repeater for a period of time (e.g., 1-10 seconds), it times out and enters a "timeout" state.

If the client is in the "requested" state or the "established" state, the user may send payload packets from the client to the server, and may receive any payload packets sent from the server to the client. This allows the client to optimistically send payload packets before having confirmed that the stream is fully established. Further, when the client sends a payload packet to the server, it generates a "flow header" for each packet, the flow header having the packet sequence number, flow ID, flow version, and HMAC (e.g., signed with a flow private key from the flow token), and then passes the packet to the first relay. The client then increments the packet sequence number, starting with 0 and incrementing by 1 as each packet is sent to the server. The stream private key is a separate symmetric key that is used to protect the stream from unauthorized packets. The stream private key may be randomly generated for each stream granted by the master server 102.

When the client receives payload packets from the server, it compares their packet sequence number with the replay protection buffer. If a packet has been received or is too old, it is discarded. This avoids a class of protocol level attacks known as "replay" attacks, in which an attacker replays valid data packets that have been exchanged in the system in an attempt to break the protocol. Many of these concepts are described more fully below.

Repeater behavior