Resolving names to network endpoints

A system, apparatus, method, and computer-readable medium are provided for resolving a name to a network endpoint. According to one method, naming providers are registered with a computer system that are operative to resolve names to network endpoints for one or more domains. A provider can claim to be a primary provider or a secondary provider for a domain. A provider can also register as a wildcard provider. Once the providers have been registered, requests may be received to resolve an e-mail address into a network address of the corresponding computer system. In response to such a request, one or more of the registered providers are identified as being able to resolve names in the domain to network addresses. Requests are transmitted to the identified providers requesting that they resolve the e-mail address to a corresponding network address. The manner in which the requests are made depends upon whether authoritative results are required. Once the results of the name resolution have been returned, the results are utilized to establish a network connection to and communicate with the computer system identified by the returned network address.

BACKGROUND

With the advent and explosion of the Internet, huge numbers of computers have become networked together, with additional computers becoming connected each day. A connection to the Internet provides access to vast information resources in the form of the world wide web (“WWW”), communications resources in the form of electronic mail (“e-mail”), and a virtually limitless variety of other data and communications resources. In most cases, these resources are provided using a client-server infrastructure, whereby a central server computer provides the bulk of the required computing resources to a relatively large number of client computers.

Other types of network services rely on a peer-to-peer (“P2P”) network infrastructure. In a P2P network, the computing power and bandwidth of participants in the network is utilized rather than concentrating it in a relatively low number of server computers. P2P networks are useful for many purposes, including instant messaging (“IM”), collaboration, content distribution, distributed processing, games, file sharing, and others. In a P2P network, the individual computers in the network, also referred to as nodes or peers, connect directly one another. In many cases, a P2P network may comprise an ad-hoc network created between just two nodes.

One difficulty that arises when setting up an ad-hoc P2P network stems from the fact that in order to establish a connection, it is typically necessary for one of the nodes to have network endpoint information for the other node. For instance, if two users want to play a network-capable multiplayer game, one user must know the network address of the other computer node in order to establish the connection. In another example, a remote assistance program may be utilized to allow a remote user to connect to a local node and to provide assistance with the computer to a user of the local node. In order to allow the remote user to connect, however, the network address of the local node must be determined and provided to the remote user. In situations like these, a user of one of the nodes typically determines the network address of their own computer and then transmits the network address to the other user. This process can be difficult and time consuming, especially for users that are not technically savvy or familiar with the process for determining the network address of a computer.

It is with respect to these considerations and others that aspects of a computing system for resolving a name to a network address are described below.

SUMMARY

A system, apparatus, method, and computer-readable medium are provided for resolving a name to a network endpoint. According to one aspect of the disclosure provided herein, a friendly name such as an e-mail address may be resolved into network endpoint information, such as a network address, for a corresponding computer system. The resolved network address can then be utilized to establish a connection to the computer system. This alleviates the need for a user to manually determine the network address and to transmit the network address to the other computer system.

According to one method described herein, one or more naming providers (also referred to herein as a “provider”or “providers”) are registered with a computer system. The naming providers are operative to resolve names, such as e-mail addresses, to network addresses for one or more domains. In order to register a naming provider, the naming provider provides a list of domains for which the naming provider should be the primary naming provider. A naming provider can claim to be the primary naming provider for a domain if it owns all of the names within that domain and therefore has access to the master data for all such names.

A naming provider may also provide a list of domains for which the naming provider should be a secondary naming provider. A provider can claim that it is a secondary naming provider for a domain if it is in contact with the authority for the domain such that it is capable of returning the same result that a primary provider would return. There may be multiple secondary providers for a given domain, but should only be one primary provider. A provider can also register as a wildcard provider. Wildcard registration is used if the provider can handle a large variety of names, such that it could not define all those for which it can resolve names declaratively.

