Data Tunnelling

The present invention relates to data tunnelling, and in particular to a method of tunnelling data between users, a method of establishing a tunnel between two users, a tunnel system, and a computer program product comprising a proxy server.

Solutions are known which enable companies to transmit data over their internal LANs. However, these solutions require public IP addresses for each party participating in a conference. In particular, several TCP/UDP ports are used for normal operation. As most users are behind some kind of firewall, opening these ports is considered as a security risk and so the usage of such solutions is limited.

In addition, existing solutions require the user to download programs onto his computer, which uses up a sometimes sizeable portion of processing power.

According to a first aspect of the present invention, there is provided a method of tunnelling real-time data bi-directionally between users wherein a first proxy server wraps data in HTTP, and acts as a tunnel client to send the wrapped data to a public tunnel server, which transmits the data to second proxy server.

Preferably, the first proxy server sends the wrapped data through an open firewall connection.

Preferably, the open firewall connection is provided via TCP port 80.

TCP port 80 is the primary communication port used to transmit data over the internet. Apart from the opening of TCP port 80, the firewalls of two users who transmit and receive data through the tunnel can be kept intact. The invention therefore provides conferencing facilities over a public network which enable the users attending the conference to retain security control of their private networks.

Preferably, the data comprises video and/or audio data.

Preferably, a user connects to the server to become registered with the server, and is assigned a unique identity by the server.

Preferably, communication of data between two users is initiated after a handshake process, wherein a first user sends a request to the tunnel server for the unique identity of a second user; the server alerts the second user to the request and provides the first user's unique identity to the second user; the second user sends a connection response to permit the communication of data.

Preferably, the connection response can refuse the communication.

According to a second aspect of the present invention, there is provided a method of establishing a tunnel between two users via a tunnel server, wherein first and second users register with the tunnel server and are assigned a unique identity by the server; the second user sends a request to the tunnel server for the unique identity of the first user;

the tunnel server sends the first user's unique identity to the second user; the tunnel server sends a connection request together with the second user's unique identity to the first user; and the first user sends a connection response to the second user via the tunnel server, said response either permitting or denying the connection request.

Preferably, a tunnel can be established to provide a data conference between more than two users.

According to a third aspect of the present invention, there is provided a tunnel system suitable for carrying out the methods of the first and/or second aspects.

According to a fourth aspect of the present invention, there is provided a proxy server suitable for acting as a tunnel client to transmit data wrapped in HTTP.

Preferably, the data comprises video and/or audio data.

Preferably, the proxy server is operable to transmit the data through TCP port 80 on a computer in which it is run in use, most preferably to transmit data through TCP port 80 only.

Preferably, the proxy server is implemented in the form of an ActiveX control.

Preferably, the proxy server further comprises a layered service provider (LSP) component.

Preferably, a segment of memory is shared by the ActiveX control and the LSP component.

According to a further aspect there is provided a computer program product comprising instructions that, when carried out by a suitable machine, enable it to function as the proxy server of the fourth aspect.

The present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Fig. 1 shows an overview of an HTTP tunnel system;

Fig. 2 illustrates the structure of the HTTP proxy which forms part of the system shown in Fig. 1 ;

Fig. 3 illustrates the functionality of an LSP component of the proxy shown in Fig. 2; and

Fig. 4 illustrates the functionality of the HTTP tunnel server which forms part of the system shown in Fig. 1.

The International Telecommunications Union (ITU) standard H.323 describes terminals and other entities that provide multimedia communications services such as real-time audio, video and/or data communications over Packet Based Networks (PBN) which may not provide a guaranteed Quality of Service.

H.323 is a widely used standard to enable companies to transmit data over their internal LANs. However, the H.323 standard requires a public

IP address for each party participating in a conference, which limits its usage. In particular, several TCP/UDP ports are used for normal operation. As most users are behind some kind of firewall, opening these ports is considered as a security risk.

It is well known to provide a tunnel to act as a blind relay between two connections over a public network. However, no effective tunnelling solution has thusfar been provided to facilitate the secure transmission of data between H.323 entities over a public network.

In the figures, reference is made to "NetMeeting". This is a program provided by Microsoft Corporation which uses the H.323 standard for real time audio/video conferencing. It will be understood that the embodiment illustrated in the figures and in the following description is only one particular example of the implementation of the principles of the present invention. The invention can be used with other programs other than NetMeeting, and can enable tunnelling between a wide range of devices, not solely H.323 entities.

As seen in Fig. 1 , the HTTP tunnel system comprises an HTTP tunnel proxy 10 and am HTTP tunnel server 12. The HTTP tunnel server 12 forwards NetMeeting data wrapped in the HTTP protocol between two HTTP tunnel proxies 10 on computers 14 running NetMeeting.

The proxy server 10 is further illustrated in Fig. 2. It is implemented in the form of an ActiveX control (OCX) 20. When the control 20 is active, it tunnels all NetMeeting data through the HTTP tunnel server 12. The tunnelling process is implemented in a Windows Sockets Layered Service Provider (LSP) 22 part of the ActiveX control and is, as such, transparent to the application.

The behaviour of the LSP component 22 is controlled by the ActiveX control 20 through the library's shared memory segment 24.

Fig. 3 illustrates the functionality of the LSP component 22. A Service Provider Interface (SPI) 30 provides an interface between the LSP component 22 and the Windows Sockets library 26. Data structures used by the LSP component 22 include a list 32 of active sockets, an incoming data queue 34 which acts as a queue for data received from the HTTP tunnel server 12, and an outgoing data queue 36 acting as a queue for data going to the HTTP tunnel server 12.

A putter thread 38 sends data to the HTTP tunnel server 12; a getter thread 40 receives data from the HTTP tunnel server 12; a worker thread 42 processes data received from the HTTP tunnel server 12; and a supervisor thread 44 monitors other threads, connection to the HTTP tunnel server and variables in the shared data segment 24. More details of the operation of these threads are given below.

Fig. 4 illustrates the functionality of the HTTP tunnel server 12.

A Win32 platform I/O completion port mechanism 50 is used for communication with the clients. Data structures used by the server 12 include an incoming connections queue 52, a client list 54 (which can be effectively be a list of different HTTP tunnel proxies 10), and one or more queues 56 for unsent client data. There is one queue 56 per client.

A main thread 58 receives incoming connections from the HTTP tunnel proxy 10 connection; a getter thread 60 picks up incoming connections from the incoming connections queue 52; one or more worker threads 62

process incoming requests; and a supervisor thread 64 monitors the HTTP tunnel server 12 status and changes its operational environment when requested.

The operation of the HTTP tunnel system will now be described.

With reference to Fig. 1 , a first client (A) first registers with the tunnel server 12, using its private IP address and a globally-unique identifier (GUID). Client A then receives a unique index from the server 12, which is used by the server to identify the client.

A second client (B) polls the tunnel server 12 to receive the private IP address of client A. Client B then also registers with the tunnel server and receives its own unique index.

Client B then sends a connection request to the server 12, which forwards the connection request, together with client B's index, private IP address and GUID.

Client A can then choose whether to permit or deny the proposed communication session, and sends a connection response to client B.

Once an affirmative connection response is sent, the tunnel is fully open and transmission of the data commences.

The functionality of the HTTP tunnel proxy 10 will now be described.

Upon startup, the HTTP tunnel proxy 10 program determines its operating mode so that it can interact with the computer it is being run on. It can run as a Windows Socket Layered Service Provider (LSP), either on the

Windows 9x or NT family of products, or as an HTTP Tunnel Proxy ActiveX component. The correct operating mode can be chosen based on the HTTP tunnel proxy module filename (which can have, for example, a .dll or .OCX extension) and the identity of the process using the module (which can be, for example, Internet Explorer, NetMeeting, or RegSvr32).

If the ActiveX component is running under the Windows 9x family of products, it copies an instance of itself as a dynamic link library (.dll) file, and installs itself as a Windows Sockets Layered Service Provider for TCP and UDP protocol into the system LSP chain. The LSP is installed in front of default service providers for TCP and UDP protocol, after which, the ActiveX control loads an instance of the LSP and sets its shared data segment variables (pointers to global functions) to meaningful values.

If the ActiveX component is running under the Windows NT family of products, it uses Windows API hooking to prevent Windows Sockets library from loading the default service provider for TCP and UDP protocol and loads the HTTP Tunnel Proxy instead. If the ActiveX component is running under Windows XP, it additionally prevents Windows Sockets library from loading the default namespace service provider and loads the HTTP Tunnel Proxy instead.

When LSP startup commences, the HTTP Tunnel Proxy loads the default service providers for the TCP and UDP protocol and sets the default working environment. After setting the environment, the HTTP Tunnel Proxy sets a procedure dispatch table pointing to its own version of the supported functions. If the process using the LSP is of a specific type (for example, NetMeeting), LSP starts its core modules (getter thread, putter thread, incoming data worker thread). Otherwise, LSP initialization is completed at this point.

The LSP operates using a set of functions that control various aspects of the operation of the sockets. Such control functions are well known and shall not be described in detail hereafter.

After the startup procedures are complete, the data structures and sub- processes that use the data structures as illustrated in Fig. 3 start to function.

The LSP putter thread 38 monitors client outgoing requests queue 36. If a new request appears in the queue 36, the putter thread 38 connects to the tunnel server 12 if necessary and sends the request to the server 12. If connection to the server 12 fails, putter thread 38 exits as the tunnel system is probably unusable.

If the request cannot be forwarded to the server 12, it is discarded if the socket in question is a UDP socket. Otherwise, the packet is returned to the queue 36.

The LSP getter thread 40 maintains an incoming data tunnel with the tunnel server 12. If a request or response is received from the tunnel server 12, it is posted to the client incoming data queue 34. If the tunnel is closed, getter thread 40 tries to open another connection. If the second connection fails, getter thread 40 exits as the tunnel is probably unusable.

The LSP worker thread 42 processes requests or responses received from the tunnel server 12, or from a remote HTTP Tunnel Proxy. The thread 42 monitors the client incoming requests queue 34 and processes incoming connection requests, connection responses, data send requests and connection close requests.

For processing incoming connection requests, the worker thread 42 searches the list of open sockets 32 for a matching listening socket. If a matching socket cannot be found, worker thread 42 discards the request. If a matching listening socket is found, worker thread 42 creates a new instance of the socket context, marks it as connected and adds it to the list of open client sockets 32.

A blocking thread (not shown) may be incorporated into the LSP component. This thread may be notified upon successful completion of the operation.

For processing connection responses, the worker thread 42 searches the list of open sockets 32 for a matching socket in "connecting" state. If a matching socket cannot be found, worker thread 42 discards the connection response. If a matching connection socket is found, worker thread 42 marks it as connected and notifies blocking thread (optional), so that the function that posts an "open connection" request to the client outgoing requests queue 36 is completed.

For processing data send requests, the incoming worker thread 42 searches the list of open sockets for a matching destination socket. If a matching socket cannot be found, worker thread 42 discards the request. If a matching socket is found, worker thread 42 posts incoming data to the socket incoming data queue 34. If the socket is in overlapped I/O operation mode, the socket's overlapped receive operation thread is notified upon successful completion of the operation.

For processing connection close requests, the incoming worker thread 42 searches the list of open sockets for a matching connected socket. If a

matching socket cannot be found, worker thread discards the request. If a matching socket can be found, the worker thread 42 marks the connection as closed.

The supervisor thread 44 monitors execution of other HTTP Tunnel Proxy modules (getter thread 40, putter thread 38 and incoming worker thread 42). If any of these modules fails (exits), the supervisor thread 44 outputs a message box saying the network system has failed and requests restart of the application from the user. The supervisor thread 44 also periodically checks if a new remote client GUID is available, upon which event the thread 44 requests the private IP address of the remote client from the tunnel server 12.

The functionality of the HTTP tunnel server 12 will now be described. In a similar way to the operation of the LSP component of the HTTP tunnel proxy, various program threads operate to regulate the processing of commands and information.

Upon startup, the tunnel server 12 reads configuration parameters from a data file and creates the server environment and its core modules (getter thread 60, worker threads 62, supervisor thread 64).

A main tunnel server thread 58 listens for incoming connections and serves Windows NT service start/stop requests.

For processing incoming connections, the main thread 58 accepts a pending incoming connection and puts it into the incoming connection queue 52. The getter thread 60 then picks the connection, using the server's I/O completion port 50.

For processing incoming requests, the worker thread 62 receives notification on a completed overlapped receive operation and appends received data to the incoming data buffer. If a complete HTTP request has been received, the worker thread 62 tries processing it. If processing of the incoming request fails, the originating connection is closed.

When a client tries to register with the tunnel server 12, the server 12 searches the registered client list 54 for the originating client GUID. If the client has previously been registered, the server 12 updates its information (relating to, for example, private/public IP address pair, etc).

If the list of registered clients has reached its maximum size, the server 12 refuses the registration request. Otherwise, the client is added to the list 54 of registered clients.

When a client sends a request for another client's IP address, the worker thread 62 searches the registered clients list 54 for the destination client GUID. If the GUID is found, that client's private IP is forwarded to the request originating client.

When a client sends a request for an output or an input data tunnel to be opened, the worker thread 62 searches the registered clients list 54 for the originating client. If the client is found, its information is updated with the originating socket information.

When opening an input data channel, if the client incoming data queue 56 is not empty, the worker thread 62 forwards the first pending packet from the queue to the client. Other pending packets (if any) are forwarded to the client by the worker thread 62 that receives send operation completion notification.

When a packet from the client incoming data queue 56 has been successfully forwarded to the client, a worker thread 62 is notified about the completion status. If the client incoming data queue 56 is not empty, the worker thread 62 forwards the next pending packet from the queue to the client.

When a client requests that a packet of data should be forwarded to another client, worker thread 62 searches the list of registered clients 54 for the destination client.

If the destination client cannot be found, the originating client is notified about the failed request, however, its outgoing data tunnel is not closed.

If the destination client has been found, its incoming data queue is empty and the client incoming data tunnel is open, worker thread 62 forwards the data to the client.

If the destination client has been found and its incoming data queue is not open, the worker thread 62 stores the data in to the destination client incoming data queue.

If the destination client queue is full (its maximum storage capacity has been reached) and the data socket protocol is UDP, the packet is discarded.

If the destination client queue is full but not reached the absolute upper size limit (being twice the size of the queue maximum storage capacity) and the data socket protocol is TCP, the packet is stored into the queue.

If the destination queue has reached the absolute upper size limit, the packet is discarded regardless of the protocol.

The supervisor thread 64 handles configuration change requests and does periodic server maintenance.

If the configuration has been changed, supervisor thread 64 loads new parameters from the configuration file and acts accordingly to the changes.

The supervisor thread 64 periodically removes stopped worker threads 62 from the worker thread list and starts additional worker threads 62 if necessary.

Supervisor thread periodically unregisters idle clients, and periodically removes unregistered clients from the registered clients list.

A garbage dump is also provided for caching

All communication between the HTTP tunnel proxy and the HTTP tunnel server is wrapped inside HTTP requests and responses. The HTTP tunnel protocol fully complies with RFC 2616 specifications.

Improvements and modifications can be made to the above without departing from the scope of the invention.