Patent ID: 12224882

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

An object of the present invention is to provide a system and method for allowing a client to access any one of a number of devices via a server or a cluster of server instances, even if each device is in a different physical location or different location on the Internet or other network.

Another object of the present invention is to provide a system or method for allowing multiple clients to access multiple devices over the same persistent tunneled connection.

Another object of the present invention is to provide a system that can easily authorize or not authorize a client to access each particular device on a network.

For purposes of the present disclosure, a client is defined as either a user or an automated process that is accessing a device. A device is any device that is connected to a network to which network access may be desired, such as a sensor, a scientific apparatus, smart-home automation such as light switches or thermostats, a kitchen appliance, and so on. A client may connect to a device in order to receive data from it, to send data to it, or to control it in some way.

FIG.1shows a block diagram of an aspect of the present invention. Clients140reside on the Internet, as do devices130. In other embodiments, some or all of the devices130can be located on a private network or behind a firewall, as can some or all of the clients140. In some embodiments, at least one of the devices130is on a network that does not normally allow access from the Internet due to firewalls or Network Address Translation. In other embodiments, at least one of the devices130is on the Internet. A load balancer120connects to at least one server instance110, located on a private network. The server instances110are connected via HTTP to a proxy database.

FIG.2shows an aspect of the tunneling process of the present invention. When a device comes online1, it establishes a connection with the server URL and identifies (authenticates) itself. The load balancer120assigns this connection to one of the server instances. In this aspect of the invention, the socket.io library is used to manage the connection, though the underlying connection is a Websocket.

A device can identify itself in various ways. In the preferred embodiment, the device self-reports its identity. The device may also verify the authenticity of the server; in the preferred embodiment, the device uses HTTPS to verify the server and then presents a unique cryptographically signed token to the server to authenticate itself. In another embodiment, 2-way TLS is used for mutual authentication.

After the server instance is assigned, it begins listening2on a port that can be accessed from the private network, but not from outside. It also adds an entry to the proxy database100that associates the hostname of the device with the assigned server instance and the assigned port.

A client then makes a network request3to access the device. In the current implementation, it is a web request over HTTP(S). The requests can also be long-lived, such as websockets, which allow a device to send realtime notifications back to the client. In its request, the client specifies which device to access via domain name. For example, if the server cluster can be accessed via app.example.com, then Device 1 could be accessed by specifying a host of device1.app.example.com in the web request. Other methods could also be used, such as using different web headers, cookies, accessing the load balancer through different IP addresses and/or ports, or using different endpoints (e.g. https://www.example.com/device1/ . . . )

It must also be noted that other network requests besides web requests may also be used with the present invention.

The load balancer then routes the client request to one of the server instances (Server Instance B, in the Figure). The server instance may be the same or different from the one that the device connected to. Once the server instance sees that the requested host refers to a device, it looks up 4 the device entry in the proxy database. In the Figure, this would be Server Instance A and Port P.

The server instance then checks to see if the client is authorized to access the device. In this embodiment, this is done by comparing the client's roles and other attributes with the device's attributes. For example, a device belonging to a particular organization might be accessible only from a client with an “admin” role belonging to the same organization. As another example, one client may be authorized to access devices in a particular building, while another client may not.

If the client is authorized, Server Instance B then opens a connection5to Server Instance A and Port P, as stated in the device entry in the proxy database, and proxies the incoming request to the new connection. This is done by opening a new TCP connection between the two server instances; it could also be done by having server instances have persistent connections between each other, or using a connectionless protocol such as UDP. Server Instance A then transparently tunnels6the proxied request over the persistent socket.io connection. Multiple simultaneous requests can be proxied over a single persistent connection.

On the device, the tunneled network connection is routed to the loopback interface7so that it appears as an ordinary network connection to applications or services running on that device. This allows any device to be used with the system of the present invention without the need to specially configure the device. In an embodiment, the device is configured to allow access to services only through the loopback interface. This allows only authorized access to services, even on a potentially insecure network.

While this is not shown in the Figure, a second client can access the device the same way. A second network request is received and routed to a server instance by the load balancer. This may be an entirely different server instance, Server Instance B, or Server Instance A. This server instance then checks to see if the second client is authorized to access the device; if the client is authorized, this server instance then looks up the server instance and port associated with the client (i.e. Server Instance A and Port P), opens a connection to Server Instance A and Port P, and proxies the incoming request to the new connection. Server Instance A then transparently tunnels the proxied request over the persistent socket.io connection. Similarly, the system can accommodate a third, fourth, or any other number of clients.

Similarly, another device may be accessed by a client the same way. The second device would need to be connected to its own server instance (for example, Server Instance D) and its own port (for example, Port P2). This would then be entered into a database. A client would then be able to access the second device by connecting to a server instance (which may be distinct from Server Instance D), which then looks up the connection between the second device and Server Instance D and Port P2, connects to Server Instance D and Port P2, and proxies the incoming request to the new connection. Server Instance D then tunnels that proxied request over the persistent socket.io connection.

As stated above, Server Instance D may be the same as Server Instance A or B, or may be a distinct server instance. It is not necessary for each device to set up its own distinct server instance to practice the present invention. It is sufficient that each pair of instance and port be distinct and associated with the device. For example, (A, P); (A, P2); (D, P); (D, P2) could all be acceptable combinations of server instance and port for four different devices.

In summary, each device sets up its own tunnel to a cloud server where all the server instances reside; there is one tunnel for each device. The authentication of the clients happens in the cloud (i.e. on the server instances), and once the client is authenticated, the system determines what tunnel the client needs to access.

As pertaining to establishing and maintaining a persistent connection from a device, the only hard requirement is that the connection from the device must support reliable two-way communication between the device and the server cluster. For practical implementations, it is often necessary for such a connection to be able to traverse firewalls and Network Address Translation (NAT) devices that may exist on the device's network. For this reason, a type of device-initiated TCP connection is preferable for practicing the present invention. In other embodiments, the transport layer connection is not truly persistent but can be reestablished readily. In an embodiment, a pair of long-polling HTTP connections (one send, one receive) is used, even though they may have a limitation on how long they are held open.

In an embodiment, a “connectionless” protocol is used instead of a connection. This is consistent with practicing the present invention as long as it ensures reliability of message delivery. In an embodiment, the UDP network protocol is used. Any other similar protocol may be used as well.

A major advantage of the present invention is the ability to multiplex multiple network requests over the single persistent connection. In this embodiment of the present invention, this is done by formatting the network request to include at least the following:a. Network request IDb. Type of action (i.e. open, close, data, acknowledge)c. Any data

In the preferred embodiment, packaging these messages to send over a connection can be done through an existing library. In an embodiment, the messages may be packaged “from scratch”.

In an aspect of the invention, multiple services may also be multiplexed over the single persistent connection. In an embodiment, in addition to proxying HTTP(S) requests, the server cluster could also be configured to proxy SSH sessions to allow authorized users to log into the device.

In an embodiment of the invention, the persistent connection may be used not just by a client to connect to the device, but by the device to initiate connections to the server instance.

In an embodiment, the system can support flow control to minimize buffering on each end. For example, if a tunneled connection on the device side is slow to consume data, the device sends a message through the tunnel to tell the server to pause its side of the connection. Once the buffered data is consumed on the device side, another message is sent to resume the connection.

In the above-described embodiment, a proxy database is used to track which server instance is connected with a particular device. However, in alternate embodiments, a database is not used. The only requirement for practicing the present invention is that there has to be some way for a server instance to look up the connection information for a device. This information may be stored in a database, on a separate server, on a single “master” or “primary” server instance, distributed or replicated among server instances, or on the load balancer itself.

In an embodiment, the connection lookup information does not reside on persistent storage, but rather is stored in the in-memory storage. If a server instance goes down, connections to it will get terminated, and then, the devices will reconnect and their lookup information will get regenerated.

If there is only a single server instance and no load balancer used in the present invention, the connection lookup information could be maintained on that single instance. In this case, of course, the server instance would not need to be stored as part of the connection information.

While a load balancer is shown in the Figure, it is not a required part of the invention. Any other way of assigning server instances could also be used. In an embodiment, the load balancer could “steer” client requests for a particular device to the server instance maintaining the connection to that device, to reduce traffic on the server cluster's internal network. In another embodiment, the connection lookup, proxying, and tunneling are all performed within the load balancer.

The load balancer required to practice the present invention may use any commonly available load balancing algorithms and methods. For example, it may use the round robin method, the least connections method, the least time method, a hash method to minimize redistribution of loads, an IP hash to use the client's IP address to determine which server receives the request, or a “random with two choices” method, wherein two server instances are picked at random and the least connections algorithm is used to pick one out of the two.

The server instances preferably reside on a cloud server or group of servers located on a private network. The present invention is not limited as to how many server instances may be used.

An exemplary embodiment is described above. It is to be understood that reasonable equivalents to the elements of the above-described embodiment are to be included in the disclosure, and that the present invention is only limited by the claims.