US20230188628A1 - Invoking a Random Linear Network Coding Communications Protocol - Google Patents
Invoking a Random Linear Network Coding Communications Protocol Download PDFInfo
- Publication number
- US20230188628A1 US20230188628A1 US18/065,375 US202218065375A US2023188628A1 US 20230188628 A1 US20230188628 A1 US 20230188628A1 US 202218065375 A US202218065375 A US 202218065375A US 2023188628 A1 US2023188628 A1 US 2023188628A1
- Authority
- US
- United States
- Prior art keywords
- client
- rlnc
- server
- communications protocol
- protocol
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000004891 communication Methods 0.000 title claims abstract description 193
- 238000000034 method Methods 0.000 claims description 21
- 230000005641 tunneling Effects 0.000 claims description 20
- 230000005540 biological transmission Effects 0.000 claims description 19
- 230000004044 response Effects 0.000 claims description 14
- 238000013475 authorization Methods 0.000 claims description 5
- 238000005516 engineering process Methods 0.000 abstract description 17
- 238000007726 management method Methods 0.000 description 18
- 238000010586 diagram Methods 0.000 description 13
- 230000015654 memory Effects 0.000 description 9
- 230000006855 networking Effects 0.000 description 7
- 238000010200 validation analysis Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000005070 sampling Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 238000012935 Averaging Methods 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
- OGMARHJAPWBNFA-UHFFFAOYSA-N vancomycin cdp-1 Chemical compound O1C(C(=C2)Cl)=CC=C2C(O)C(C(NC(C2=CC(O)=CC(O)=C2C=2C(O)=CC=C3C=2)C(O)=O)=O)NC(=O)C3NC(=O)C2NC(=O)CC(C(O)=O)NC(=O)C(NC(=O)C(CC(C)C)NC)C(O)C(C=C3Cl)=CC=C3OC3=CC2=CC1=C3OC1OC(CO)C(O)C(O)C1OC1CC(C)(N)C(O)C(C)O1 OGMARHJAPWBNFA-UHFFFAOYSA-N 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/03—Protocol definition or specification
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0076—Distributed coding, e.g. network coding, involving channel coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/19—Flow control; Congestion control at layers above the network layer
- H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
Definitions
- Communications across computer networks have become a widely available form of communications.
- the communications can be between many forms of computing devices, including: mobile devices, servers, clients to servers, game consoles, desktop computers, laptops and a myriad of other computing devices.
- the form of data being sent in these communications usually takes the form of data packets which are transmitted between the computing devices.
- TCP/IP transmission control protocol / internet protocol
- the recipient TCP layer may collect the packets and organize the packets in the order in which the packets were sent. If a packet is lost, the protocol interprets this as a sign that the network is congested - the transmission speed is immediately halved, and from there the packets speed attempts to increase again at a slow rate. This is beneficial in some situations and inefficient in other situations.
- FIG. 1 is a sequence diagram that illustrates various operations associated with invoking a random linear network coding (RLNC) communications protocol between a client and server in a network.
- RLNC random linear network coding
- FIG. 2 A is a block diagram illustrating an example of a system for communicating over a network using the RLNC communications protocol.
- FIG. 2 B is a diagram of a data packet that includes an RLNC flag in a header of the data packet.
- FIG. 3 is block diagram that illustrates another example of a system that includes a server and clients configured to support the RLNC communications protocol.
- FIG. 4 is a block diagram illustrating an example of the technology using a tunneling interface and a random linear network coding to prepare data packets to be sent across a network.
- FIG. 5 is a flow diagram that illustrates an example method for invoking an RLNC communications protocol from a server perspective.
- FIG. 6 is a flow diagram illustrating another example method for invoking an RLNC communications protocol from a client perspective.
- FIG. 7 is block diagram illustrating an example of a computing device that may be used to execute a method that invokes the RLNC communications protocol between a client and server.
- random linear network coding can be used to reduce network congestion by allowing (i) a receiver (e.g., a server or a client) to ignore lost data packets sent by a transmitter (e.g., the server or the client) and acknowledge the receipt of certain data packets, (ii) a receiver to rebuild lost data packets sent by a transmitter, and (iii) a transmitter to avoid retransmitting data packets.
- invoking the RLNC communications protocol between a client and a server may include sending a synchronize (SYN) message from the client to the server requesting a network connection with the server, where the synchronize message indicates that the client supports the RLNC communications protocol.
- the server may analyze the message for an indication (e.g., a protocol flag, type-length-value, etc.) that the client supports the RLNC communications protocol.
- the server may send an acknowledge message in a synchronize-acknowledge packet or an acknowledge packet (e.g., in an SYN-ACK or ACK packet) to the client indicating that the server supports the RLNC communications protocol.
- the server may listen on a communications channel (e.g., UDP (User Datagram Protocol) port) for a connection request and/or encoded data packets from the client to communicate with the server using the RLNC communications protocol.
- a communications channel e.g., UDP (User Datagram Protocol) port
- the communication channel may be a dedicated or defined communications channel (e.g., a dedicated UDP port).
- FIG. 1 is a sequence diagram illustrating operations used to invoke an RLNC communications protocol between a client 102 and a server 104 .
- the client 102 may be configured to support the RLNC communications protocol by encoding and decoding data packets (e.g., encoding or decoding the contents of data packets and portions of the packet headers as described later) using random linear network coding.
- the server 104 may be configured to support the RLNC communications protocol by decoding and encoding data packets using random linear network coding.
- a client 102 may send a synchronize message 110 to the server 104 using a first communications channel 106 (e.g., a logical connection over a computer network) requesting a network connection with the server 104 .
- the synchronize message 110 may indicate that the client 102 supports the RLNC communications protocol.
- a header of the synchronize message 110 can include a field containing an RLNC protocol flag, a type-length-value (TLV), a cryptographic hash, or another value or data field that indicates that the client 102 supports the RLNC communications protocol.
- the synchronize message 110 can be sent using a TCP/IP transmission protocol over the Internet, wherein the synchronize message 110 requests a TCP/IP connection with the server 104 , and the header of the synchronize message 110 includes a field value indicating to the server 104 that the client 102 is configured to encode and decode data packets using random linear network coding.
- the server 104 may analyze the synchronize message 110 for an indication that the client 102 supports the RLNC communications protocol. For example, the server 104 may analyze a header of the synchronize message 110 to determine whether a designated field in the header contains a value (e.g., RLNC protocol flag, TLC, cryptographic hash, etc.) representing support of the RLNC communications protocol. In determining that the synchronize message 110 indicates client support for the RLNC communications protocol, the server 104 may send an acknowledge message 112 to the client 102 using the first communications channel 106 , where the acknowledge message 112 indicates that the server 104 supports the RLNC communications protocol.
- a value e.g., RLNC protocol flag, TLC, cryptographic hash, etc.
- a header of the acknowledge message 112 may include a field containing an RLNC protocol flag, a TLV, a cryptographic hash, or another value indicating that the server 104 supports the RLNC communications protocol.
- the server 104 may obtain an identifier used for the client 102 (e.g., an internet protocol (IP) address or media access control (MAC) address) to allow identification of data packets sent by the client 102 using the RLNC communications protocol to the server 104 as being associated with the client 102 .
- IP internet protocol
- MAC media access control
- the acknowledge message 112 may be analyzed for an indication that the server 104 supports the RLNC communications protocol.
- the client 102 may analyze a header of the acknowledge message 112 to determine whether a designated field in the header contains a value (e.g., RLNC protocol flag, TLC, cryptographic hash, etc.) representing server support of the RLNC communications protocol.
- a value e.g., RLNC protocol flag, TLC, cryptographic hash, etc.
- the client 102 may initiate termination of the first communications channel 106 to allow a second communications channel 108 to be opened for transmitting data over TCP/IP using the RLNC communications protocol.
- the client 102 may initiate termination of the network connection between the client 102 and the server 104 by sending a finish message 114 to the server 104 .
- the server 104 may close the network connection between the server 104 and the client 102 , thereby closing the first communications channel 106 .
- a four-way handshake may be used to close the first communications channel 106 , wherein the client 102 and the server 104 independently terminate the network connection by transmitting finish messages to each other and acknowledging the finish messages, and waiting for a timeout to occur before closing the first communications channel 106 .
- the client 102 may abandon a request to connect to the server 104 using the TCP/IP protocol by not transmitting a finish message after determining that the server 104 supports the RLNC communications protocol and the client 104 can start sending encoded data packets to the server 104 via a second communications channel 108 , as explained below.
- the client 102 may encode data packets 116 for transmission to the server 104 using random linear network coding and the client 102 may send the encoded data packets 116 to the server 104 using a second communications channel 108 (e.g., a UDP communications channel).
- a second communications channel 108 e.g., a UDP communications channel
- the server 104 may open a network port (e.g., UDP port) for communicating with the client 102 using data packets encoded in the RLNC communications protocol and listen for data packets 116 sent from the client 102 .
- the network port may be a dedicated or defined network port.
- the client 102 may encode data packets 116 using random linear network coding and send the data packets 116 to the network port.
- the server 104 may receive the data packets 116 sent from the client 102 over the second communications channel 108 , and the server 104 may decode the data packets 116 using random linear network coding. Likewise, the server 104 may encode data packets using random linear network coding and send the data packets 116 to the client 102 via the network port, and the client 102 may decode the data packets 116 using random linear network coding.
- the server 104 may ignore an indication (e.g., RLNC protocol flag) in a synchronize message 110 that a client 102 supports the RLNC communications protocol, and network communication between the client 102 and the server 104 may proceed using a network protocol used to send the synchronize message 110 to the server 104 .
- a client 102 may initially use a TCP/IP transmission protocol to send a synchronize message 110 indicating client support for the RLNC communications protocol to a server 104 .
- the server 104 may ignore the indication of client support for the RLNC communications protocol in the synchronize message 110 and proceed with establishing a network connection using the TCP/IP protocol for communications between the client 102 and the server 104 .
- FIG. 2 A is a block diagram illustrating one high level configuration of a system 200 for communicating over a network 210 using the RLNC communications protocol.
- the system 200 may include a server 202 and a plurality of clients 204 configured to use the RLNC communications protocol to encode and decode data packets using random linear network coding.
- the server 202 may be any computer accessible by a client 204 over a network 210 , including but not limited to a service provider (e.g., “cloud”) server, gateway, router, mainframe server, proxy server, etc.
- the network 210 connecting the server 202 and the client 204 may include a local area network (“LAN”), a wide area network (“WAN”), a wireless network, a cellular network, the Internet, or the like.
- LAN local area network
- WAN wide area network
- wireless network a cellular network
- the Internet or the like.
- a client 204 may be an electronic device or a software application running on a computing device, including a mobile electronic device, a smartphone, a tablet computer, a laptop computer, a desktop computer, a server, a digital media player (e.g., Chromecast, Apple TV, etc.), a network appliance, a gaming console (e.g., PlayStation, Xbox, etc.), or the like.
- a client 204 implemented as a software application may include a VPN (virtual private network) client and/or an application running on a mobile electronic device.
- a server 202 and a client 204 may be capable of encoding data packets using random linear network coding, and sending and receiving the data packets, as well as receiving and decoding data packets encoded using random linear network coding.
- Random linear network coding enables (i) a receiver (e.g., the server 202 or the client 204 ) to ignore lost data packets sent by the transmitter (e.g., the server 202 or the client 204 ) and acknowledge the receipt of certain data packets and (ii) a transmitter to avoid retransmitting data packets, thus reducing network congestion.
- a server 202 and a client 204 may contain a network coding module 206a-b configured to encode data packets using random linear network coding, and decode data packets encoded using random linear network coding.
- Traditional TCP/IP transmission divides data content into sequentially numbered packets and sends each packet with its accompanying sequence number. If a packet (i) does not arrive at its destination and therefore an acknowledgement is not sent to the origin or (ii) an acknowledgement is sent but does not arrive at the origin within a specific window of time, the packet is resent.
- each coded data packet is formed by multiplying each data block with a constant chosen randomly from a finite range of constants and then combining the results.
- each coded data packet can be represented by a linear equation in the following form:
- CDP 1 C 1 , 1 x DB 1 , 1 + C 1 , 2 x DB 1 , 2 + . . . + C 1 ,m x DB 1 , m
- CDP 2 C 2 , 1 x DB 2 , 1 + C 2 , 2 x DB 2 , 2 + . . . + C 2 , m x DB 2 , m
- CDP k C k , 1 x DB k , 1 + C k , 2 x DB k , 2 + . . . + C k,m x DB k , m
- CDP represents a “coded data packet”
- DB represents a “data block”
- C represents a randomly chosen constant from a finite range of constants.
- the randomly chosen constant C k,m multiplied with each data block is encoded in the headers of the coded data packets in which they are used.
- coded data packets are sent continuously until n distinct (i.e., linearly independent) coded data packets are received and acknowledged. Once n distinct coded data packets are received, they can be decoded to find the n data blocks.
- some individual coded data packets can be decoded as they are received. For example, given m distinct coded data packets encoded using a total of p unique data blocks, where m ⁇ p, it is possible to decode the m coded data packets to find the p data blocks.
- the server 202 and the client 204 may contain a control module 208 a - b .
- the control module 208 a - b may be configured to cause the server 202 and the client 204 to send and receive data packets between each other.
- the control module 208 a - b may use a default network protocol for a network connection, and utilize a RLNC communications protocol when the RLNC communications protocol is supported by both a server 202 and a client 204 .
- control module 208 a - b may communicate using a TCP layer included in a TCP/IP stack (e.g., a set of TCP/IP network protocol layers) configured to insert an indication of support for the RLNC communications protocol in a header of a packet, and the control module 208 a - b may determine whether a header of a received packet contains an indication of support for the RLNC communications protocol.
- a TCP layer included in a TCP/IP stack e.g., a set of TCP/IP network protocol layers
- the control module 208 b located on a client 204 may initiate a network connection with a server 202 by causing a synchronize message to be sent from the client 204 to the server 202 using a common network protocol, such as a TCP/IP protocol or another networking protocol.
- the synchronize message can include an indication that the client 204 supports an RLNC communications protocol by encoding and decoding data packets using random linear network coding.
- the indication in the synchronize message sent from the client 204 can be an RLNC protocol flag, a type-length-value (TLV), a cryptographic hash, or another value which indicates that the client 204 supports the RLNC communications protocol.
- FIG. 2 A illustrates an example data packet 210 that includes an RLNC flag 212 used to indicate client support of the RLNC communications protocol.
- the control module 208 b on the client 204 shown in FIG. 2 A may analyze an acknowledge message received in response to the client’s synchronize message for an indication that the server 202 supports the RLNC communications protocol, and if the acknowledge message indicates server support of the RLNC communications protocol, the control module 208 b on the client 204 may initiate closing of the network connection between the client 204 and the server 202 , and, in some examples, request opening of a communications channel between the client 204 and the server 202 for sending data to the server 202 using the RLNC communications protocol.
- the control module 208 b may implement the RLNC communications protocol by instructing the network coding module 206 b to encode data packets using random linear network coding, and the control module 208 b may cause the encoded data packets to be sent to the server 202 using the communications channel.
- the communications channel may be a dedicated communications channel, which can include a network connection between the server 202 and the client 204 using a communication endpoint (e.g., network port) dedicated to RLNC communications protocol traffic.
- the control module 208 a located on the server 202 may analyze a synchronize message received from a client 204 for an indication that the client 204 supports the RLNC communications protocol, and if the client 204 supports the RLNC communications protocol, the control module 208 a causes an acknowledge message to be sent to the client 204 indicating that the server 202 also supports the RLNC communications protocol. Thereafter, the control module 208 a on the server 202 may listen on a communications channel for data packets sent from the client 204 which are encoded using the RLNC communications protocol. For example, the control module 208 a may open a dedicated or defined network port to enable a network connection with the client 204 and to send and receive data packets using the RLNC communications protocol over the network connection.
- the server 202 may receive a finish message from the client 204 indicating that the client 204 is done sending data using a network protocol (e.g., a TCP/IP transmission protocol) that was used to send the first synchronize message.
- a network protocol e.g., a TCP/IP transmission protocol
- the control module 208 a may acknowledge that the finish message was received and that the control module 208 a is terminating the network connection between the server 202 and the client 204 by sending a final acknowledge message to the client 204 .
- control module 208 a on the server 202 may listen on a communications channel for data packets encoded using the RLNC communications protocol. In response to receiving the encoded data packets on the communications channel, the control module 208 a instructs the network coding module 206 a to decode the data packets using random linear network coding. The control module 208 a then causes data obtained from the decoded data packets to be made available to an intended recipient of the data on the client 204 , such as an application, process, service, or the like.
- FIG. 3 is a block diagram illustrating another example of a system 300 that includes a server 202 and clients 204 a - n configured to support the RLNC communications protocol.
- the server 202 may include the network coding module 206 and the control module 208 described earlier, as well as a validation module 312 and a data traffic management module 310 .
- the data traffic management module 310 , the control module 208 , the network coding module 206 , the validation module 312 may each be in communication with each other, and communication may occur over one or more types of communication frameworks or communication networks.
- the sever 202 may include, for example, mechanical, electrical and signaling circuitry needed to connect the modules 310 / 208 / 206 / 312 to each other for communication and/or sending and/or receiving data.
- the validation module 312 may be configured to authenticate a client 204 a - n and determine whether the client 204 a - n possesses valid authorization to encode and decode data packets using random linear network encoding.
- the control module 208 causes the server 202 and a client 204 a - n to send to and receive from each other data packets encoded using random linear network (RLNC) coding in response to the validation module 312 authenticating the client 204 a - n and determining that the client 204 a - n possesses valid authorization.
- RNC random linear network
- a database 314 can be used to store a unique identifier for each client 204 a - n .
- This identifier can be a unique alphanumeric code, picture, or other authentication token.
- the stored identifier may be an encrypted hash of a client’s MAC address.
- the database 314 can also store an indicator of whether a client 204 a - n is authorized to encode or decode data packets using random linear network coding.
- the control module 208 causes the server 202 and the client 204 a - n to stop sending and receiving data packets encoded using random linear network coding between each other in response to the validation module 312 determining that the client 204 a - n lacks valid authorization or a valid license.
- the data traffic management module 310 may be configured to measure characteristics of a data stream and analyze the characteristics of the data stream to determine whether to continue using the RLNC communications protocol to transmit the data stream. Characteristics of the data stream can include, but is not limited to, a data loss rate at one or more time periods and a data throughput rate. In one example configuration, the data traffic management module 310 analyzes and/or determines a data loss rate pertaining to a data stream between the server 202 and a client 204 a - n . A data stream includes data packets sent and received between the server 202 and a client 204 a - n .
- the data traffic management module 310 can simultaneously determine the data loss rate pertaining to multiple data streams between the server 202 and multiple clients 204 a - n .
- the data loss rate pertaining to a data stream may be defined in different ways.
- the data loss rate may be the total number of data packets sent by either (i) the server 202 , (ii) a client 204 a - n , or (iii) both the server 202 and the client 204 a - n , but not received by the server 202 and/or the client 204 a - n over a set period of time.
- the data loss rate may be, during a one second interval, the total number of data packets sent by a client 204 a - n to the server 202 that were not received by the server 202 .
- the data loss rate is the total number of data packets resent by (i) the server 202 , (ii) the client 204 a - n , or (iii) both the server 202 and the client 204 a - n over a set period of time.
- An example of the data loss rate using this definition may be, during a one second interval, the total number of data packets resent by server 202 to the client 204 a - n .
- a data loss rate above a certain threshold can have an adverse impact on the performance of real-time software applications running on the server 202 and/or a client 204 a - n , including but not limited to video teleconferencing, video streaming, and graphic and network heavy online multiplayer games.
- measuring the data loss rate between the server 202 and a client 204 a - n can be used to identify when network congestion is severely impairing the functionality of these applications.
- the data traffic management module 310 may count the total number of data packets lost between the server 202 and a client 204 a - n over a five second interval.
- a longer sampling window may give the data traffic management module 310 a better understanding of the state of congestion within a network between the server 202 and a client 204 a - n by better averaging the impact of momentary spikes or dips in network congestion.
- a shorter sampling window may allow for a quicker reaction to changes in network congestion.
- the data traffic management module 310 may determine the data loss rate pertaining to a data stream between the server 202 and a client 204 a - n either continuously, at regular intervals (e.g., every 30 seconds), and/or at scheduled times (e.g., during peak network usage hours). Determining the data loss rate pertaining to a data stream continuously allows the data traffic management module 310 to maintain a moving window average of the data loss rate.
- the data loss rate determined by the data traffic management module 310 may be the average of the most recent three data loss rates measured.
- the data loss rate determined by the data traffic management module 310 may be the weighted average of the most recent five data loss rates measured, with the more recently measured data loss rates weighted more heavily.
- Encoding data packets using random linear network coding can increase overhead in terms of both packet header size and time spent encoding and decoding packet payloads, as well as an increase in the size of the coded data packet header to include the randomly chosen constants.
- the overhead incurred is typically small compared to the efficiency gained by the transmitter (e.g., the server 202 or the client 204 a - n ) not having to retransmit lost coded data packets and the receiver (e.g., the server 202 or the client 204 a - n ) only having to acknowledge the receipt of every distinct coded data packet.
- the transmitter e.g., the server 202 or the client 204 a - n
- the receiver e.g., the server 202 or the client 204 a - n
- the transmitter may have to send more than n coded data packets in order for n distinct coded data packets to be received.
- sending coded data packets encoded using random linear network coding may use more network bandwidth compared to encoding and sending data packets using another network protocol like the traditional TCP/IP transmission protocol.
- the present technology allows for determining whether to continue to use the RLNC communications protocol based on characteristics of a data stream being transmitted between the server 202 and a client 204 a - n .
- the data traffic management module 310 can determine that a data loss rate is lower than a threshold, and in response, the control module 208 causes the server 202 and a client 204 a - n to stop sending and receiving data packets encoded using random linear network coding between each other.
- the data traffic management module 310 can analyze and/or determine a data throughput rate pertaining to a data stream between the server 202 and a client 204 a - n .
- the data traffic management module 310 can simultaneously determine data throughput rates pertaining to multiple data streams between the server 202 and multiple clients 204 a - n .
- the data traffic management module 310 can determine that a data throughput rate is lower than a threshold, and in response, the control module 208 can instruct the server 202 and a client 204 a - n to stop sending and receiving data packets encoded using random linear network coding.
- the data traffic management module 310 can determine a data loss rate pertaining to a data stream at various times (e.g., 8 a.m. to 5 p.m., day, week, month, Mondays, weekends, New Year’s Day) and/or a data throughput rate (e.g., an amount of data transmitted in a given time period) pertaining to a data stream at various times.
- the data traffic management module 310 can dynamically and/or automatically adjust thresholds and/or set the thresholds used to determine whether to continue to utilize the RLNC communications protocol based on a data loss rate and/or data throughput rate pertaining to a data stream.
- the thresholds may be dynamically and/or automatically adjusted and/or set to data loss rates for real-time load balancing of various modules or applications of the server 202 and/or client 204 a - n while maintaining the highest data throughput rates between the server 202 and the client 204 a - n .
- the control module 208 may cause a message to be sent to a client 204 a - n that instructs the client 204 a - n to stop using the RLNC communications protocol, and the control module 208 may cause a data stream to be sent to the client 204 a - n using another network protocol, such as a TCP/IP transmission protocol.
- FIG. 4 illustrates an example system 400 that can include an application 404 on a source computing device 402 that sends data packets using the RLNC communications protocol through a network 414 such as the Internet (e.g., through a hard wired connection or using a wireless connection such as WI-FI) or a cellular network which then communicates through the Internet or another packet switched network.
- a source computing device 402 e.g., server
- the source device 402 sends an acknowledge message to the destination device 420 indicating that the source device 402 supports the RLNC communications protocol.
- data packets sent between the source computing device 402 and the destination computing device 420 can be encapsulated using a tunneling protocol.
- the application 404 can be located in a memory device of a source computing device 402 configured to send data packets over a computer network 414 .
- the application 404 may be a content server executing on a hardware layer that is configured to deliver streaming video, streaming audio, text, web pages, or other content.
- the application 404 may be a client application requesting content.
- a tunneling interface 406 can be configured to receive the data packets from the application 404 and encapsulate the data packets using the tunneling protocol.
- the tunneling interface 406 may be a virtual private network (VPN), TAP (network tap) interface, a TUN (network TUNnel) interface, or another type of tunneling interface 406 .
- VPN virtual private network
- TAP network tap
- TUN network TUNnel
- tunneling interface 406 or VPN interface may enable the source computing device 402 to use the RLNC communications protocol with multiple applications accessing the same tunneling interface 406 on a device (e.g., a mobile device, desktop device, laptop, etc.) or in embedded hardware without specifically adding an RLNC layer or processing into each application.
- each application 404 may setup or access the application’s own separate tunneling interface 406 or VPN network interface. This way the traffic for the application 404 can be funneled through the tunneling interface 406 and may be connected with a single receiving device or server through the tunneling interface 406 .
- a group of applications 404 may share a tunneling interface 406 that is destined for one or more destination computing devices 420 within a virtualized network or physical data center.
- the VPN interface may be used because the network traffic from multiple applications can be funneled through the interface.
- an encoding module 410 or encoder may receive the encapsulated packets and encode the data packets from the tunneling interface 406 using random linear network coding to form coded data packets. Encoding the data packets using random linear network coding may make the group of data packets resistant to data packet loss and increase the speed of the data packet transmissions because lost data packets are not re-transmitted but are re-constructed at the destination computing device 420 or receiving software.
- a UDP/TCP (user datagram protocol/transmission control protocol) layer 412 can be configured to encapsulate and send the encoded data packets over the Internet using UDP (user datagram protocol). Sending the packets using UDP can increase the speed of transmission of the data packets, but UDP does not guarantee the delivery of the data packets.
- Random linear network coding may be able to compensate for any packets that are lost by mathematically reconstructing the lost information on the destination computing device 420 .
- the UDP packets can contain encoded TCP packets to transport the packets from the encoder to the destination decoder. If any control packets (e.g., with random linear network coding mathematical coefficients) are necessary to perform lost packet reconstruction, these packets can be sent using the TCP or UDP protocol.
- the encoded data packets may be sent across a network 414 , and the data packets may be received at a destination computing device 420 . Once the data packets are received at the destination computing device 420 , the data packets may be decoded using random linear network coding and encapsulation may be removed when the data packets arrive at the destination tunneling protocol layer (e.g., destination virtual network). In one example, this virtual network can be a virtual private network formed between two applications.
- the destination tunneling protocol layer e.g., destination virtual network
- the source computing device 402 may transfer any type of data that an application 404 may be configured to send to a destination computing device 420 .
- files, videos, database transactions, web pages, ebooks, audio, voice over internet protocol (VOIP) or other information may be located on the source computing device 402 and data packets can be sent through the tunneling interface 406 , encoding module and UDP/TCP layers as described above. Because the data packets passing through the tunneling interface 406 may be encoded using random linear network coding and sent via UDP this can increase the overall speed of the data packets being sent.
- VOIP voice over internet protocol
- the communication layering illustrated on the source computing device 402 may also exist on the destination computing device 420 .
- Data packets received by the destination computing device 420 can be processed through the communications layers in the reverse order that the encapsulation and decoding originally took place in order to obtain the actual data that was sent in the data packets.
- FIG. 5 is a flow diagram illustrating a method 500 for invoking a random linear network coding (RLNC) communications protocol between a client and server in a network.
- random linear network coding can be used to reduce network congestion by allowing (i) a receiver (e.g., a server or a client) to ignore lost data packets sent by a transmitter (e.g., the server or the client) and acknowledge the receipt of certain data packets, and (ii) a transmitter to avoid retransmitting data packets.
- the method 500 can be used to determine whether a client and a server support an RLNC communications protocol by encoding and decoding data packets using random linear network coding, and utilize the RLNC communications protocol when supported by both the client and the server.
- a server may receive a synchronize message sent by a client over a network requesting a network connection to the server.
- the synchronize message can contain an indication that the client supports the RLNC communications protocol.
- the indication can be included in the header of the synchronize message.
- the indication can be a RLNC protocol flag, a type-length-value (TLV), a cryptographic hash, or any other type of value or packet field used to indicate client support of the RLNC communications protocol.
- a transmission control protocol (TCP) layer installed on the client sets an indication (e.g., an RLNC protocol flag, TLV, cryptographic hash, etc.) in a header of the synchronize message to indicate that the client supports the RLNC communications protocol.
- TCP transmission control protocol
- the server analyzes the synchronize message for an indication that the client supports the RLNC communications protocol.
- a TCP layer installed on the server can be used by a processor of the server to analyze the synchronize message for the indication (e.g., an RLNC protocol flag, TLV, cryptographic hash, etc.) that the client supports the RLNC communications protocol.
- the header of the synchronize message can be parsed to determine whether a field in the header contains a value indicating client support of the RLNC communications protocol.
- the server may determine whether the client possesses valid authorization to use the RLNC communications protocol to send and receive data packets.
- the server sends an acknowledge message to the client indicating that the server supports the RLNC communications protocol.
- a TCP layer installed on the server may set a field value (e.g., an RLNC protocol flag, TLV, cryptographic hash, etc.) in the header of the acknowledge message to indicate server support for the RLNC communications protocol, and the acknowledge message may be sent to the client.
- the server may listen on a communications channel for data packets sent by the client using the RLNC communications protocol.
- the communications channel may be a dedicated communications channel, a set channel, or a defined channel.
- the client may send a connection request to communicate with the server using the communications channel, and after acknowledging the connection request, the client and server may send data over the communications channel using the RLNC communications protocol.
- the server may receive a finished message sent by the client, where the finished message may be sent in response to the client receiving the acknowledge message indicating that the server supports the RLNC communications protocol.
- the server may terminate the network connection with the client and open a dedicated network port to allow the client to send and receive data packets over the dedicated communications channel using the RLNC communications protocol.
- the server may continue to establish a network connection with the client using a default network protocol, such as a TCP/IP transmission protocol.
- a default network protocol such as a TCP/IP transmission protocol.
- the server may send an acknowledge message to the client indicating that the client’s synchronize message was received, and as in block 514 , the client and the server can send and receive data packets using the default network protocol.
- FIG. 6 is a flow diagram illustrating another example method 600 for invoking a random linear network coding (RLNC) communications protocol between a client and server in a network.
- the method can include, as in block 602 , a client sending a synchronize message to a server requesting a network connection with the server, wherein the synchronize message contains an indication that the client supports the RLNC communications protocol.
- RLNC random linear network coding
- the client receives an acknowledge message from the server, as in block 604 , and the client may analyze the message for an indication that the server supports the RLNC communications protocol, as in block 606 .
- the client may send a finished message to the server to close the network connection between the client and the server. For example, where a TCP/IP transmission protocol was used to open a TCP/IP network connection with the server, the client can send a finished message to the server to close the TCP/IP network connection to the server.
- the client may send a connection request to the server using a dedicated or defined communications channel associated with the RLNC communications protocol.
- a handshake process can be used to create a connection between the client and the server.
- a three-way handshake comprising a synchronize message, synchronize-acknowledge message, and an acknowledge message can be used to create a network connection between a client and server over a dedicated communications channel.
- data packets can be sent and received between the client and the server using the RLNC communications protocol and the dedicated communications channel.
- the server may ignore the indication in the synchronize message that the client supports the RLNC communications protocol. Accordingly, in response to the synchronize message, the server sends an acknowledge message to the client that does not contain an indication of server support for the RLNC communications protocol. Thus, returning to block 606 , the client may analyze the acknowledge message received from the server and determine in block 608 that the server does not support the RLNC communications protocol. As in block 614 , the client may continue to establish a network connection with the server using a default network protocol, such as a TCP/IP transmission protocol, and as in block 616 , the client and the server can send and receive data packets using the default network protocol.
- a default network protocol such as a TCP/IP transmission protocol
- FIG. 7 illustrates a computing device 710 on which modules of this technology may execute.
- a computing device 710 is illustrated on which a high level example of the technology may be executed.
- the computing device 710 may include one or more processors 712 that are in communication with memory devices 720 .
- the computing device 710 may include a local communication interface 718 for the components in the computing device 710 .
- the local communication interface may be a local data bus and/or any related address or control busses as may be desired.
- the memory device 720 may contain modules that are executable by the processor(s) 712 and data for the modules. Located in the memory device 720 are modules executable by the processor. For example, a network coding module 724 , a control module 726 , one or more application modules 728 , and other modules may be located in the memory device 720 . The modules may execute the functions described earlier. A data store 722 may also be located in the memory device 720 for storing data related to the modules and other applications along with an operating system that is executable by the processor(s) 712 .
- the computing device 710 may also have access to I/O (input/output) devices 714 that are usable by the computing device 710 .
- I/O input/output
- An example of an I/O device is a display screen 730 available to display output from the computing device 710 .
- Other known I/O device may be used with the computing device 710 as desired.
- Networking devices 716 and similar communication devices may be included in the computing device 710 .
- the networking devices 716 may be wired or wireless networking devices that connect to the internet, a LAN, WAN, or other computing network.
- the components or modules that are shown as being stored in the memory device 720 may be executed by the processor 712 .
- the term “executable” may mean a program file that is in a form that may be executed by a processor 712 .
- a program in a higher level language may be compiled into machine code in a format that may be loaded into a random access portion of the memory device 720 and executed by the processor 712 , or source code may be loaded by another executable program and interpreted to generate instructions in a random access portion of the memory to be executed by a processor.
- the executable program may be stored in any portion or component of the memory device 720 .
- the memory device 720 may be random access memory (RAM), read only memory (ROM), flash memory, a solid state drive, memory card, a hard drive, optical disk, floppy disk, magnetic tape, or any other memory components.
- the processor 712 may represent multiple processors and the memory 720 may represent multiple memory units that operate in parallel to the processing circuits. This may provide parallel processing channels for the processes and data in the system.
- the local interface 718 may be used as a network to facilitate communication between any of the multiple processors and multiple memories. The local interface 718 may use additional systems designed for coordinating communication such as load balancing, bulk data transfer, and similar systems.
- modules may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components.
- a module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
- Modules may also be implemented in software for execution by various types of processors.
- An identified module of executable code may, for instance, comprise one or more blocks of computer instructions, which may be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which comprise the module and achieve the stated purpose for the module when joined logically together.
- a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices.
- operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices.
- the modules may be passive or active, including agents operable to perform desired functions.
- Computer readable storage medium includes volatile and non-volatile, removable and non-removable media implemented with any technology for the storage of information such as computer readable instructions, data structures, program modules, or other data.
- Computer readable storage media include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other computer storage medium which can be used to store the desired information and described technology.
- the devices described herein may also contain communication connections or networking apparatus and networking connections that allow the devices to communicate with other devices.
- Communication connections are an example of communication media.
- Communication media typically embodies computer readable instructions, data structures, program modules and other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
- a “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
- communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared, and other wireless media.
- the term computer readable media as used herein includes communication media.
Abstract
A technology is provided for invoking a random linear network coding (RLNC) communications protocol between a client and server in a network. In one example, a synchronize message requesting a network connection to a server can contain an indication that a client supports the RLNC communications protocol to encode and decode data packets using random linear network coding. The server can analyze the synchronize message for the indication that the client supports the RLNC communications protocol and send an acknowledge message to the client indicating that the server supports the RLNC communications protocol. Thereafter, the server can listen on a communications channel for a connection request sent by the client to communicate with the server using the RLNC communications protocol.
Description
- This application is a continuation of U.S. Pat. Application No. 16/591,496, filed Oct. 2, 2019, which is incorporated herein by reference.
- Communications across computer networks have become a widely available form of communications. The communications can be between many forms of computing devices, including: mobile devices, servers, clients to servers, game consoles, desktop computers, laptops and a myriad of other computing devices. The form of data being sent in these communications usually takes the form of data packets which are transmitted between the computing devices.
- Data may be transmitted through the Internet using packets or chunks of information. Packet formatting and the method for delivering packets across the Internet are governed by the protocol known as TCP/IP (transmission control protocol / internet protocol). For a TCP data transmission to be completed, the recipient TCP layer may collect the packets and organize the packets in the order in which the packets were sent. If a packet is lost, the protocol interprets this as a sign that the network is congested - the transmission speed is immediately halved, and from there the packets speed attempts to increase again at a slow rate. This is beneficial in some situations and inefficient in other situations.
-
FIG. 1 is a sequence diagram that illustrates various operations associated with invoking a random linear network coding (RLNC) communications protocol between a client and server in a network. -
FIG. 2A is a block diagram illustrating an example of a system for communicating over a network using the RLNC communications protocol. -
FIG. 2B is a diagram of a data packet that includes an RLNC flag in a header of the data packet. -
FIG. 3 is block diagram that illustrates another example of a system that includes a server and clients configured to support the RLNC communications protocol. -
FIG. 4 is a block diagram illustrating an example of the technology using a tunneling interface and a random linear network coding to prepare data packets to be sent across a network. -
FIG. 5 is a flow diagram that illustrates an example method for invoking an RLNC communications protocol from a server perspective. -
FIG. 6 is a flow diagram illustrating another example method for invoking an RLNC communications protocol from a client perspective. -
FIG. 7 is block diagram illustrating an example of a computing device that may be used to execute a method that invokes the RLNC communications protocol between a client and server. - A technology is provided for invoking a random linear network coding (RLNC) communications protocol between a client and server in a network using data packets and data in a networking protocol. As explained in more detail later, random linear network coding can be used to reduce network congestion by allowing (i) a receiver (e.g., a server or a client) to ignore lost data packets sent by a transmitter (e.g., the server or the client) and acknowledge the receipt of certain data packets, (ii) a receiver to rebuild lost data packets sent by a transmitter, and (iii) a transmitter to avoid retransmitting data packets. In one example, invoking the RLNC communications protocol between a client and a server may include sending a synchronize (SYN) message from the client to the server requesting a network connection with the server, where the synchronize message indicates that the client supports the RLNC communications protocol. As part of receiving the message, the server may analyze the message for an indication (e.g., a protocol flag, type-length-value, etc.) that the client supports the RLNC communications protocol. In the case that the message indicates that the client supports the RLNC communications protocol, the server may send an acknowledge message in a synchronize-acknowledge packet or an acknowledge packet (e.g., in an SYN-ACK or ACK packet) to the client indicating that the server supports the RLNC communications protocol. Thereafter, the server may listen on a communications channel (e.g., UDP (User Datagram Protocol) port) for a connection request and/or encoded data packets from the client to communicate with the server using the RLNC communications protocol. The communication channel may be a dedicated or defined communications channel (e.g., a dedicated UDP port).
- To further describe the present technology, examples are now provided with reference to the figures.
FIG. 1 is a sequence diagram illustrating operations used to invoke an RLNC communications protocol between aclient 102 and aserver 104. Theclient 102 may be configured to support the RLNC communications protocol by encoding and decoding data packets (e.g., encoding or decoding the contents of data packets and portions of the packet headers as described later) using random linear network coding. Likewise, theserver 104 may be configured to support the RLNC communications protocol by decoding and encoding data packets using random linear network coding. - As shown, a
client 102 may send asynchronize message 110 to theserver 104 using a first communications channel 106 (e.g., a logical connection over a computer network) requesting a network connection with theserver 104. Thesynchronize message 110 may indicate that theclient 102 supports the RLNC communications protocol. For example, a header of thesynchronize message 110 can include a field containing an RLNC protocol flag, a type-length-value (TLV), a cryptographic hash, or another value or data field that indicates that theclient 102 supports the RLNC communications protocol. In one example, thesynchronize message 110 can be sent using a TCP/IP transmission protocol over the Internet, wherein thesynchronize message 110 requests a TCP/IP connection with theserver 104, and the header of thesynchronize message 110 includes a field value indicating to theserver 104 that theclient 102 is configured to encode and decode data packets using random linear network coding. - In response to receiving the
synchronize message 110 from theclient 102, theserver 104 may analyze thesynchronize message 110 for an indication that theclient 102 supports the RLNC communications protocol. For example, theserver 104 may analyze a header of thesynchronize message 110 to determine whether a designated field in the header contains a value (e.g., RLNC protocol flag, TLC, cryptographic hash, etc.) representing support of the RLNC communications protocol. In determining that thesynchronize message 110 indicates client support for the RLNC communications protocol, theserver 104 may send anacknowledge message 112 to theclient 102 using thefirst communications channel 106, where theacknowledge message 112 indicates that theserver 104 supports the RLNC communications protocol. For example, a header of theacknowledge message 112 may include a field containing an RLNC protocol flag, a TLV, a cryptographic hash, or another value indicating that theserver 104 supports the RLNC communications protocol. In one example, theserver 104 may obtain an identifier used for the client 102 (e.g., an internet protocol (IP) address or media access control (MAC) address) to allow identification of data packets sent by theclient 102 using the RLNC communications protocol to theserver 104 as being associated with theclient 102. - When received by the
client 102, theacknowledge message 112 may be analyzed for an indication that theserver 104 supports the RLNC communications protocol. For example, theclient 102 may analyze a header of theacknowledge message 112 to determine whether a designated field in the header contains a value (e.g., RLNC protocol flag, TLC, cryptographic hash, etc.) representing server support of the RLNC communications protocol. - After determining that the
server 104 supports the RLNC communications protocol via the indication in theacknowledge message 112, theclient 102 may initiate termination of thefirst communications channel 106 to allow asecond communications channel 108 to be opened for transmitting data over TCP/IP using the RLNC communications protocol. In one example, theclient 102 may initiate termination of the network connection between theclient 102 and theserver 104 by sending afinish message 114 to theserver 104. In response to receiving thefinish message 114, theserver 104 may close the network connection between theserver 104 and theclient 102, thereby closing thefirst communications channel 106. In examples where thefirst communications channel 106 is implemented using a TCP/IP protocol, a four-way handshake may be used to close thefirst communications channel 106, wherein theclient 102 and theserver 104 independently terminate the network connection by transmitting finish messages to each other and acknowledging the finish messages, and waiting for a timeout to occur before closing thefirst communications channel 106. In another example, theclient 102 may abandon a request to connect to theserver 104 using the TCP/IP protocol by not transmitting a finish message after determining that theserver 104 supports the RLNC communications protocol and theclient 104 can start sending encoded data packets to theserver 104 via asecond communications channel 108, as explained below. - The
client 102 may encodedata packets 116 for transmission to theserver 104 using random linear network coding and theclient 102 may send the encodeddata packets 116 to theserver 104 using a second communications channel 108 (e.g., a UDP communications channel). For example, after determining that theclient 102 supports the RLNC communications protocol, theserver 104 may open a network port (e.g., UDP port) for communicating with theclient 102 using data packets encoded in the RLNC communications protocol and listen fordata packets 116 sent from theclient 102. The network port may be a dedicated or defined network port. Theclient 102 may encodedata packets 116 using random linear network coding and send thedata packets 116 to the network port. Theserver 104 may receive thedata packets 116 sent from theclient 102 over thesecond communications channel 108, and theserver 104 may decode thedata packets 116 using random linear network coding. Likewise, theserver 104 may encode data packets using random linear network coding and send thedata packets 116 to theclient 102 via the network port, and theclient 102 may decode thedata packets 116 using random linear network coding. - In cases where a
server 104 does not support the RLNC communications protocol, theserver 104 may ignore an indication (e.g., RLNC protocol flag) in asynchronize message 110 that aclient 102 supports the RLNC communications protocol, and network communication between theclient 102 and theserver 104 may proceed using a network protocol used to send thesynchronize message 110 to theserver 104. As an illustration, aclient 102 may initially use a TCP/IP transmission protocol to send asynchronize message 110 indicating client support for the RLNC communications protocol to aserver 104. If theserver 104 is not configured to support the RLNC communications protocol, theserver 104 may ignore the indication of client support for the RLNC communications protocol in thesynchronize message 110 and proceed with establishing a network connection using the TCP/IP protocol for communications between theclient 102 and theserver 104. -
FIG. 2A is a block diagram illustrating one high level configuration of asystem 200 for communicating over anetwork 210 using the RLNC communications protocol. Thesystem 200 may include aserver 202 and a plurality ofclients 204 configured to use the RLNC communications protocol to encode and decode data packets using random linear network coding. Theserver 202 may be any computer accessible by aclient 204 over anetwork 210, including but not limited to a service provider (e.g., “cloud”) server, gateway, router, mainframe server, proxy server, etc. Thenetwork 210 connecting theserver 202 and theclient 204 may include a local area network (“LAN”), a wide area network (“WAN”), a wireless network, a cellular network, the Internet, or the like. - A
client 204 may be an electronic device or a software application running on a computing device, including a mobile electronic device, a smartphone, a tablet computer, a laptop computer, a desktop computer, a server, a digital media player (e.g., Chromecast, Apple TV, etc.), a network appliance, a gaming console (e.g., PlayStation, Xbox, etc.), or the like. Aclient 204 implemented as a software application may include a VPN (virtual private network) client and/or an application running on a mobile electronic device. - A
server 202 and aclient 204 may be capable of encoding data packets using random linear network coding, and sending and receiving the data packets, as well as receiving and decoding data packets encoded using random linear network coding. Random linear network coding enables (i) a receiver (e.g., theserver 202 or the client 204) to ignore lost data packets sent by the transmitter (e.g., theserver 202 or the client 204) and acknowledge the receipt of certain data packets and (ii) a transmitter to avoid retransmitting data packets, thus reducing network congestion. - A
server 202 and aclient 204 may contain anetwork coding module 206a-b configured to encode data packets using random linear network coding, and decode data packets encoded using random linear network coding. Traditional TCP/IP transmission divides data content into sequentially numbered packets and sends each packet with its accompanying sequence number. If a packet (i) does not arrive at its destination and therefore an acknowledgement is not sent to the origin or (ii) an acknowledgement is sent but does not arrive at the origin within a specific window of time, the packet is resent. - In random linear network coding (RLNC), data is divided into data blocks and encoded into coded data packets. Each coded data packet is formed by multiplying each data block with a constant chosen randomly from a finite range of constants and then combining the results. Thus, each coded data packet can be represented by a linear equation in the following form:
-
-
-
- Here, CDP represents a “coded data packet,” DB represents a “data block,” and C represents a randomly chosen constant from a finite range of constants. The randomly chosen constant Ck,m multiplied with each data block is encoded in the headers of the coded data packets in which they are used. Assuming there are n data blocks to be sent, coded data packets are sent continuously until n distinct (i.e., linearly independent) coded data packets are received and acknowledged. Once n distinct coded data packets are received, they can be decoded to find the n data blocks. Alternatively, some individual coded data packets can be decoded as they are received. For example, given m distinct coded data packets encoded using a total of p unique data blocks, where m ≥ p, it is possible to decode the m coded data packets to find the p data blocks.
- The
server 202 and theclient 204 may contain acontrol module 208 a-b. Thecontrol module 208 a-b may be configured to cause theserver 202 and theclient 204 to send and receive data packets between each other. Thecontrol module 208 a-b may use a default network protocol for a network connection, and utilize a RLNC communications protocol when the RLNC communications protocol is supported by both aserver 202 and aclient 204. In one example, thecontrol module 208 a-b may communicate using a TCP layer included in a TCP/IP stack (e.g., a set of TCP/IP network protocol layers) configured to insert an indication of support for the RLNC communications protocol in a header of a packet, and thecontrol module 208 a-b may determine whether a header of a received packet contains an indication of support for the RLNC communications protocol. - The
control module 208 b located on aclient 204 may initiate a network connection with aserver 202 by causing a synchronize message to be sent from theclient 204 to theserver 202 using a common network protocol, such as a TCP/IP protocol or another networking protocol. The synchronize message can include an indication that theclient 204 supports an RLNC communications protocol by encoding and decoding data packets using random linear network coding. The indication in the synchronize message sent from theclient 204 can be an RLNC protocol flag, a type-length-value (TLV), a cryptographic hash, or another value which indicates that theclient 204 supports the RLNC communications protocol. As an illustration,FIG. 2A illustrates anexample data packet 210 that includes anRLNC flag 212 used to indicate client support of the RLNC communications protocol. - The
control module 208 b on theclient 204 shown inFIG. 2A may analyze an acknowledge message received in response to the client’s synchronize message for an indication that theserver 202 supports the RLNC communications protocol, and if the acknowledge message indicates server support of the RLNC communications protocol, thecontrol module 208 b on theclient 204 may initiate closing of the network connection between theclient 204 and theserver 202, and, in some examples, request opening of a communications channel between theclient 204 and theserver 202 for sending data to theserver 202 using the RLNC communications protocol. Thecontrol module 208 b may implement the RLNC communications protocol by instructing thenetwork coding module 206 b to encode data packets using random linear network coding, and thecontrol module 208 b may cause the encoded data packets to be sent to theserver 202 using the communications channel. In one example, the communications channel may be a dedicated communications channel, which can include a network connection between theserver 202 and theclient 204 using a communication endpoint (e.g., network port) dedicated to RLNC communications protocol traffic. - The
control module 208 a located on theserver 202 may analyze a synchronize message received from aclient 204 for an indication that theclient 204 supports the RLNC communications protocol, and if theclient 204 supports the RLNC communications protocol, thecontrol module 208 a causes an acknowledge message to be sent to theclient 204 indicating that theserver 202 also supports the RLNC communications protocol. Thereafter, thecontrol module 208 a on theserver 202 may listen on a communications channel for data packets sent from theclient 204 which are encoded using the RLNC communications protocol. For example, thecontrol module 208 a may open a dedicated or defined network port to enable a network connection with theclient 204 and to send and receive data packets using the RLNC communications protocol over the network connection. Also, after sending the acknowledge message to theclient 204 indicating server support for the RLNC communications protocol, theserver 202 may receive a finish message from theclient 204 indicating that theclient 204 is done sending data using a network protocol (e.g., a TCP/IP transmission protocol) that was used to send the first synchronize message. In response to receiving the finish message, thecontrol module 208 a may acknowledge that the finish message was received and that thecontrol module 208 a is terminating the network connection between theserver 202 and theclient 204 by sending a final acknowledge message to theclient 204. - As mentioned, the
control module 208 a on theserver 202 may listen on a communications channel for data packets encoded using the RLNC communications protocol. In response to receiving the encoded data packets on the communications channel, thecontrol module 208 a instructs thenetwork coding module 206 a to decode the data packets using random linear network coding. Thecontrol module 208 a then causes data obtained from the decoded data packets to be made available to an intended recipient of the data on theclient 204, such as an application, process, service, or the like. -
FIG. 3 is a block diagram illustrating another example of asystem 300 that includes aserver 202 andclients 204 a-n configured to support the RLNC communications protocol. Theserver 202 may include thenetwork coding module 206 and thecontrol module 208 described earlier, as well as avalidation module 312 and a datatraffic management module 310. The datatraffic management module 310, thecontrol module 208, thenetwork coding module 206, thevalidation module 312 may each be in communication with each other, and communication may occur over one or more types of communication frameworks or communication networks. The sever 202 may include, for example, mechanical, electrical and signaling circuitry needed to connect themodules 310/208/206/312 to each other for communication and/or sending and/or receiving data. - The
validation module 312 may be configured to authenticate aclient 204 a-n and determine whether theclient 204 a-n possesses valid authorization to encode and decode data packets using random linear network encoding. In one embodiment, thecontrol module 208 causes theserver 202 and aclient 204 a-n to send to and receive from each other data packets encoded using random linear network (RLNC) coding in response to thevalidation module 312 authenticating theclient 204 a-n and determining that theclient 204 a-n possesses valid authorization. Adatabase 314 can be used to store a unique identifier for eachclient 204 a-n. This identifier can be a unique alphanumeric code, picture, or other authentication token. For example, the stored identifier may be an encrypted hash of a client’s MAC address. Thedatabase 314 can also store an indicator of whether aclient 204 a-n is authorized to encode or decode data packets using random linear network coding. In another embodiment, thecontrol module 208 causes theserver 202 and theclient 204 a-n to stop sending and receiving data packets encoded using random linear network coding between each other in response to thevalidation module 312 determining that theclient 204 a-n lacks valid authorization or a valid license. - The data
traffic management module 310 may be configured to measure characteristics of a data stream and analyze the characteristics of the data stream to determine whether to continue using the RLNC communications protocol to transmit the data stream. Characteristics of the data stream can include, but is not limited to, a data loss rate at one or more time periods and a data throughput rate. In one example configuration, the datatraffic management module 310 analyzes and/or determines a data loss rate pertaining to a data stream between theserver 202 and aclient 204 a-n. A data stream includes data packets sent and received between theserver 202 and aclient 204 a-n. In one example, the datatraffic management module 310 can simultaneously determine the data loss rate pertaining to multiple data streams between theserver 202 andmultiple clients 204 a-n. The data loss rate pertaining to a data stream may be defined in different ways. In one example, the data loss rate may be the total number of data packets sent by either (i) theserver 202, (ii) aclient 204 a-n, or (iii) both theserver 202 and theclient 204 a-n, but not received by theserver 202 and/or theclient 204 a-n over a set period of time. For example, the data loss rate may be, during a one second interval, the total number of data packets sent by aclient 204 a-n to theserver 202 that were not received by theserver 202. In another embodiment, the data loss rate is the total number of data packets resent by (i) theserver 202, (ii) theclient 204 a-n, or (iii) both theserver 202 and theclient 204 a-n over a set period of time. An example of the data loss rate using this definition may be, during a one second interval, the total number of data packets resent byserver 202 to theclient 204 a-n. - A data loss rate above a certain threshold can have an adverse impact on the performance of real-time software applications running on the
server 202 and/or aclient 204 a-n, including but not limited to video teleconferencing, video streaming, and graphic and network heavy online multiplayer games. Thus, measuring the data loss rate between theserver 202 and aclient 204 a-n can be used to identify when network congestion is severely impairing the functionality of these applications. To more accurately measure the average data loss rate between theserver 202 and aclient 204 a-n, it may be advantageous to vary the window of time during which the datatraffic management module 310 counts the total number of data packets lost, receives requests to retransmit data packets, or resends data packets. Thus, for example, the datatraffic management module 310 may count the total number of data packets lost between theserver 202 and aclient 204 a-n over a five second interval. A longer sampling window may give the data traffic management module 310 a better understanding of the state of congestion within a network between theserver 202 and aclient 204 a-n by better averaging the impact of momentary spikes or dips in network congestion. A shorter sampling window may allow for a quicker reaction to changes in network congestion. - The data
traffic management module 310 may determine the data loss rate pertaining to a data stream between theserver 202 and aclient 204 a-n either continuously, at regular intervals (e.g., every 30 seconds), and/or at scheduled times (e.g., during peak network usage hours). Determining the data loss rate pertaining to a data stream continuously allows the datatraffic management module 310 to maintain a moving window average of the data loss rate. For example, the data loss rate determined by the datatraffic management module 310 may be the average of the most recent three data loss rates measured. In another example, the data loss rate determined by the datatraffic management module 310 may be the weighted average of the most recent five data loss rates measured, with the more recently measured data loss rates weighted more heavily. - Encoding data packets using random linear network coding can increase overhead in terms of both packet header size and time spent encoding and decoding packet payloads, as well as an increase in the size of the coded data packet header to include the randomly chosen constants. The overhead incurred is typically small compared to the efficiency gained by the transmitter (e.g., the
server 202 or theclient 204 a-n) not having to retransmit lost coded data packets and the receiver (e.g., theserver 202 or theclient 204 a-n) only having to acknowledge the receipt of every distinct coded data packet. However, in certain scenarios, encoding data packets using random linear network coding will actually increase network congestion and result in lower data throughput rates. Since it is possible that not all coded data packets created by random linear network coding are distinct, the transmitter may have to send more than n coded data packets in order for n distinct coded data packets to be received. Thus, if network congestion is low and there is very little to no packet loss, sending coded data packets encoded using random linear network coding may use more network bandwidth compared to encoding and sending data packets using another network protocol like the traditional TCP/IP transmission protocol. - The present technology allows for determining whether to continue to use the RLNC communications protocol based on characteristics of a data stream being transmitted between the
server 202 and aclient 204 a-n. As one example, the datatraffic management module 310 can determine that a data loss rate is lower than a threshold, and in response, thecontrol module 208 causes theserver 202 and aclient 204 a-n to stop sending and receiving data packets encoded using random linear network coding between each other. As another example, the datatraffic management module 310 can analyze and/or determine a data throughput rate pertaining to a data stream between theserver 202 and aclient 204 a-n. The datatraffic management module 310 can simultaneously determine data throughput rates pertaining to multiple data streams between theserver 202 andmultiple clients 204 a-n. The datatraffic management module 310 can determine that a data throughput rate is lower than a threshold, and in response, thecontrol module 208 can instruct theserver 202 and aclient 204 a-n to stop sending and receiving data packets encoded using random linear network coding. - In some examples, the data
traffic management module 310 can determine a data loss rate pertaining to a data stream at various times (e.g., 8 a.m. to 5 p.m., day, week, month, Mondays, weekends, New Year’s Day) and/or a data throughput rate (e.g., an amount of data transmitted in a given time period) pertaining to a data stream at various times. The datatraffic management module 310 can dynamically and/or automatically adjust thresholds and/or set the thresholds used to determine whether to continue to utilize the RLNC communications protocol based on a data loss rate and/or data throughput rate pertaining to a data stream. As an example, the thresholds may be dynamically and/or automatically adjusted and/or set to data loss rates for real-time load balancing of various modules or applications of theserver 202 and/orclient 204 a-n while maintaining the highest data throughput rates between theserver 202 and theclient 204 a-n. - As part of a determination to stop sending and receiving data packets encoded using random linear network coding, the
control module 208 may cause a message to be sent to aclient 204 a-n that instructs theclient 204 a-n to stop using the RLNC communications protocol, and thecontrol module 208 may cause a data stream to be sent to theclient 204 a-n using another network protocol, such as a TCP/IP transmission protocol. -
FIG. 4 illustrates anexample system 400 that can include anapplication 404 on asource computing device 402 that sends data packets using the RLNC communications protocol through anetwork 414 such as the Internet (e.g., through a hard wired connection or using a wireless connection such as WI-FI) or a cellular network which then communicates through the Internet or another packet switched network. A source computing device 402 (e.g., server) can be configured to analyze a synchronize message received from a destination computing device 420 (e.g., client) for an indication that the destination computing device 420 supports the RLNC communications protocol to encode and decode data packets using random linear network coding. If the synchronize message indicates support of the RLNC communications protocol, thesource device 402 sends an acknowledge message to the destination device 420 indicating that thesource device 402 supports the RLNC communications protocol. In the scenario where thesource computing device 402 and the destination computing device 420 support the RLNC communications protocol, data packets sent between thesource computing device 402 and the destination computing device 420 can be encapsulated using a tunneling protocol. - The
application 404 can be located in a memory device of asource computing device 402 configured to send data packets over acomputer network 414. For example, theapplication 404 may be a content server executing on a hardware layer that is configured to deliver streaming video, streaming audio, text, web pages, or other content. Alternatively, theapplication 404 may be a client application requesting content. - A
tunneling interface 406 can be configured to receive the data packets from theapplication 404 and encapsulate the data packets using the tunneling protocol. In one example, thetunneling interface 406 may be a virtual private network (VPN), TAP (network tap) interface, a TUN (network TUNnel) interface, or another type oftunneling interface 406. - The use of a
tunneling interface 406 or VPN interface may enable thesource computing device 402 to use the RLNC communications protocol with multiple applications accessing thesame tunneling interface 406 on a device (e.g., a mobile device, desktop device, laptop, etc.) or in embedded hardware without specifically adding an RLNC layer or processing into each application. Further, eachapplication 404 may setup or access the application’s ownseparate tunneling interface 406 or VPN network interface. This way the traffic for theapplication 404 can be funneled through thetunneling interface 406 and may be connected with a single receiving device or server through thetunneling interface 406. Alternatively, a group ofapplications 404 may share atunneling interface 406 that is destined for one or more destination computing devices 420 within a virtualized network or physical data center. - While a VPN interface is often encrypted, the use of encryption with the
tunneling interface 406 may be optional as illustrated by theencryption layer 408 shown with dotted lines. Packets from the tunneling layer can be encoded and decoded using random linear network coding with or without encryption. Therefore, in some configurations, if a user or application designer does not want the extra overhead of encryption but wants packet error correction using random linear network coding, such a configuration is available. The VPN interface may be used because the network traffic from multiple applications can be funneled through the interface. - Once data packets have been encapsulated in the tunneling protocol, an
encoding module 410 or encoder may receive the encapsulated packets and encode the data packets from thetunneling interface 406 using random linear network coding to form coded data packets. Encoding the data packets using random linear network coding may make the group of data packets resistant to data packet loss and increase the speed of the data packet transmissions because lost data packets are not re-transmitted but are re-constructed at the destination computing device 420 or receiving software. - A UDP/TCP (user datagram protocol/transmission control protocol)
layer 412 can be configured to encapsulate and send the encoded data packets over the Internet using UDP (user datagram protocol). Sending the packets using UDP can increase the speed of transmission of the data packets, but UDP does not guarantee the delivery of the data packets. Random linear network coding may be able to compensate for any packets that are lost by mathematically reconstructing the lost information on the destination computing device 420. The UDP packets can contain encoded TCP packets to transport the packets from the encoder to the destination decoder. If any control packets (e.g., with random linear network coding mathematical coefficients) are necessary to perform lost packet reconstruction, these packets can be sent using the TCP or UDP protocol. - The encoded data packets may be sent across a
network 414, and the data packets may be received at a destination computing device 420. Once the data packets are received at the destination computing device 420, the data packets may be decoded using random linear network coding and encapsulation may be removed when the data packets arrive at the destination tunneling protocol layer (e.g., destination virtual network). In one example, this virtual network can be a virtual private network formed between two applications. - The
source computing device 402 may transfer any type of data that anapplication 404 may be configured to send to a destination computing device 420. For example, files, videos, database transactions, web pages, ebooks, audio, voice over internet protocol (VOIP) or other information may be located on thesource computing device 402 and data packets can be sent through thetunneling interface 406, encoding module and UDP/TCP layers as described above. Because the data packets passing through thetunneling interface 406 may be encoded using random linear network coding and sent via UDP this can increase the overall speed of the data packets being sent. - The communication layering illustrated on the
source computing device 402 may also exist on the destination computing device 420. Data packets received by the destination computing device 420 can be processed through the communications layers in the reverse order that the encapsulation and decoding originally took place in order to obtain the actual data that was sent in the data packets. -
FIG. 5 is a flow diagram illustrating amethod 500 for invoking a random linear network coding (RLNC) communications protocol between a client and server in a network. As explained earlier, random linear network coding can be used to reduce network congestion by allowing (i) a receiver (e.g., a server or a client) to ignore lost data packets sent by a transmitter (e.g., the server or the client) and acknowledge the receipt of certain data packets, and (ii) a transmitter to avoid retransmitting data packets. Themethod 500 can be used to determine whether a client and a server support an RLNC communications protocol by encoding and decoding data packets using random linear network coding, and utilize the RLNC communications protocol when supported by both the client and the server. - As in
block 502, a server may receive a synchronize message sent by a client over a network requesting a network connection to the server. The synchronize message can contain an indication that the client supports the RLNC communications protocol. The indication can be included in the header of the synchronize message. For example, the indication can be a RLNC protocol flag, a type-length-value (TLV), a cryptographic hash, or any other type of value or packet field used to indicate client support of the RLNC communications protocol. In one example, a transmission control protocol (TCP) layer installed on the client sets an indication (e.g., an RLNC protocol flag, TLV, cryptographic hash, etc.) in a header of the synchronize message to indicate that the client supports the RLNC communications protocol. - As in
block 504, the server analyzes the synchronize message for an indication that the client supports the RLNC communications protocol. In one example, a TCP layer installed on the server can be used by a processor of the server to analyze the synchronize message for the indication (e.g., an RLNC protocol flag, TLV, cryptographic hash, etc.) that the client supports the RLNC communications protocol. For example, the header of the synchronize message can be parsed to determine whether a field in the header contains a value indicating client support of the RLNC communications protocol. In one example, as described earlier in relation toFIG. 3 , the server may determine whether the client possesses valid authorization to use the RLNC communications protocol to send and receive data packets. - As in block 506, in the case that the synchronize message received from the client contains an indication that the client supports the RLNC communications protocol, then as in
block 508, the server sends an acknowledge message to the client indicating that the server supports the RLNC communications protocol. For example, a TCP layer installed on the server may set a field value (e.g., an RLNC protocol flag, TLV, cryptographic hash, etc.) in the header of the acknowledge message to indicate server support for the RLNC communications protocol, and the acknowledge message may be sent to the client. - After sending the acknowledge message to the client, the server, as in
block 510, may listen on a communications channel for data packets sent by the client using the RLNC communications protocol. The communications channel may be a dedicated communications channel, a set channel, or a defined channel. In one example, the client may send a connection request to communicate with the server using the communications channel, and after acknowledging the connection request, the client and server may send data over the communications channel using the RLNC communications protocol. - In some examples, the server may receive a finished message sent by the client, where the finished message may be sent in response to the client receiving the acknowledge message indicating that the server supports the RLNC communications protocol. In response to receiving the finished message, the server may terminate the network connection with the client and open a dedicated network port to allow the client to send and receive data packets over the dedicated communications channel using the RLNC communications protocol.
- In the case that the client does not support the RLNC communications protocol, the server, as in
block 512, may continue to establish a network connection with the client using a default network protocol, such as a TCP/IP transmission protocol. For example, the server may send an acknowledge message to the client indicating that the client’s synchronize message was received, and as inblock 514, the client and the server can send and receive data packets using the default network protocol. -
FIG. 6 is a flow diagram illustrating anotherexample method 600 for invoking a random linear network coding (RLNC) communications protocol between a client and server in a network. The method can include, as inblock 602, a client sending a synchronize message to a server requesting a network connection with the server, wherein the synchronize message contains an indication that the client supports the RLNC communications protocol. - In response to the synchronize message sent to the server, the client receives an acknowledge message from the server, as in
block 604, and the client may analyze the message for an indication that the server supports the RLNC communications protocol, as inblock 606. As in block 608, in the case that the acknowledge message indicates that the server supports the RLNC communications protocol, then as inblock 610, the client may send a finished message to the server to close the network connection between the client and the server. For example, where a TCP/IP transmission protocol was used to open a TCP/IP network connection with the server, the client can send a finished message to the server to close the TCP/IP network connection to the server. - After sending the finished message to the server, the client, as in
block 612, may send a connection request to the server using a dedicated or defined communications channel associated with the RLNC communications protocol. In one example, a handshake process can be used to create a connection between the client and the server. As a non-limiting example, a three-way handshake comprising a synchronize message, synchronize-acknowledge message, and an acknowledge message can be used to create a network connection between a client and server over a dedicated communications channel. Thereafter, as inblock 616, data packets can be sent and received between the client and the server using the RLNC communications protocol and the dedicated communications channel. - In the case that the server does not support the RLNC communications protocol, the server may ignore the indication in the synchronize message that the client supports the RLNC communications protocol. Accordingly, in response to the synchronize message, the server sends an acknowledge message to the client that does not contain an indication of server support for the RLNC communications protocol. Thus, returning to block 606, the client may analyze the acknowledge message received from the server and determine in block 608 that the server does not support the RLNC communications protocol. As in
block 614, the client may continue to establish a network connection with the server using a default network protocol, such as a TCP/IP transmission protocol, and as inblock 616, the client and the server can send and receive data packets using the default network protocol. -
FIG. 7 illustrates acomputing device 710 on which modules of this technology may execute. Acomputing device 710 is illustrated on which a high level example of the technology may be executed. Thecomputing device 710 may include one ormore processors 712 that are in communication withmemory devices 720. Thecomputing device 710 may include alocal communication interface 718 for the components in thecomputing device 710. For example, the local communication interface may be a local data bus and/or any related address or control busses as may be desired. - The
memory device 720 may contain modules that are executable by the processor(s) 712 and data for the modules. Located in thememory device 720 are modules executable by the processor. For example, anetwork coding module 724, acontrol module 726, one ormore application modules 728, and other modules may be located in thememory device 720. The modules may execute the functions described earlier. Adata store 722 may also be located in thememory device 720 for storing data related to the modules and other applications along with an operating system that is executable by the processor(s) 712. - Other applications may also be stored in the
memory device 720 and may be executable by the processor(s) 712. Components or modules discussed in this description that may be implemented in the form of software using high programming level languages that are compiled, interpreted or executed using a hybrid of the methods. - The
computing device 710 may also have access to I/O (input/output)devices 714 that are usable by thecomputing device 710. An example of an I/O device is adisplay screen 730 available to display output from thecomputing device 710. Other known I/O device may be used with thecomputing device 710 as desired.Networking devices 716 and similar communication devices may be included in thecomputing device 710. Thenetworking devices 716 may be wired or wireless networking devices that connect to the internet, a LAN, WAN, or other computing network. - The components or modules that are shown as being stored in the
memory device 720 may be executed by theprocessor 712. The term “executable” may mean a program file that is in a form that may be executed by aprocessor 712. For example, a program in a higher level language may be compiled into machine code in a format that may be loaded into a random access portion of thememory device 720 and executed by theprocessor 712, or source code may be loaded by another executable program and interpreted to generate instructions in a random access portion of the memory to be executed by a processor. The executable program may be stored in any portion or component of thememory device 720. For example, thememory device 720 may be random access memory (RAM), read only memory (ROM), flash memory, a solid state drive, memory card, a hard drive, optical disk, floppy disk, magnetic tape, or any other memory components. - The
processor 712 may represent multiple processors and thememory 720 may represent multiple memory units that operate in parallel to the processing circuits. This may provide parallel processing channels for the processes and data in the system. Thelocal interface 718 may be used as a network to facilitate communication between any of the multiple processors and multiple memories. Thelocal interface 718 may use additional systems designed for coordinating communication such as load balancing, bulk data transfer, and similar systems. - While the flowcharts presented for this technology may imply a specific order of execution, the order of execution may differ from what is illustrated. For example, the order of two more blocks may be rearranged relative to the order shown. Further, two or more blocks shown in succession may be executed in parallel or with partial parallelization. In some configurations, one or more blocks shown in the flow chart may be omitted or skipped. Any number of counters, state variables, warning semaphores, or messages might be added to the logical flow for purposes of enhanced utility, accounting, performance, measurement, troubleshooting or for similar reasons.
- Some of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
- Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more blocks of computer instructions, which may be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which comprise the module and achieve the stated purpose for the module when joined logically together.
- Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices. The modules may be passive or active, including agents operable to perform desired functions.
- The technology described here can also be stored on a computer readable storage medium that includes volatile and non-volatile, removable and non-removable media implemented with any technology for the storage of information such as computer readable instructions, data structures, program modules, or other data. Computer readable storage media include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other computer storage medium which can be used to store the desired information and described technology.
- The devices described herein may also contain communication connections or networking apparatus and networking connections that allow the devices to communicate with other devices. Communication connections are an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules and other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. A “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared, and other wireless media. The term computer readable media as used herein includes communication media.
- Reference was made to the examples illustrated in the drawings, and specific language was used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the technology is thereby intended. Alterations and further modifications of the features illustrated herein, and additional applications of the examples as illustrated herein, which would occur to one skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the description.
- Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more examples. In the preceding description, numerous specific details were provided, such as examples of various configurations to provide a thorough understanding of examples of the described technology. One skilled in the relevant art will recognize, however, that the technology can be practiced without one or more of the specific details, or with other methods, components, devices, etc. In other instances, well-known structures or operations are not shown or described in detail to avoid obscuring aspects of the technology.
- Although the subject matter has been described in language specific to structural features and/or operations, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features and operations described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. Numerous modifications and alternative arrangements can be devised without departing from the spirit and scope of the described technology.
Claims (20)
1. A system for invoking a random linear network coding (RLNC) communications protocol between a client and server in a network, comprising:
at least one processor;
a memory device including instructions that, when executed by the at least one processor, cause the system to:
receive a synchronize message sent by the client over the network requesting a network connection to the server;
analyze the synchronize message for the indication that the client supports the RLNC communications protocol to determine whether the synchronize message contains an indication that the client supports the RLNC communications protocol to encode and decode data packets using random linear network coding;
send an acknowledge message to the client indicating that the server supports the RLNC communications protocol; and
listen on a communications channel for the data packets sent by the client to the server using the RLNC communications protocol.
2. The system in claim 1 , wherein the synchronize message is analyzed to identify an RLNC protocol flag which indicates that the client supports the RLNC communications protocol.
3. The system in claim 1 , wherein the synchronize message is analyzed to identify a type-length-value (TLV) included in the synchronize message that has a value indicating that the client supports the RLNC communications protocol.
4. The system in claim 1 , wherein the client sets an RLNC protocol flag in a header of the synchronize message to indicate that the client supports the RLNC communications protocol.
5. The system in claim 1 , wherein the server analyzes the synchronize message for an RLNC protocol flag that indicates that the client supports the RLNC communications protocol, and sets the RLNC protocol flag in the acknowledge message to indicate that the server supports the RLNC communications protocol.
6. The system in claim 1 , wherein the memory device further includes instructions that, when executed by the at least one processor, cause the system to determine whether the client possesses valid authorization to use the RLNC communications protocol to send and receive data packets.
7. The system in claim 1 , wherein the memory device further includes instructions that, when executed by the at least one processor, cause the system to:
receive a finished message sent by the client, where the finished message is sent in response to the client receiving the acknowledge message indicating that the server supports the RLNC communications protocol; and
terminate the network connection with the client.
8. The system in claim 1 , wherein data packets sent between the client and the server are encapsulated using a tunneling protocol.
9. A computer implemented method, comprising:
receiving a synchronize message from a client requesting a transmission control protocol (TCP) network connection to a server;
analyzing the synchronize message for an indication that the client supports a random linear network coding (RLNC) communications protocol to encode and decode data packets using random linear network coding;
sending an acknowledge message to the client indicating that the server supports the RLNC communications protocol by encoding and decoding data packets using random linear network coding;
terminating the TCP network connection with the client; and
establishing a network connection with the client to use the RLNC communications protocol to send and receive data packets.
10. The method in claim 9 , wherein analyzing the synchronize message for the indication that the client supports the RLNC communications protocol further comprises analyzing a header of the synchronize message to identify an RLNC protocol flag which indicates that the client supports the RLNC communications protocol.
11. The method in claim 9 , wherein analyzing the synchronize message for the indication that the client supports the RLNC communications protocol further comprises identifying a type-length-value (TLV) included in the synchronize message that has a value indicating that the client supports the RLNC communications protocol.
12. The method in claim 9 , wherein terminating the TCP network connection with the client further comprises receiving a finished message sent by the client requesting that the TCP network connection be terminated.
13. The method in claim 9 , further comprising opening a network port to allow the network connection with the client and to send and receive data packets using the RLNC communications protocol over the network connection.
14. The method in claim 9 , further comprising:
measuring characteristics of a data stream comprising data packets transmitted between the server and the client; and
analyzing the characteristics of the data stream to determine whether to continue using the RLNC communications protocol to transmit the data stream.
15. The method in claim 14 , further comprising:
sending a message to the client that instructs the client to stop using the RLNC communications protocol; and
sending the data stream using a TCP protocol.
16. A non-transitory machine readable storage medium including instructions embodied thereon, wherein the instructions, when executed by at least one processor:
send, by a client, a synchronize message to a server over a network requesting to connect to the server over a network, wherein the synchronize message contains an indication that the client supports a random linear network coding (RLNC) communications protocol to encode and decode data packets using random linear network coding;
receive an acknowledge message from the server containing an indication that the server supports the RLNC communications protocol; and
send the data packets over the network to the server using the RLNC communications protocol.
17. The non-transitory machine readable storage medium in claim 16 , wherein the synchronize message and the acknowledge message contain an RLNC protocol flag which indicates support of the RLNC communications protocol.
18. The non-transitory machine readable storage medium in claim 17 , wherein the client sets an RLNC protocol flag in a header of the synchronize message to indicate that the client supports the RLNC communications protocol.
19. The non-transitory machine readable storage medium in claim 17 , wherein a transmission control protocol (TCP) layer installed on the server is configured to:
determine, at the server, whether the RLNC protocol flag in the synchronize message received from the client indicates that the client supports the RLNC communications protocol, and
set the RLNC protocol flag in the acknowledge message to indicate that the server supports the RLNC communications protocol when the client supports the RLNC communications protocol.
20. The non-transitory machine readable storage medium in claim 16 , wherein the data packets are sent to the server using a user datagram protocol (UDP) communications channel dedicated for transmitting data packets using the RLNC communications protocol.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18/065,375 US20230188628A1 (en) | 2019-10-02 | 2022-12-13 | Invoking a Random Linear Network Coding Communications Protocol |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/591,496 US11528342B2 (en) | 2019-10-02 | 2019-10-02 | Invoking a random linear network coding communications protocol |
US18/065,375 US20230188628A1 (en) | 2019-10-02 | 2022-12-13 | Invoking a Random Linear Network Coding Communications Protocol |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/591,496 Continuation US11528342B2 (en) | 2019-10-02 | 2019-10-02 | Invoking a random linear network coding communications protocol |
Publications (1)
Publication Number | Publication Date |
---|---|
US20230188628A1 true US20230188628A1 (en) | 2023-06-15 |
Family
ID=75275275
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/591,496 Active 2040-01-16 US11528342B2 (en) | 2019-10-02 | 2019-10-02 | Invoking a random linear network coding communications protocol |
US18/065,375 Abandoned US20230188628A1 (en) | 2019-10-02 | 2022-12-13 | Invoking a Random Linear Network Coding Communications Protocol |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/591,496 Active 2040-01-16 US11528342B2 (en) | 2019-10-02 | 2019-10-02 | Invoking a random linear network coding communications protocol |
Country Status (3)
Country | Link |
---|---|
US (2) | US11528342B2 (en) |
EP (1) | EP4038841A4 (en) |
WO (1) | WO2021067625A1 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114531500B (en) * | 2021-12-27 | 2023-11-21 | 新纳传感系统有限公司 | Extensible equipment data acquisition terminal, method and system |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050132214A1 (en) * | 2003-12-10 | 2005-06-16 | Cisco Technology, Inc. (A California Corporation) | Authentication for transmission control protocol |
US20150381753A1 (en) * | 2000-04-17 | 2015-12-31 | Circadence Corporation | Optimization of enhanced network links |
US20160134546A1 (en) * | 2014-11-10 | 2016-05-12 | APS Technology 1 LLC | Network Throughput |
US20160150054A1 (en) * | 2000-04-17 | 2016-05-26 | Circadence Corporation | System and devices facilitating dynamic network link acceleration |
US20160191402A1 (en) * | 2014-04-16 | 2016-06-30 | Apsi Wifi, Llc | Reduction of Network Congestion |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7321935B2 (en) * | 2002-06-21 | 2008-01-22 | Intel Corporation | Method and apparatus for increasing TCP/IP server responsiveness |
US7979694B2 (en) * | 2003-03-03 | 2011-07-12 | Cisco Technology, Inc. | Using TCP to authenticate IP source addresses |
US8473620B2 (en) * | 2003-04-14 | 2013-06-25 | Riverbed Technology, Inc. | Interception of a cloud-based communication connection |
US20040255008A1 (en) * | 2003-04-21 | 2004-12-16 | International Business Machines Corporation | System for low power operation of wireless LAN |
US8279781B2 (en) | 2008-08-28 | 2012-10-02 | Massachusetts Institute Of Technology | Random linear network coding for time division duplexing |
US10530574B2 (en) * | 2010-03-25 | 2020-01-07 | Massachusetts Institute Of Technology | Secure network coding for multi-description wireless transmission |
ES2742286T3 (en) | 2010-03-25 | 2020-02-13 | Massachusetts Inst Technology | Secure network coding for streaming video streaming, multi-resolution wireless |
US20120054583A1 (en) * | 2010-08-27 | 2012-03-01 | Raytheon Company | Method and system of sub-packet error correction |
GB2482991B (en) * | 2011-08-24 | 2012-09-12 | Renesas Mobile Corp | Methods and apparatus for multicast transmission |
US20130051386A1 (en) * | 2011-08-24 | 2013-02-28 | Renesas Mobile Corporation | Methods and Apparatus for Multicast Transmission |
US9537759B2 (en) * | 2012-01-31 | 2017-01-03 | Massachusetts Institute Of Technology | Multi-path data transfer using network coding |
US9515775B2 (en) * | 2012-11-08 | 2016-12-06 | Instart Logic, Inc. | Method and apparatus for improving the performance of TCP and other network protocols in a communication network |
US9185529B2 (en) * | 2013-03-15 | 2015-11-10 | Massachusetts Institute Of Technology | Wireless reliability architecture and methods using network coding |
US9609492B2 (en) | 2013-10-17 | 2017-03-28 | Openet Telecom Ltd. | Method and system for dynamically creating tunnels suitable for metering and managing usage data for applications and services |
US10554565B2 (en) * | 2015-07-07 | 2020-02-04 | Strong Force Iot Portfolio 2016, Llc | Network communication recoding node |
US20180284741A1 (en) | 2016-05-09 | 2018-10-04 | StrongForce IoT Portfolio 2016, LLC | Methods and systems for industrial internet of things data collection for a chemical production process |
CN107508655B (en) * | 2017-07-19 | 2020-08-07 | 西南交通大学 | Self-adaptive end-to-end network coding transmission method |
-
2019
- 2019-10-02 US US16/591,496 patent/US11528342B2/en active Active
-
2020
- 2020-10-01 WO PCT/US2020/053841 patent/WO2021067625A1/en unknown
- 2020-10-01 EP EP20872005.2A patent/EP4038841A4/en active Pending
-
2022
- 2022-12-13 US US18/065,375 patent/US20230188628A1/en not_active Abandoned
Patent Citations (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170163757A1 (en) * | 2000-04-17 | 2017-06-08 | Circadence Corporation | Optimization of enhanced network links |
US20180316773A1 (en) * | 2000-04-17 | 2018-11-01 | Circadence Corporation | Optimization of enhanced network links |
US10205795B2 (en) * | 2000-04-17 | 2019-02-12 | Circadence Corporation | Optimization of enhanced network links |
US20160150054A1 (en) * | 2000-04-17 | 2016-05-26 | Circadence Corporation | System and devices facilitating dynamic network link acceleration |
US20170324845A1 (en) * | 2000-04-17 | 2017-11-09 | Circadence Corporation | System and devices facilitating dynamic network link acceleration |
US9578124B2 (en) * | 2000-04-17 | 2017-02-21 | Circadence Corporation | Optimization of enhanced network links |
US20150381753A1 (en) * | 2000-04-17 | 2015-12-31 | Circadence Corporation | Optimization of enhanced network links |
US9923987B2 (en) * | 2000-04-17 | 2018-03-20 | Circadence Corporation | Optimization of enhanced network links |
US10033840B2 (en) * | 2000-04-17 | 2018-07-24 | Circadence Corporation | System and devices facilitating dynamic network link acceleration |
US20180355154A1 (en) * | 2000-04-17 | 2018-12-13 | Circadence Corporation | System and devices facilitating dynamic network link acceleration |
US20050132214A1 (en) * | 2003-12-10 | 2005-06-16 | Cisco Technology, Inc. (A California Corporation) | Authentication for transmission control protocol |
US20160191402A1 (en) * | 2014-04-16 | 2016-06-30 | Apsi Wifi, Llc | Reduction of Network Congestion |
US10069746B2 (en) * | 2014-04-16 | 2018-09-04 | Apsi Wifi, Llc | Reduction of network congestion |
US20160134546A1 (en) * | 2014-11-10 | 2016-05-12 | APS Technology 1 LLC | Network Throughput |
US10516617B2 (en) * | 2014-11-10 | 2019-12-24 | APS Technology 1 LLC | Network throughput |
Also Published As
Publication number | Publication date |
---|---|
WO2021067625A1 (en) | 2021-04-08 |
US20210105342A1 (en) | 2021-04-08 |
EP4038841A4 (en) | 2024-02-14 |
US11528342B2 (en) | 2022-12-13 |
EP4038841A1 (en) | 2022-08-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10516617B2 (en) | Network throughput | |
US10069746B2 (en) | Reduction of network congestion | |
US10862871B2 (en) | Hardware-accelerated payload filtering in secure communication | |
Cui et al. | Innovating transport with QUIC: Design approaches and research challenges | |
Grigorik | High Performance Browser Networking: What every web developer should know about networking and web performance | |
US10038693B2 (en) | Facilitating secure network traffic by an application delivery controller | |
US20190229903A1 (en) | Hardware offload for quic connections | |
US10911491B2 (en) | Encryption with sealed keys | |
US9300733B2 (en) | System and/or method for client-driven server load distribution | |
JP2019528604A (en) | System and method for virtual multipath data transport | |
US20070094723A1 (en) | Method for dynamically tunneling over an unreliable protocol or a reliable protocol, based on network conditions | |
Fairhurst et al. | Services provided by IETF transport protocols and congestion control mechanisms | |
CN110875799A (en) | Transmission control method and device | |
US20230188628A1 (en) | Invoking a Random Linear Network Coding Communications Protocol | |
CN112953850B (en) | Data transmission method and device, computer readable medium and electronic equipment | |
US9240952B2 (en) | System and method for communication between networked applications | |
WO2023217188A1 (en) | Livestream data transmission method, apparatus and system, device and medium | |
US9866384B2 (en) | Media detection of encrypted tunneled data | |
CN113645283B (en) | Multilink communication method, device, storage medium and electronic equipment | |
US9060205B2 (en) | Optimizing streaming of a group of videos | |
Caviglione et al. | A deep analysis on future web technologies and protocols over broadband GEO satellite networks | |
Shamieh et al. | Dynamic cross-layer signaling exchange for real-time and on-demand multimedia streams | |
US20170126849A1 (en) | Header redundancy removal for tunneled media traffic | |
US8856304B2 (en) | Accelerating UDP traffic | |
WO2024030760A1 (en) | Techniques for mitigating nic ktls denial-of-service attacks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: APS TECHNOLOGY 1 LLC, UTAH Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BALLIF, JEFFREY G.;ANDERSON, CHRIS;REEL/FRAME:062072/0951 Effective date: 20190919 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |