Abstract:
Disclosed are a connectivity platform that allows for proprietary connectivity modules to plug into the operating system and also allows the operating system users and various existing networking applications in the operating system that are authorized by those providers to use that connectivity via existing APIs without the need for the applications to change or for extra configuration of the application to be performed. In an example disclosed herein, the providers provide NAT or firewall traversal and implement the appropriate transport mechanism. This allows for applications and computing devices to communicate in environments where connectivity is prevented by intermediate systems.

Description:
TECHNICAL FIELD 
     This description relates generally to network connectivity and more specifically to the traversal of firewalls and Network Address Translators. 
     BACKGROUND 
     Communications devices have multiple obstacles to the seamless exchange of data. Whether these devices are on Intranets or on the public Internet, various security and addressing devices could disrupt their communication. One device that can disrupt communication is a firewall. While the benefits of a firewall provide a higher security level, arbitrary ports are blocked which increase the possibility of communications interference. Another device that can disrupt the exchange of data is a Network Address Translator (NAT). NATs have the benefit of allowing multiple devices on a private network to share the same global IP address, by handing out private addresses behind these devices and masking these private addresses with that shared global address. In this process several assumptions are made that could disrupt data exchange. This can include overlap in private addressing. When applications that run on communications devices that make addressing assumptions, the data exchange may not occur as expected, resulting in a poor usability experience. 
     In addition to the above described communication disruptions, there are only a few address blocks that are designated as private. Deployment of NATs leads many home and corporate environments to use the same addresses in their private networks. In some cases, two machines in different environments may have the same IP address. Thus without some out of band mechanism it is impossible for the application to identify to which destination computing device the application is attempting to send the traffic. There are many solutions currently available to traverse NATs and firewalls. These solutions typically require that applications include a customized implementation that allows for end-to-end communication. Examples of custom NAT traversal approaches include Simple Traversal of UDP through NATs (STUN) and Traversal using Relay NAT (TURN). 
     SUMMARY 
     The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later. 
     The present example provides a connectivity platform that allows for proprietary connectivity modules (providers) to integrate into the operating system and also allows the operating system users and various existing networking applications in the operating system that are authorized by those providers to use that connectivity via existing APIs without the need for the applications to change or for extra configuration of the application to be performed. In this example, the providers provide NAT or firewall traversal and implement the appropriate transport mechanism. This can allow for applications and computing devices to communicate in environments where connectivity is prevented by intermediate systems. 
     Many of the attendant features will be more readily appreciated as the same becomes better understood by reference to the following detailed description considered in connection with the accompanying drawings. 
    
    
     
       DESCRIPTION OF THE DRAWINGS 
       The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein: 
         FIG. 1  is a block diagram of an illustrative connectivity system. 
         FIG. 2  is a block diagram illustrating components of a connectivity platform according to one embodiment. 
         FIG. 3  is a flow diagram illustrating a process associated with the connectivity platform according to one embodiment. 
         FIG. 4  is a flow diagram illustrating a process for using the connectivity platform according to one embodiment. 
         FIG. 5  is a block diagram of the connectivity system according to an alternative embodiment. 
         FIG. 6  is a block diagram of the connectivity system according to another alternative embodiment. 
         FIG. 7  is a block diagram illustrating components of a computing device according to one embodiment. 
     
    
    
     Like reference numerals are used to designate like parts in the accompanying drawings. 
     DETAILED DESCRIPTION 
       FIG. 1  is a block diagram of a connectivity system  10  according to one illustrative embodiment. System  10  includes computing device  100  and computing device  140 . Computing device  100  includes an application  110 , a connectivity platform  120  and a provider  130 . Provider  130  communicates to another provider located on computing device  140  through a network, such as network  150 . While the arrows in  FIG. 1  indicate communication from computing device  100  to computing device  140 , it should be noted that communication may flow in the opposite direction. In one embodiment, computing device  140  includes similar components as computing device  100 .  FIG. 1  illustrates an embodiment where a single application or user uses a provider  130  to connect to computing device  140 . In this embodiment computing device  100  and computing device  140  have the same provider  130 . However, in other embodiments each computing device  100 ,  140  may have a different provider. Prior to reaching the network  150  the provider processes a request through a firewall or Network Address Translator (NAT)  135 . In one embodiment, from the NAT  135  a signal is transmitted through network  150  to a firewall or NAT  145  which protects computing device  140  and then onto components of computing device  140 . While a firewall or NAT is illustrated at both computing device  100  and  140  in alternative embodiments one or both of the computing devices may lack a firewall or NAT. 
     Application  110  is any application running on, or service of, computing device  100  that requires a connection or communication with a computing device, such as to computing device  140  across a network. For example application  110  may be an internet browser, an instant messaging system, or any other application using a network. The Application generates data that is to be communicated to the other computing device  140 . The application  110  may also provide an identifier to the operating system of the computing device for the desired communication. In some embodiments data from application  110  can include an identifier or address of the destination computing device  140 . In some embodiments application  110  may be located on a third computing device (not illustrated) that is connected to computing device  100  through a network. 
     Connectivity platform  120  is a component or components that enable a provider, such as provider  130 , to plug into an operating system and/or an application running on the operating system to enable end-to-end connectivity. Connectivity platform  120  provides users (applications or services) of computing devices  100  and  140  with the ability to communicate with each other, or to other computing devices (not illustrated) connected through the network  150 . To achieve this connectivity platform  120  that, in one embodiment, exposes a subnet network and routes data from application  110  to the provider ( 130 ). In one embodiment, the connectivity at the link and network layer is not transitive. In embodiments where multiple applications or users share a common provider  130  the connectivity platform or the provider  130  may limit the ability of those users or applications to connect with each other. The connectivity platform  120  will be discussed in greater detail with respect to  FIG. 2  below. 
     Provider  130  is a component or module of system  10  that is configured to plug into the connectivity platform  120  in order to enable end-to-end connectivity between computing devices and users of the computing devices. In one embodiment the provider  130  provides some form of NAT or firewall traversal, and may also provide a data relay (illustrated as relay  185 ) when NAT or firewall traversal fails. Other implementations of a (relay  185 -provider  130 ) combination may include alternative transport mechanisms including for example low priority file transfers. In some embodiments provider  130  may encapsulate packets that are sent by the connectivity platform  120  into packets that are routable over the network  150 . In some embodiments multiple peers (i.e. computing devices that are all using the same or compatible providers) could build an overlay mesh network over which they could route communications as an alternative to a relay or direct communication. Provider  130  may register with the connectivity provider  120  multiple times to provide services to the same or multiple users on the computing device  100 . For purposes of this discussion each registration by the provider  130  will be referred to as a provider instance. Further, for purposes of simplicity only one provider instance will be discussed. However, it is possible that multiple provider instances may be used simultaneously, for example when the user has multiple identities that need connectivity and are understood by the provider  130 . The provider instance is generated inside the connectivity platform  120 . 
     In general provider  130  can be any type of provider available. One requirement of the provider  130  is that it provides end to end network connectivity. The provider  130  transfers arbitrary data from application  110  to application  160  through the connectivity platforms based on addresses that have been associated with the applications  110 ,  160 , users and/or computing devices through designated provider instances. The provider  130  also allows for detecting whether an address is reachable through the designated provider instance. In one embodiment the addresses involved could use IPv4 or IPv6 protocols. 
     Network  150  is a network that may provide connectivity for computing devices  100  and  140  Network  150  may be, for example, the Internet, a local area network, a wide area network, an intranet or any other system that allows or facilitates communication between the computing devices  100  and  140 . 
     Firewall  135  is a component that regulates the flow of traffic between computer networks or between computing devices such as computing devices  100  and  140  based on a set of rules. Firewall  135  may also include network address translation (NAT) functionality. However, in some embodiments the firewall  135  is simply a NAT. In some embodiments, computing devices  100  and  140  are located behind a firewall have addresses in the “private address range”, for example as defined in RFC 1918. The NAT functionality of firewall  135  functions to address the limited number of IPv4 routable addresses that can be used. Again as mentioned above, in other embodiments Firewall or NAT devices may only be present at some locations, or not be present at all. 
       FIG. 2  illustrates the components and data flow through the connectivity platform  120  according to one illustrative embodiment. While the components illustrated in  FIG. 2  are shown as being in close proximity to each other, in some embodiments the components the connectivity platform  120  are located throughout the system  10 . 
     Connectivity platform  120  is divided into a user mode  200  and a kernel mode  250 . The user mode  200  of connectivity platform  110  has an application interface  210  (which interfaces with application  110  of  FIG. 1 ), a provider instance  220  and a management module  230 . The kernel mode  250  of connectivity platform  120  has an liaison module  260 , a device driver  270  and a protocol module  280 . While the present discussion is directed to a portion of the connectivity platform  120  being in a user mode and a portion in kernel mode, in other embodiments the connectivity platform  120  may be entirely in the user mode, or alternatively entirely in the kernel mode. 
     Provider instance  220  is an instance created by a provider, such as provider  130 , as a result of a user action or other event. In one illustrative embodiment the provider instance  220  includes two interfaces for communicating with the provider  130 . In one embodiment the interface is an LRPC interface. However, other types of interfaces may be used. The first interface is used by the provider  130  to register/deregister with the connectivity platform  120 . The second interface is used by the liaison module  260  to call the provider  130  for control and data exchange. 
     Management module  230  is a module configured to support the transition between different addressing protocols. Additionally the management module  230  is configured to implement the registration and deregistration of providers  130  and provider instances  220 , configure the IP addresses according to the correct protocols, and implement any required filters. Further, the management module  230  is configured to place the provider instances  220  into or out of a dormant state. It should be noted that the management module  230  is not part of the flow of data through the connectivity platform  120 . 
     Liaison module  260  is a component of connectivity platform  120  that takes data to be transmitted and facilitates transmission over the provider instance  220 . In one embodiment liaison module  260  is the tunnel.sys of the Windows operating system. However other types of liaison modules may be used. Network driver  270  is a software module configured to enable different network protocols communicate with a variety of network adaptors. In one embodiment the network driver  270  is compliant with network driver interface specification (NDIS). In general, network driver  270  represents a virtual or physical media (Ethernet, for example) in an interface that is understood by NDIS clients such as TCP/IP stack. 
     Protocol module  280  is a device that maintains a set of protocols that work together on different levels to enable communication through network  150 . In one embodiment protocol module  280  implements TCP/IP protocols. Additionally, in some embodiments, protocol module  280  includes a filtering platform  285 . Filtering platform  285  provides a platform for creating network filtering applications and/or inspection applications. In one embodiment the filtering platform  285  is the Windows Filtering Platform (WFP). However, other filtering methods can be used. 
     Interface  235  is a secondary interface through which data may flow. Interface  235  provides a platform for connecting to applications through connectivity platform  120  without using network  150 . Interface  235  may be a Bluetooth connection, an IR connection, or any other connection platform that does not require the data to be received over network  150 . 
     Briefly the flow of data through the connectivity platform  120  will be discussed. The arrows  290  illustrated in  FIG. 2  indicate the direction of the flow of data through the connectivity platform  120 . A more detailed description of the process will be provided with respect to  FIGS. 3 and 4 . In some embodiments, for inbound data, data traffic is received by the protocol module  280  and passed to the provider instance  220 . In other embodiments, inbound data is received by interface  235  and passed to the provider instance  220 . In some embodiments, at this point the provider instance  220  may decapsulate or packet process the data. The data traffic is then passed through liaison module  260 , and is re-processed by the protocol module  280 . If authorized by the filtering platform  285  according to the policy of the provider  130 , provider instance  220  traffic is delivered to the application  110 . In some embodiments, filtering platform  285  employs its own filtering rules as well. Outbound traffic flows in the opposite direction of arrows  290  as illustrated in  FIG. 2 . 
       FIG. 3  is a flow diagram illustrating a process for installing, registering and using a provider instance  220  according to one illustrative embodiment. For purposes of simplicity the discussion of  FIG. 3  assumes that only one instance is being installed. However, a similar process may be used when multiple providers and provider instances are present. 
     At step  310  a provider, such as provider  130 , is installed on computing device  100 . Providers  130  are typically installed as a result of a user action. However, in some embodiments the provider  130  may be native to the operating system or provided as part of a larger package of software or hardware that is on the computing device. The installation of the provider  130  is executed according to the process defined by the provider. 
     At step  320  the provider generates the provider instance  220  which then registers with the connectivity platform  120 . If this is the first time that the provider instance  220  has registered with the connectivity platform  120  the connectivity platform  120  creates a new IP interface and associates this IP interface with the provider instance  220 . If the provider instance  220  has previously registered with the connectivity platform  120  then the connectivity platform  120  may reuse the IP interface that was previously associated with the provider instance  220 . 
     During the first registration of the provider instance  220  the connectivity platform  120  may execute additional processes. For example, the connectivity platform  120  may create a user friendly name for the assigned IP interface. This user friendly name can assist a user in identifying the interface during a diagnostic procedure or other procedure where finding the interface may be useful. In some embodiments this name, or other identifier such as an IP address, may be made available to a buddy or a friend for end to end communication. The connectivity platform  120  may also configure filters on the system, such as filter  285  to implement any access controls that the provider  130  requires. The provider  130  provides this information to the connectivity platform during the registration process. 
     Also during the registration of the provider instance  220  the connectivity platform configures routing for data. This on-link routing, according to one embodiment, is for IPv4 and IPv6 subnets, where the prefixes needed are specified by the provider  130 . However, in some embodiments a default prefix is generated by the connectivity platform. The on-link routes assist the protocol module to look-up and consider the assigned IP interface as a candidate interface during data communication between the computing device  100  and the remote computing device  140 . 
     At step  330  the connectivity platform  330  sets the provider instance  220  to a dormant state. However, in some embodiments the provider instance is assumed to be dormant. By a dormant state it is meant that the provider instance  220  is not active and is not sending or receiving data through the connectivity provider  120 . However, this does not necessarily mean that the provider instance  220  is actually dormant. 
     At step  340  the connectivity platform  120  is used in communicating between the two applications through the network. The process performed by the connectivity platform  120  at this step is described in greater detail in  FIG. 4 . 
       FIG. 4  is a flow diagram illustrating a process used by the connectivity platform  120  to process communications according to one illustrative embodiment. At step  410  the connectivity platform  120  receives a signal indicating that communications are desired. In one embodiment this signal can be generated by the opening of a listening endpoint by application  110  that is allowed by the firewall or other policy implementing mechanism to receive edge traversal traffic. In another embodiment the signal is generated by the application  110  for sending outgoing traffic over an interface associated with a provider interface. In yet another embodiment the signal may be a call to a function that brings edge traversal interfaces to a qualified or active state. 
     Following receipt of the signal the connectivity platform  120  may need to change the state of the provider instance from dormant to active, if the provider instance was not active at the time the signal was received. This is illustrated at step  420 . In activating the provider instance the liaison module  260  makes a call to the provider instance  220 . This call to the provider instance  220  activates the instance and data can be sent. As discussed above in one embodiment this call is can be a RPC call. 
     Once the provider instance  220  is active the connectivity platform  120  then proceeds to assign an address for the provider instance. This is illustrated at step  430 . In one embodiment the address is automatically configured. In one embodiment this random address is generated using the management module  280  to generate a random address. In other embodiments the address is obtained from other sources. 
     Once the random address has been assigned, the connectivity platform  120  requests that the provider  130  perform address conflict detection. The conflicting addresses may be identified by reviewing the addresses associated with the provider  130  across all of the computing devices that reachable through network  150 . This is illustrated at step  440 . The address conflict detection is requested to ensure that when the data is transmitted to the desired application or user that it is sent to the correct application or user. If two users or applications have provider instances that have the same address then it is not possible to route the data to the correct location. If the provider determines that there is no conflicting address assigned a signal is provided to the connectivity platform  120  assigns the selected address to the interface associated with the provider instance  220 . This is illustrated at step  445 . 
     If the provider  130  determines that the selected address is in conflict with another address, the provider sends a signal to the connectivity platform indicating that the address is in conflict. This signal causes the connectivity platform  120  to return to step  430  and repeat this process until an address is generated that does not conflict with another address. In some embodiments, a component or system could track all addresses and centrally manage the addresses to avoid conflicts. 
     Once the address is assigned to the provider instance  220  the data is transmitted to and from the application  110 . This is illustrated at step  450 . In some embodiments this communication could be simplex. The data is transmitted according to the procedures associated with the provider  130 . The provider  130  performs the actual traversal of the NAT  135 . During this data transfer the data may be encapsulated both by the liaison module  260  and by the provider instance  220 . 
     Following the completion of the data transmission between the applications  110  and  160  the connectivity platform  120  proceeds to wait a predetermined period of time. This is illustrated at step  455 . In one embodiment if the there has been no additional data transfers either inbound or outbound over that period of time, the connectivity platform places the provider instance  220  in to a dormant state. This is illustrated at step  460 . If data continues to transfer, the connectivity platform  120  keeps the provider instance  220  open until such time as it has been inactive for the predetermined period of time. In another embodiment the provider instance may remain active if a component that is awaiting a message from another provider is still open the provider instance  220  will remain active, even though data is not being transferred. 
     Referring back to  FIG. 3  at step  350  a provider may deregister from the connectivity platform  120 . When a provider  130  deregisters from the connectivity platform the connectivity platform  120  removes any addresses and routes that were configured during the registration process. Further, the provider interface  220  can be removed if for example the provider  130  requests this removal during the deregistration process. 
     While the above discussion has focused on examples where the connectivity platform  120  interacts with a single provider  130 ,  FIGS. 5 and 6  illustrate exemplary alternative embodiments for implementing the connectivity platform  120 . Reference numbers that are repeated refer to the same or similar components. 
       FIG. 5  is a block diagram illustrating a single user of a computing device  500  using multiple providers  530 - 1 ,  530 - 2  to connect to computing devices  510 - 1 ,  510 - 2  that have instances of the same provider  530 - 1 ,  530 - 2  installed. As illustrated in  FIG. 5  there are two virtual links  512  and  513 . Each link  512 ,  513  is associated with one of the providers  530 - 1 ,  530 - 2 . Computing device  500  is multi-homed to both links. On computing device  500 , the connectivity platform  120  assigns different addresses to the interfaces corresponding to the provider instances of providers  530 - 1 ,  530 - 2 . To connect to either computing device  510 - 1  or computing device  510 - 2 , the provider instance selection is performed using each provider instance&#39;s ability to detect whether a remote address is reachable via that provider instance as discussed above. Once the correct provider  530 - 1 ,  530 - 2  is selected the use of the instance is the same as discussed above with respect to  FIGS. 3 and 4 . 
       FIG. 6  is a block diagram illustrating a multiple user and multiple computing device setup according to one illustrative embodiment. As illustrated in  FIG. 6  computing device  600  has two users,  610  and  611  respectively. In one embodiment, each user  610 ,  611  uses a different provider instance, provider instances  620 - 1  and  620 - 2  to communicate with applications  160  on computing devices  630  and  631  respectively. Additionally, the local system  612  of computing device  600  can access the connectivity provider  120  to provide service  613 . In the embodiment service  613  has access to both providers  620 - 1  and  620 - 2 . In  FIG. 6  there are two virtual links  601  and  602  (one per provider instance), and computing device  600  is multi-homed to both links. 
     The provider instances  620 - 1 ,  620 - 2  determine the access policy controlling the user&#39;s  610 ,  611  access to the provider instances as has been discussed above. For example, the policy may allow the system service  613  implementing the resource sharing functionality to access the provider instances so that: the user of computing device  630  can connect to resources shared by user  610  on computing device  600 , and the user of computing device  631  can connect to resources shared by user  611  on computing device  600 . Once the connection is established the system of  FIG. 6  operates similar to the systems discussed above. 
       FIG. 7  illustrates a component diagram of a computing device according to one embodiment. Computing device  700  is similar to computing devices discussed above with respect to  FIGS. 1-6 . The computing device  700  can be utilized to implement one or more computing devices, computer processes, or software modules described herein. In one example, the computing device  700  can be utilized to process calculations, execute instructions, receive and transmit digital signals. In another example, the computing device  700  can be utilized to process calculations, execute instructions, receive and transmit digital signals, receive and transmit search queries, and hypertext, compile computer code, as required by the application  110  or application  160 . 
     The computing device  700  can be any general or special purpose computer now known or to become known capable of performing the steps and/or performing the functions described herein, either in software, hardware, firmware, or a combination thereof. 
     In its most basic configuration, computing device  700  typically includes at least one central processing unit (CPU)  702  and memory  704 . Depending on the exact configuration and type of computing device, memory  704  may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. Additionally, computing device  700  may also have additional features/functionality. For example, computing device  700  may include multiple CPU&#39;s. The described methods may be executed in any manner by any processing unit in computing device  700 . For example, the described process may be executed by both multiple CPU&#39;s in parallel. 
     Computing device  700  may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in  FIG. 7  by storage  706 . Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory  704  and storage  706  are all examples of computer storage media. Computer storage media includes, 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 tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computing device  700 . Any such computer storage media may be part of computing device  700 . 
     Computing device  700  may also contain communications device(s)  712  that allow the device to communicate with other devices. Communications device(s)  712  is an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “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, RF, infrared and other wireless media. The term computer-readable media as used herein includes both computer storage media and communication media. The described methods may be encoded in any computer-readable media in any form, such as data, computer-executable instructions, and the like. 
     Computing device  700  may also have input device(s)  77  such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s)  708  such as a display, speakers, printer, etc. may also be included. All these devices are well known in the art and need not be discussed at length. 
     Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively the local computer may download pieces of the software as needed, or distributively process by executing some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.