Real-time proxies

• US 20050108411A1
• Filed: 09/01/2004
• Published: 05/19/2005
• Est. Priority Date: 09/05/2003
• Status: Abandoned Application

• Current Assignee: Logitech Europe S A (Logitech International SA)
• Original Assignee: Logitech Europe S A (Logitech International SA)
• Inventors: Farner, Knut, Kliland, Kevin
• Application Number:
  US10/931,492
• Publication Number:
  US 20050108411A1
• Time in Patent Office: Days
• US Class Current: 709/230
• CPC Class Codes: H04L 63/029 Firewall traversal, e.g. tunnelling or, creating pinholes
• CPC Class Codes: H04L 69/14 Multichannel or multilink protocols
• CPC Class Codes: H04L 69/16 Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
• CPC Class Codes: H04L 69/163 In-band adaptation of TCP data exchange; In-band control procedures

Abstract

An arrangement for real-time data transmission through data communication networks is disclosed. The arrangement allows for real-time communication between applications located in different internal networks protected by firewalls by means of representing the applications by proxies and establishing TCP channels towards an intermediate proxy server localized outside the firewalls. A set of parameters residing in the server determines i.a. the number of required TCP channels based on the ratio of measured bandwidth between the data flow directions.

Claims

1. A sender, receiver, arrangement for high reliability bidirectional data communication in real time, through one or more firewalls characterized in that the data communication is provided by at least one bidirectional HTTP/HTTPS connection associated with at least one of (a) a real tunnel client behind a firewall and (b) a NAT device with a real tunnel server, and (c) a media engine on the outside of a firewall.

2. An arrangement according to claim 1, characterized in that said real tunnel client resides in a client computer and at least one real time application is running on said computer.

3. An arrangement according to claim 1, characterized in that the real tunnel client has a two-level system for caching and a system for dropping data packets, such as TCP packets.

4. An arrangement according to claim 3, characterized in that 1-5 RTP packets are packed into one TCP packet.

5. A method for high reliability bidirectional data communication in real time through one or more firewalls or NAT devices where said method involves the use of at least a real tunnel client behind the firewall and a real tunnel server or a media engine on the outside of said firewall, characterized in that said method for data communication comprises providing at least one bidirectional HTTP/HTTPS connection, and establishing said bidirectional data communication between the real tunnel client and the media engine wherein new HTTP/HTTPS connection is established before time-out on the previous HTTP/HTTPS connection.

6. A method according to claim 5, characterized by employing a two-level system for caching and dropping data packets by the real tunnel client, where the data packets are TCP packets.

7. A method according to claim 6, characterized by establishing new TCP connections for the real tunnel client whenever at least one of the following conditions are met:

cache level 1 is full,

cache level 2 is full,

cache level 1 has reached a predetermined threshold level,

cache level 2 has reached a predetermined threshold level,

the rate of dropping packets has reached a predetermined rate dropping level,

a function of the current drop rate and the previous drop rate are satisfied,

the ratio between the total transmitted bandwidth, and the total receiving bandwidth exceed a predetermined threshold with reference to the real tunnel client.

8. A method according to claim 6, characterized by reducing TCP connections for the real tunnel client whenever one or more of the following conditions are satisfied;

cache level 1 is empty,

cache level 2 is empty,

cache level 1 has reached a predetermined threshold level,

cache level 2 has reached a predetermined threshold level,

the rate of dropping packets has reached a predetermined rate dropping level, or

a function of the current drop rate and the previous drop rate are satisfied, or

the ratio between the total transmitted bandwidth and the total receiving bandwidth exceed a predetermined threshold with reference to the real tunnel client.

9. A method according to claim 6, characterized by establishing new TCP connections by the server or media engine whenever at least one of the following conditions are satisfied:

cache level 1 is full,

cache level 2 is full,

cache level 1 has reached a predetermined threshold level,

cache level 2 has reached a predetermined threshold level,

the rate of dropping packets has reached a predetermined rate dropping level,

a function of the current drop rate and the previous drop rate are satisfied,

the ratio between the total transmitted bandwidth and the total receiving bandwidth exceed a predetermined threshold with reference to the real tunnel client.

10. A method according to claim 6, characterized by optimizing TCP throughput where a maximum number of subsequent RTP packets are transmitted on the sam TCP connection is given as:

a ratio between a round trip delay and a number of HTTP/HTTPS connections times a time interval between every single RTP packet, is checked or measured by a sender at predetermined intervals.

11. A method according to claim 6, characterized by algorithmically ranking the best available TCP connection where said ranking is based at least one of the following conditions:

cache level 1 is full;

cache level 2 is full;

cache level 1 has reached a predetermined threshold level;

cache level 2 has reached a predetermined threshold level;

the rate of dropping packets has reached a predetermined rate dropping level;

a function of the current drop rate and the previous drop rate are satisfied;

the ratio between the total transmitted bandwidth and the total receiving bandwidth exceeds a predetermined threshold with reference to the real tunnel client;

RTCP messages have a specified characteristic, and

TCP window size has a specified characteristic.

12. A method according to claim 6, characterized by packing 1-5 RTP packets into one TCP packet.

13. A method according to claim 6, characterized by finding and disabling Nagle'"'"'s algorithm.

14. A method according to claim 6, characterized in that the receiver always acknowledges all packets as received, and if TCP packets are lost the receiver will modify the TCP 32-bit acknowledge number of the TCP packet to be equal to the TCP bit sequence number of the last received TCP packet.

15. A method according to claim 14 further defined by improving TCP throughput by modifying TCP stack, where the send is adding a fixed bit pattern to every RTP packet.

16. A method according to claim 15 further defined by synchronizing the sender with the RTP packets and, when a TCP segment with a fractional RTP packet is lost, the receiver initializes a search algorithm for searching a first occurrence of a fixed bit pattern.

17. A method according to claim 5 further defined by improving TCP throughput where the Media Engine, as a sender, detects that a TCP packet (segment) is lost, a new RTP packet is inserted into the TCP packet that has to be resent.