Once the providers have been registered, requests may be received to resolve an e-mail address into a network address of the corresponding computer system. The e-mail address includes a local part and a domain. In response to such a request, one or more of the registered providers are identified as being able to resolve names in the domain to network addresses. In particular, in order to identify the providers capable of resolving the e-mail address, the providers that are registered as primary for the domain, secondary for the domain, or registered as wildcard providers are identified. The identified providers are then sorted into a list, with the primary provider first, the secondary providers next, and any wildcard providers listed last.

Once the sorted list of providers has been created, requests are transmitted to the providers in the list requesting that they resolve the e-mail address to a corresponding network address. In particular, according to embodiments, the request to resolve the name may include an indication as to whether the provided results should be authoritative or that the provided results need not be authoritative. An authoritative result is returned where the provider does, in fact, own the domain identified in the e-mail or is federated with an authority for the domain. A non-authoritative result is returned where the provider has information for the domain, although it has no connection with the authority for the domain.

In the case where authoritative results are requested, resolution of the name is requested from each provider in the sorted list in order until one of the providers returns an authoritative response or each of the providers indicate that they cannot resolve the name or fail. In the case where non-authoritative results are accepted, resolution of the name is requested from each of the providers in the list and the results from each provider are collected and returned.

Once the results of the name resolution have been returned, the results are returned to the requestor. For instance, an application program may request resolution of the name, in which case the results are returned to the application. The application may then utilize the returned endpoint information to establish a network connection and to communicate with the computer system identified by the returned network address. In this manner, a name can be utilized to establish a network connection to a computer system, rather than a network address.

According to other aspects, a data format is disclosed for registering a naming provider. In particular, according to one implementation, the data format includes a first data field for storing data indicating that the provider is a primary naming provider for a domain. A second data field may be utilized to store data indicating that the provider is a secondary provider for a domain. A third data field may be utilized to specify that the provider is a wildcard naming provider.

The above-described subject matter may also be implemented as a computer-controlled apparatus, a computer process, a computing system, or as an article of manufacture such as a computer program product or computer-readable medium. The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings.

DETAILED DESCRIPTION

The following detailed description is directed to systems, methods, and computer-readable media for resolving names to network endpoints. While the subject matter described herein is presented in the general context of program modules that execute in conjunction with the execution of an operating system and application programs on a computer system, those skilled in the art will recognize that other implementations may be performed in combination with other types of program modules.

Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the subject matter described herein may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.

The subject matter described herein is also described as being practiced in a distributed computing environment where tasks are performed by remote processing devices that are linked through a communications network and wherein program modules may be located in both local and remote memory storage devices. It should be appreciated, however, that the implementations described herein may also be utilized in conjunction with stand-alone computer systems and other types of computing devices. It should also be appreciated that although reference is made herein to the Internet, the embodiments presented herein may be utilized with any type of local area network (“LAN”) or wide area network (“WAN”).

In the following detailed description, references are made to the accompanying drawings that form a part hereof, and which are shown by way of illustration specific embodiments or examples. Referring now to the drawings, in which like numerals represent like elements through the several figures, aspects of a computing system and methodology for resolving names to network endpoints will be described. In particular,FIG. 1is a network diagram illustrating aspects of an illustrative operative environment for the subject matter described herein that includes a computer system100. As shown inFIG. 1, the computer system100includes an application program102. The application program102comprises a networked application program that utilizes a network address106to connect to a remote computer system101.

As also shown inFIG. 1, the computer100also includes one or more naming providers108A-108C. As will be described in greater detail below, the naming providers108A-108C include functionality for resolving a name104to a network address106of a computer101associated with the name104. In order to provide this functionality, the naming providers108A-108C maintain data correlating names to corresponding network addresses. In an embodiment, the names may comprise e-mail addresses conforming to the RFC 2821, 2822, and 1642 specifications. Generally, e-mail addresses conforming to these specifications include a local part and a domain separated by an “@” symbol (e.g. localpart@domain).

In order to obtain the mapping between names and network addresses, the naming providers108A-108C may communicate with server computers over the network112. For instance, in one implementation, the functionality for resolving names to network addresses is provided by IM client applications. In this implementation, the IM client applications communicate with associated IM server computers110A-110C over the network112to obtain the network addresses corresponding to names and to perform other functions. It should be appreciated that the naming providers108A-108C may be provided by any type of application or service.

As will be discussed in greater detail below, prior to receiving a request from the application102to resolve a name104to a network address106, each of the naming providers108A-108C must register themselves with the computer100. During registration, the naming providers108A-108C identify the domains for which they are able to resolve names and specify the authoritativeness of the results they are able to provide. Additional details regarding the registration of the naming providers108A-108C are provided below with respect toFIG. 4.

Once the naming providers108A-108C have been registered, the application102may request that a name104be resolved to a network address106. In order to provide the application102with a result, a number of processing steps are performed. In particular, the naming providers108A-108C that may be able to resolve the name104with the requested authoritativeness are identified and sorted into a list. Providers in the list are then called with a request to resolve the name104to a corresponding network address106. When an appropriate result is received from the providers108A-108C, the result is returned to the application102. The application102may then utilize the results to establish a connection with the computer system101identified by the returned network address. Additional details regarding the selection of the appropriate providers108A-108C for a particular domain are provided below with respect toFIG. 6. Additional details regarding the manner in which the selected providers are queried are provided below with respect toFIG. 7. Additional details regarding the software architecture utilized to implement the embodiments of the invention described herein are provided below with respect toFIGS. 2-3.

Referring now toFIG. 2, additional details regarding a software architecture that may be utilized to implement the embodiments described herein will be presented. In particular, as shown inFIG. 2, an application102includes application code102. The application code102utilizes the Winsock application programming interfaces (“APIs”)204to establish and maintain network connections. As known to those skilled in the art, the Winsock APIs204comprise APIs that may be utilized by application programs for communicating with a TCP/IP networking stack.

According to aspects of the invention, the Winsock APIs204may be utilized by the application code202to request the resolution of a name to a network address. In particular, according to embodiments, the application102utilizes the GetAddrInfo, GetAddrInfoEx, and SetAddrInfoEx APIs. The Winsock APIs204, in turn, call into the e-mail namespace shim206. The e-mail namespace shim206implements the Winsock namespace provider (“NSP”) version1interface the for the e-mail namespace and forwards these calls on to the providers108A-108D. It should be appreciated that the functionality described herein as being performed by the e-mail namespace shim206may be performed by the Winsock APIs204or other type of network stack interface. Additional details regarding the function and structure of the e-mail namespace shim206are provided below with respect toFIG. 3.

As shown inFIG. 3, an asynchronous lightweight remote procedure call (“LRPC”)208is utilized to call the providers108A-108D. By utilizing a LRPC, the providers108A-108D can be hosted inside of services and applications. The LRPC also prevents third-party code from running in-process with the application102. In the embodiment shown inFIG. 2, the providers108A-108B are provided by an application210and the providers108C-108D are provided by a service212. As shown inFIG. 2, a provider stub214is also utilized to hide the RPC interface details and to translate cross procedure calls into in-process calls so that the providers108A-108D do not have to be configured for RPC specific requirements. The provider stub214also implements support for publishing multiple providers from the same process and dispatching incoming calls to the correct provider.

As described briefly above, the e-mail namespace shim206is operative to discover the installed providers108A-108D, to translate synchronous NSP version1calls into asynchronous version2calls, and back to synchronous, to select the appropriate providers108A-108D for handing a resolution request based on the domain section of the e-mail address to be resolved, and to perform other functions. Additional details regarding the structure and operation of the e-mail namespace shim206are provided below with respect toFIG. 3.

Turning now toFIG. 3, further details regarding the software architecture presented inFIG. 2will be provided. In particular,FIG. 3illustrates additional details regarding the architecture of the e-mail namespace shim206. As discussed briefly above, the Winsock APIs204call into the NSP V1interface302provided by the e-mail namespace shim206. The provider call dispatcher304accepts calls from the interface302. In response to such a call, the provider call dispatcher304gathers a list of providers108A-108N from the provider selection engine306. The provider selection engine306gathers a list of the installed providers108A-108N from the provider manager308. The provider manager308is responsible for tracking the providers that are installed and running at any given time, and for tracking the provider proxies for those providers.

Once the provider call dispatcher304has received the list of providers, it then calls the list of providers108A-108N via the provider proxy layer310. When results are returned, the provider call dispatcher304returns the results to the interface302for return to the calling application102. The provider proxy layer310is responsible for exposing a synchronous in-process interface for the providers108A-108N. The proxy layer310wraps the asynchronous and cross-process nature of accessing the NSP version2providers108A-108N. The dispatcher304calls into the proxy layer310to access a provider108A-108N.

A provider stub214is also utilized by the providers108A-108N. The provider stub214is a component loaded at the provider side that hides the RPC interface details and translates cross process calls into in-process calls so that the providers108A-108N do not have to conform to RPC specific requirements. As discussed briefly above, the provider stub214also implements support for publishing multiple providers from the same process and dispatching incoming calls to the correct provider. Additional details regarding the operation of the e-mail namespace shim302will be provided below with respect toFIGS. 4-8.

Referring now toFIG. 4, additional details will be provided regarding the embodiments presented herein for resolving a name to a network endpoint. In particular,FIG. 4is a flow diagram illustrating a routine400for registering a naming provider. It should be appreciated that the logical operations described herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as operations, structural devices, acts, or modules. These operations, structural devices, acts and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination.

As discussed briefly above, each of the providers108A-108N must register with the computer100before they can be utilized to resolve e-mail addresses to network addresses. This process typically takes place at the time the provider is installed, although the registration may be performed or updated at another time. Generally, each provider108A-108N indicates during the registration process the domains for which they are capable of resolving names. This process is illustrated in the routine400ofFIG. 4.

The routine400begins at operation402, where the registering provider indicates its provider type. According to implementations, the provider may be an application or service. At operation402, the provider indicates its type. From operation402, the routine400continues to operation404. At operation404, the registering provider specifies the domains for which it is the primary provider, if any. A registering provider can claim to be the primary provider for a domain if it owns all of the names within that domain and therefore has access to the master data for all such names. In this manner, the registering provider can indicate that it should handle certain domains with priority over other providers. There should only be one provider that is registered as the primary provider for a domain. For instance, in one implementation, the MSN MESSENGER IM client application from MICROSOFT CORPORATION may register as the primary provider for the MSN.COM domain. Similarly, the YAHO MESSENGER IM client application from YAHOO may register as the primary provider for the YAHOO.COM domain. No other providers are permitted to register as the primary provider for these domains.

From operation404, the routine400continues to operation406, where the registering provider specifies the domains for which it is a secondary provider. A provider can claim that it is a secondary naming provider for a domain if it is in contact with the authority for the domain such that it is capable of returning the same result that a primary provider would return. This also implies that the secondary provider should be tried after the primary provider for the domain has been tried and has failed. There may be multiple secondary providers for a given domain. As an example, because a federation relationship currently exists between MSN and YAHOO, the MSN MESSENGER IM client application may register as a secondary provider for the YAHOO.COM domain. If the YAHO MESSENGER IM client application is unable to resolve a name, the MSN MESSENGER IM client application may be requested to resolve the name. Additional details regarding this process will be provided below.

From operation406, the routine400continues to operation408where the registering provider may register as a wildcard provider. Wildcard registration is an assertion that the provider either has non-authoritative information for, or is federated with the authority for, a number of domains large enough that exhaustive explicit declaration would be impractical. Given this assertion, wildcard providers should be tried after all secondary providers have failed. Similarly, any name for which there is no primary or secondary provider will be passed to wildcard providers so that they may attempt to resolve the name. The MSN MESSENGER IM client application may register as a wildcard provider because arbitrary e-mail addresses may be utilized with the federated PASSPORT service.

As will be described in detail below, the result of the resolution request may be authoritative, for the case in which the provider did own the name in question or was federated with the authority for the name. Alternatively, the result may be non-authoritative where the provider has information for the name, but has no connection with the authority for the name. Additional details regarding the authoritativeness of the requested response and its impact on the processing operations performed by the e-mail namespace shim206will be provided below. It should be appreciated that the registering provider must register as a provider of at least one type for at least one domain or as a wildcard provider. Once the wildcard registration has been completed at operation408, the routine400continues to operation410, where it ends.

According to one implementation, a provider registration data format is provided. The registration data format comprises a data format expressed using the extensible markup language (“XML”) that is utilized at registration time by a registering provider to specify its provider type as either an application or service. The data format is also utilized to specify the domains for which the registering provider is a primary or secondary provider. A Boolean data field is also utilized within the data format to indicate whether the registering provider is a wildcard provider.FIG. 10illustrates the structure of the provider registration data format1002according to one implementation described herein.

Turning now toFIG. 5, additional details will be provided regarding the embodiments provided herein for resolving an e-mail address to a network address. As discussed briefly above, once the registration of one or more providers108A-108N has completed, requests can be accepted for resolving e-mail addresses to network addresses. The routine500shown inFIG. 5illustrates the processing of such requests. In particular, the routine500begins at operation502where, in response to a resolution request that includes an e-mail address, the provider call dispatcher304queries the provider selection engine306for an ordered list of the providers that should be utilized to resolve the specified name. In order to generate the list, the provider selection engine306queries the provider manager308for a list of the currently installed providers. This occurs at operation502.

From operation502, the routine500continues to operation504, where a provider preference algorithm is performed by the provider selection engine306. The provider preference algorithm takes the name to be resolved as input and orders the providers according to how likely they are to be able to resolve the name based upon the registration information provided by the providers at registration time. An illustrative routine600for selecting and sorting the providers into an ordered list will be described below with reference toFIG. 6. From operation504, the routine500continues to operation506.

At operation506, the provider call dispatcher304receives the ordered sub-list of providers that may be able to resolve the specified name. From operation506, the routine500continues to operation508, where a determination is made as to whether the request for name resolution indicated that the results should be authoritative or whether the results of the resolution may be non-authoritative. As discussed above, authoritative results indicate that the provider owns the name in question or was federated with an authority for the name. Non-authoritative results indicate that the provider has information for the name, but has no connection with the authority for the name.

If the results must be authoritative, the routine500branches to operation510where the providers in the ordered list are queried using an LRPC in a manner designed to ensure that only authoritative results are received. An illustrative routine700for querying the providers to obtain authoritative results is discussed below with reference toFIG. 7. If the results may be non-authoritative, the routine500continues from operation508to operation512, where the providers in the ordered list are queried in a manner designed to retrieve results that may or may not be authoritative. An illustrative routine800for retrieving non-authoritative results is discussed below with respect toFIG. 8. From operations510and512, the routine500continues to operation514, where the results received from the providers are returned to the calling application. The calling application may then utilize the results to establish a connection to or otherwise communicate with the computer at the network address specified in the results. From operation514, the routine500continues to operation516, where it ends.

Referring now toFIG. 6, an illustrative routine600will be described for generating a sorted sub-list of providers that are likely to be able to resolve the e-mail address specified in the resolution request. In particular, the routine600begins at operation602where any providers not registered as a primary provider for the specified domain, as a secondary provider for the specified domain, or as a wildcard provider are removed from the list. This ensures that no providers will be queried that cannot possibly resolve the specified domain. From operation602, the routine600continues to operation604.

At operation604, the remaining providers are sorted. In particular, the providers are sorted in order of their potential ability to return authoritative results in response to the resolution request. Sorting this list in this manner results in the primary provider for the specified domain, if any, to be located at the beginning of the list. The primary provider is followed in the list by any secondary providers for the specified domain and, finally, any wildcard providers are listed last. As will be described in detail below with reference toFIG. 7, the order of the providers in the ordered list determines the order in which the providers are called to resolve the specified name. From operation604, the routine600continues to operation606, where the sorted list of providers is returned to the provider call dispatcher304.

Turning now toFIG. 7, an illustrative routine700will be described for resolving the specified name where authoritative results are required. In particular, the routine700begins at operation702, where the ordered list of providers is received by the provider call dispatcher304. The routine700then continues to operation704, where the value of a temporary variable utilized to store data identifying the current provider in the list is set as the first provider in the list. From operation704, the routine700continues to operation706, where a LRPC resolution request is transmitted to the current provider for the specified name. Once the request has been made, the routine700continues to operation708, where a determination is made as to whether the current provider is the primary provider for the specified domain. If so, the routine700branches to operation710, where a determination is made as to whether an authoritative response to the request has been received.

An authoritative response may be positive indicating that an error did not occur and that the provider was able to resolve the name, or negative indicating that an error did not occur and the provider could not resolve the name. A positive authoritative response indicates that other providers should not be permitted to give back a negative response or a different positive response. Negative authoritative responses indicate that other providers should not be able to return a positive authoritative response, and therefore other providers are not tried when authoritative results are required. The provider may alternatively return an error response. When an error response is received, other providers are tried because secondary providers may be able to service the request even though the primary or another secondary provider could not.

Accordingly, if at operation710it is determined that an authoritative response was received, the routine700branches from operation710to operation714, where the authoritative response is returned. If at operation710it is determined that an authoritative response was not received, the routine700branches from operation710to operation712, where the current provider in the ordered list is set to the first secondary provider in the list. From operation712, the routine700continues to operation706, where the current provider is requested to resolve the specified name.

If at operation708, it is determined that the current provider is not the primary provider for the specified domain, then the routine700continues from operation708to operation718. At operation718, a determination is made as to whether the current provider is a secondary provider. If so, the routine700branches from operation718to operation720. At operation720, a determination is made as to whether an authoritative response has been received from the current provider. If so, the routine700branches from operation720to operation714, where the authoritative response is returned. Otherwise, the routine700continues from operation720to operation722, where a determination is made as to whether more secondary providers remain to be tried. If not, the routine700continues from operation722to operation724, where the current provider is set to the first wildcard provider in the list. If so, the routine700branches to operation726, where the current provider is set to the next secondary provider in the list. From operations724and726, the routine700continues to operation706where a resolution request is transmitted to the current provider.

If at operation718, it is determined that the current provider is not a secondary provider, then the routine700continues from operation718to operation730. At operation730a determination is made as to whether an authoritative response has been received from the current wildcard provider. If so, the routine700branches from operation730to operation714, where the authoritative response is returned. If not, the routine700branches from operation730to operation732, where a determination is made as to whether additional wildcard providers remain to be tried in the ordered list. If so, the routine700branches from operation728, where the current provider is set to the next wildcard provider in the list. Otherwise, the routine700branches from operation732to operation734, where failure is returned. From operations734and714, the routine700continues to operation716, where it returns to operation514, described above with reference toFIG. 5.

Referring now toFIG. 8, an illustrative routine800will be described for resolving the specified name where authoritative results are not required. In particular, the routine800begins at operation802, where the ordered list of providers is received by the provider call dispatcher304. The routine800then continues to operation804, where the value of a temporary variable utilized to store data identifying the current provider in the list is set as the first provider in the list. From operation804, the routine800continues to operation806, where a LRPC resolution request is transmitted to the current provider for the specified name.

Once the resolution request has been made at operation806, the routine800continues to operation708, where a determination is made as to whether any response has been received from the current provider. If so, the routine800continues to operation810, where the response is saved. Otherwise, the routine800branches from operation808to operation812, where a determination is made as to whether the list includes more providers that should be tried. If so, the routine800branches from operation812to operation814, where the current provider is set to the next provider in the list. From operation814, the routine800continues to operation806, where the current provider in the list is requested to resolve the specified name.

If at operation812, it is determined that the list does not contain more providers to try, the routine800continues to operation816. At operation816, all of the saved responses from the providers are returned in response to the resolution request. From operation816, the routine800continues to operation818, where it returns to operation514, described in detail above with respect toFIG. 5. It should be appreciated that, although not illustrated inFIG. 8, the resolution requests may be transmitted in parallel to each of the providers in the list.

According to other embodiments, a client application102may call the resolution APIs provided herein with a request to retrieve the names that can be published on the system easily. In particular, according to one implementation, a client application102can request from the naming providers108A-108N all of the names for which they can publish without any additional configuration or information. This occurs, for instance, when a naming provider includes both the name and a corresponding password. Therefore, each provider that has the name stored along with the corresponding credentials returns a name to the calling client. This is useful because it allows a client application102to identify the publishable names and prompt the user for which name to use rather than requiring the user to type in a name that they may not remember, misspell, or otherwise provide incorrectly.

Referring now toFIG. 9, an illustrative computer architecture for a computer100utilized in the various embodiments presented herein will be discussed. The computer architecture shown inFIG. 9illustrates a conventional desktop, laptop computer, or server computer. The computer architecture shown inFIG. 9includes a central processing unit902(“CPU”), a system memory908, including a random access memory914(“RAM”) and a read-only memory (“ROM”)916, and a system bus904that couples the memory to the CPU902. A basic input/output system containing the basic routines that help to transfer information between elements within the computer100, such as during startup, is stored in the ROM916. The computer100further includes a mass storage device910for storing an operating system918, application programs, and other program modules, which will be described in greater detail below.

The mass storage device910is connected to the CPU902through a mass storage controller (not shown) connected to the bus904. The mass storage device910and its associated computer-readable media provide non-volatile storage for the computer100. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed by the computer100.

According to various embodiments, the computer100may operate in a networked environment using logical connections to remote computers through a network112, such as the Internet. The computer100may connect to the network112through a network interface unit906connected to the bus904. It should be appreciated that the network interface unit906may also be utilized to connect to other types of networks and remote computer systems. The computer100may also include an input/output controller912for receiving and processing input from a number of other devices, including a keyboard, mouse, or electronic stylus (not shown inFIG. 9). Similarly, an input/output controller may provide output to a display screen, a printer, or other type of output device (also not shown inFIG. 9).

As mentioned briefly above, a number of program modules and data files may be stored in the mass storage device910and RAM914of the computer100, including an operating system918suitable for controlling the operation of a networked computer, such as the WINDOWS XP operating system from MICROSOFT CORPORATION of Redmond, Wash., or the WINDOWS VISTA operating system, also from MICROSOFOT CORPORATION. The mass storage device910and RAM914may also store one or more program modules. In particular, the mass storage device910and the RAM914may store an application program102, Winsock APIs204, an e-mail namespace shim206, and one or more naming providers108. Each of these software components has been described in great detail above.

Based on the foregoing, it should be appreciated that systems, methods, and computer-readable media for resolving names to network endpoints are provided herein. Although the subject matter presented herein has been described in language specific to computer structural features, methodological acts, and computer readable media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features, acts, or media described herein. Rather, the specific features, acts and mediums are disclosed as example forms of implementing the claims. The subject matter described above is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter described herein without following the example embodiments and applications illustrated and described, and without departing from the true spirit and scope of the present invention, which is set forth in the following claims.