BACKGROUND

[0001] Devices often communicate with each other over networks to exchange information. For any two devices that need to exchange data, network communication can potentially involve many protocols, from the application layer down through the link layer. In some cases, two devices may have software that implements a same application-layer protocol. For discussion, the software might be peer components on respective devices, where the peer components are to exchange information according to the application-layer protocol. Although the two devices might be capable of forming a network connection through which their peer components might exchange messages, such an exchange can be difficult when a network connection cannot be formed because one peer is not aware of the other peer's existence or in particular its network address.

[0002] This kind of connectivity problem often occurs when the application-layer protocol implemented by the peers assumes that one or more particular lower layer protocols are available for discovering other devices on the network. For instance, the application- layer protocol might be a media streaming protocol designed to use a WiFi advertising mechanism to discover other WiFi devices. One of the peer devices might not implement the advertising mechanism, or, the devices might be out of range of each other. Although the peers might be capable of exchanging their application-layer data if a network connection were established, the inability to discover each other prevents such communication. They might be incapable of "seeing" each other using the link-layer discover mechanism, and yet a network/transport layer connection - and hence peer communication - would be possible if they were able to discover each other through other means.

[0003] Device-to-device connectivity at the application layer can be difficult due to other problems. For example, a network discovery mechanism at any layer might discover an excessive number of nodes, perhaps in the hundreds or thousands. If all such discovered devices are provided to an application and displayed for a user to select a target device for the application to connect to, the large number of devices shown makes it difficult for the user to find a suitable or particular device. In addition, many of the devices might not be relevant to the current conditions, application, user, etc. The user might know that the desired target device is in the same room, is within a certain radio range is on a same network segment, or is a certain type of device, and yet devices that do not meet those conditions are displayed for potential selection by the user.

[0004] In addition, any given device needing to form a connection might have many mechanisms available for device discovery. A device might have application-level discovery mechanisms such as directory services, Domain Name System (DNS) discovery protocols such as DNS-SD (Service Discovery) and the Simple Service Discovery Protocol (SSDP). The device might also have discovery features in its implementations of network- level protocols, such as Internet Protocol (IP) multicast extensions, the IPv6 Network Discovery Protocol (NDP), and others. Many link-layer protocols also include discovery facilities for discovering nodes available for a particular link-layer protocol. For example, Bluetooth has various types of broadcast beacons that announce or solicit device presence. WiFi Direct also has advertise/discover functions.

[0005] For a network with many and various devices, there might be dozens or hundreds of protocols that any two devices might potentially use to discover one another. However, most application-level software is coded to inflexibly use only one or a few discovery mechanisms. If multiple discovery mechanisms are used, it is in an uncoordinated disjoint manner. For instance, if two different discovery mechanisms are used by one application, then there might be, respectively, two different user interfaces (UIs), two different paths of connection logic, two different purposes for discovery, etc. While a device might have four or five means for discovering other devices on the network or devices that are nearby and capable of link-level or network-level connectivity, any given application on that device might be configured to use only one of the discovery means and therefore fail to take advantage of its device's full discovery capability.

[0006] There is a need to allow arbitrary application-level software to transparently use a variety of network discovery mechanisms in a coherent manner and in a way that allows the scope and results of discovery to fit a current usage context.

SUMMARY

[0007] The following summary is included only to introduce some concepts discussed in the Detailed Description below. This summary is not comprehensive and is not intended to delineate the scope of the claimed subject matter, which is set forth by the claims herein.

[0008] A computing device is provided with a discovery framework that may include a discovery user interface (UI) and a discovery engine configured to use various standard discovery protocols in a protocol stack of the computing device. The discovery engine may respond to an invocation of the discovery framework by determining discovery criteria and based thereon selecting one of the discovery protocols, requesting discovery through the selected discovery protocol, receiving corresponding first discovery results, and maintaining a discovery list comprised of indicia of devices discovered through at least the selected discovery protocol. The discovery UI allows interactive adjustment of the discovery criteria, displays the discovery list, and responds to selection of a discovered device in the discovery list by enabling a connection with the discovered device based on a network address of the discovered device obtained through one of the discovery protocols.

[0009] Many of the attendant features will be explained below with reference to the following detailed description considered in connection with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The embodiments described herein will be better understood from the following Detailed Description read in light of the accompanying Drawings, wherein like reference numerals are used to designate like parts in the accompanying description.

[0011] Figure 1 shows a discovery framework on a host.

[0012] Figure 2 shows details of the discovery framework.

[0013] Figure 3 shows details of how a discovery engine is used.

[0014] Figure 4 illustrates how the scope of device discovery may change dynamically based on user steering through a user interface of the discovery framework.

[0015] Figure 5 shows different discovery mechanisms that can be used by the discovery engine.

[0016] Figure 6 shows how discovery results from various discovery protocols can be collected and normalized into a coherent namespace of unique device identities.

[0017] Figure 7 shows an example of a master device identities table.

[0018] Figure 8 shows an example of an application configured to use the discovery framework.

[0019] Figure 9 shows the discovery user interface displayed by an application that uses the discovery framework.

[0020] Figure 10 shows how the discovery user interface can interactively control the scope of device discovery.

[0021] Figure 11 shows an example of the discovery user interface initiating a new connection.

[0022] Figure 12 shows details of a computing device. DETAILED DESCRIPTION

[0023] Embodiments of a network discovery framework are discussed below.

Discussion will begin with an overview of a network discovery framework and its general context. Major functions of a discovery framework are described next, followed by discussion of how a same discovery framework can manage multiple contexts or discovery sessions for multiple applications or the like. Next, dynamic user-controlled scoping and refinement of a discovery list is explained. Examples of standard underlying discovery mechanisms and protocols are then covered, including details of how to build the results of disparate discovery protocols into a coherent normalized set of discovered devices. Finally, uses and features of a user interface provided by a discovery framework are described.

[0024] Figure 1 shows a discovery framework 100 on a host 102. The discovery framework 100 is shown as part of an operating system 104. However, the framework can be implemented in any way that makes it available to arbitrary application-level code that needs to discover devices for connecting thereto. For example, the framework may be a shared library, a background service, a component of a managed runtime environment, etc. Generally, the discovery framework 100 is accessed through some form of software interface, application programming interface (API), interprocess communication, or the like. The framework can be invoked and used by any software on the host 102. For instance, different applications 106 might each interface with the discovery framework 100. However, any code can invoke the framework. For example, a graphical user shell might have different elements that each have their own connectivity and discovery needs; each element may use the discovery framework in a customized way. As discussed below, in one embodiment, the framework manages a different context for each instance of its use or invocation by an application or other software.

[0025] The discovery framework 100 has two major functions or modules, namely, a discovery UI 108 and a discovery engine 110. The discovery UI 108 (or instances thereof) is displayed in the windows of the application-layer code where device discovery is needed. Alternatively, the discovery UI has its own window. The discovery UI 108 is for (i) allowing a user to interactively steer the discovery engine's discovery of devices and shaping the results, (ii) displaying indicia of the discovered devices (e.g., a list of device names and pieces of device information), and (iii) allowing discovered devices to be interactively selected and in response configured for connectivity, for instance by assigning the network name/address of the selected device to an application-level configuration setting, and/or initiating network-level and/or application-level connectivity to the selected device, etc. [0026] The discovery engine 110 discovers devices as specified by the discovery UI

108 and/or discovery criteria. The discovery engine 110 is configured to interface with a variety of standard discovery protocols. The discovery engine 110 manages the discovery of devices 112 over one or more networks 114 according to various conditions, underlying discovery protocols, or discovery features of communication protocols. The discovery engine 110 uses arbitrary and perhaps standard discovery protocols to collect information about the devices 112. The devices 112 can be any type of device with the means to potentially communicate with the host 100. For example, devices 112 may be mobile phones, laptops, appliances with network connectivity, virtual machines, servers, displays such as projectors, sensors, printers, and so on. As discussed below, the discovery engine 110 collects responses to discovery requests, normalizes the discovery information, and provides indicia of discovered devices 112 for display and selection in the discovery UI 108. As used herein, "discovery protocol" refers to any communication protocol either specifically designed for device discovery or any communication protocol that includes a component for device discovery.

[0027] Figure 2 shows details of the discovery framework 100. As noted, any arbitrary code such as applications 106 can invoke the discovery framework through an API or the like. The discovery framework 100 has a context manager 130 to keep track of sessions or individual invocations of the discovery framework 100. When an application invokes the discovery framework 100, a new context 131 is created and associated with the invoker. The context 131 stores all of the discovery state for the corresponding invoker, for instance, discovery criteria, user interface state, etc. The context manager 130 creates and manages the lifetime of contexts 131. The context manager 130 also performs processes 132 for instantiating contexts 131, handling updates to contexts, and using the contexts to provide each application 106 or other invoker with the correct corresponding discovery results and the corresponding state of the discovery UI 108. Thus, each piece of code using the discovery framework 100 appears to have its own independent discovery mechanism with its own individual state, yet resources of the discovery framework such as discovery functionality, UI appearance and logic, and underlying discovery results can be shared. In one embodiment, contexts are partly persisted. For instance, when an application has invoked the framework, if the application specifies some discovery parameters, or if the discovery UI 108 is used to express preferences for displaying or filtering discovery results, or if a discovered device is selected for a connection, etc., then this type of information is persisted in the corresponding context after the application terminates or otherwise ends its session with the framework. When the application again invokes the framework, for instance after a new execution of the application, then the application can continue with at least some of its prior discovery state.

[0028] As noted above, a new context might be initialized with various values. In one embodiment, a discovery type is associated with the new context. This might be done explicitly by the invoker passing in an explicit type parameter (e.g., "typel ") or implicitly by inferring a type from features of the invoker. The type, if any, is looked up in a table 134 of predefined discovery types, each having a respective set of discovery criteria. The looked- up criteria are copied in to the corresponding context to initialize the discovery criteria for that context. Once initialized, if at all, the discovery criteria for a context can be updated interactively by user interaction with the discovery UI 108. Alternatively, each new context is assigned default values.

[0029] In another embodiment, each invocation of the discovery framework creates a new autonomous instance of the discovery framework. In this case, context management is not needed and each framework instance has its own discovery configuration and data.

[0030] The discovery framework 100 may be implemented so that the discovery UI

108 acts as a near real-time regulator of the scope and content of discovery. When the discovery UI 108 is interacted with to, for example, expand or contract the scope of discovery for the corresponding context/application, any necessary additional discovery searches (e.g., using an additional discovery protocol) are responsively performed and results thereof may populate the discovery UI 108 with newly discovered devices. In this way, a user is able to evaluate what has been discovered and interactively contract or expand the scope of network discovery of devices. Similarly, the current set of discovery results can be interactively filtered, reordered, etc., and which discovered devices are displayed in the discovery results expands and contracts accordingly.

[0031] To enable this interactive steering of discovery and how discovery results are presented, a monitor 138 may be included. The monitor 138 may perform a process 139 that monitors for changes to contexts. When a change is detected the discovery engine 110 is informed and any needed actions are taken, such as issuing a new discovery request to the network. Similarly, the monitor 138 can monitor activity of the discovery engine 110 to assure that the discovery UI 108 remains consistent with the current discovery criteria. In some embodiments, discovery results are provided to the discovery UI 108 asynchronously so that the discovery UI 108 populates with indicia of devices as they are discovered. [0032] The discovery engine 110 uses the various available discovery protocols

(discussed below) to discover new devices, stores results, and normalizes or canonicalizes the results into a coherent set of discovered device identities. Discovery may be guided by the discovery criteria of a given context. When the monitor 138 detects a change to a context's discovery criteria, the discovery engine 110 may be signaled to update the discovery search for the context. In turn, a discovery process 140 is performed. The relative discovery criteria are evaluated by the discovery engine 110. The discovery engine 1 10 may determine whether the discovery search needs to be expanded with a new discovery source.

[0033] Figure 3 shows details of how the discovery engine 110 is used. For discussion, it will be assumed that some application ("APP N") or other software has invoked the discovery framework 100 and has a corresponding context 131 ("CONTEXT N"). The context 131 stores or accesses UI state 150, discovery criteria 152, and a current discovery list 154. At step 155, controls 156 of the discovery UI 108 may be manipulated by a user. For example, an "expand search" button might be activated, a new discovery criteria might be added, a search string might be inputted in a text box, a desired type of device might be selected, a minimal degree of proximity is inputted, etc. This change to the UI state 150 updates the discovery criteria 152 (the UI state and the discovery criteria may be one and the same). In response, at step 158 the discovery engine 110 evaluates the updated discovery criteria and performs any underlying discovery inquiries that might be needed. Alternatively or additionally, at step 159 the current discovery list 154 is updated, which flows through to a device list element 160; indications 162 of discovered devices reflect which devices have been discovered according to the updated discovery criteria 152.

[0034] Figure 4 illustrates how the scope of device discovery or the devices in the current discovery list 154 may change dynamically based on user steering through the discovery UI. The shapes and shades of the graphics representing discoverable devices 112 represent different discovery mechanisms or protocols that might be implemented by the devices, different filterable features of the devices, and so forth. That is, factors that might affect whether a device is discovered or considered relevant to current criteria. Initially, the operative device or host 102 invokes the discovery framework. The discovery framework may start with some initial discovery criteria, either explicitly seeded with initialization parameters by the caller of the framework, by default, by inference, according to a previously stored context of the invoker, etc. At this initial state ("STAGE 1 " in Figure 4), the discovery engine might determine that only a single discovery protocol is needed, for instance, a Bluetooth discovery packet might be broadcasted. Devices 112 that answer the Bluetooth discovery request are represented by shaded squares. Thus, the current discovery list at STAGE 1 includes four devices, some or all of which are displayed in the device list element 160. If, after this first stage of discovery, the user does not find a desired device, then the scope of discovery may be expanded either by explicit user input or automatically, for instance based on passage of time or other conditions such as passive receipt of advertisement beacons or packets.

[0035] At a next state of discovery ("STAGE 2"), the user may have indicated that additional discovery is needed. The discovery engine may expand the scope of discovery in a number of ways. For instance, a Bluetooth discovery might be initiated for additional device types or a lower minimum signal strength. A new discovery protocol might be added to the mix. As shown in Figure 4, at the second stage the variety and number of discovered devices has been expanded. Similarly, if additional user input indicates that a desired device has still not been found, then the discovery may be expanded again ("STAGE 3"), for example, by invoking yet another search mechanism (e.g., multicast DNS) or loosening another search constraint. At each stage, the discovery UI might be updated to reflect the current discovery list, additional search constraints, result-ordering options, discovery options, etc. In some cases, adding filtering criteria might, counterintuitively, expand the number of discovery protocols in use. For example, if a string matching condition is inputted by a user, although this condition might reduce the number of displayed devices (by filtering), some form of DNS query might be added to the mix of discovery protocols.

[0036] Figure 5 shows different discovery mechanisms that can be used by the discovery engine 110. The discovery engine has a discovery querier 180 or similar component that is configured to interface with various discovery protocols. Regarding the discovery protocols, the host's operating system 104 has an ordinary communication or protocol stack 182, with modules or implementations of various communication protocols, some of which may be dedicated for discovery, others which may be communication protocols that happen to include a discovery mechanism (collectively referred to herein as "discovery protocols"). The discovery protocols can be used at any layer, including the application layer 184, transport layer 186, network layer 188, and link layer 190. In addition, some discovery mechanisms may be used that do not involve network communication, for example, Quick Response (QR) codes and inaudible sound.

[0037] Among the discovery protocols that might be used at the application layer

184 are various DNS mechanisms such as DNS Service Discovery (DNS-SD), Multicast DNS (M-DNS). Well known directory services may also be used, for instance various Lightweight Directory Access Protocol (LDAP) implementations, Active Directory (TM), Simple Network Management Protocol (SNMP), etc. Service discovery protocols may also be used to discover devices, such as Dynamic Host Configuration Protocol (DHCP), the Simple Service Discovery Protocol (SSDP), or others. At the transport layer 186 there may not be protocols dedicated to discovery per se, however, some of the transport protocols may have discovery components. For example, the Universal Datagram Protocol (UDP) may include a broadcast feature 192 that can be used to obtain addresses of answering devices. At the network layer 188, several features may be available. For example, the Internet Protocol (IP) Neighbor Discovery (ND) 194 defined by IP version 6, the Internet Control Message Protocol (ICMP), and others may be used for network-level discovery of devices. At the link layer 190 a number of mechanisms may be available. The WiFi protocols alone include several discovery protocols. WiFi Direct protocols define transmissions for advertising and discovery. WiFi infrastructure, Bluetooth, and Ethernet implementations may each include ways to discover devices. For instance Ethernet modules sometimes implement the Link Layer Discovery Protocol. It should be noted that aspects of protocols not specifically designed for discovery can nonetheless be used to obtain clues about available devices. Discovery protocols can be implemented in ways other than wired/wireless electromagnetic radiation. For example, some devices may be capable of sound transmission and detection and at inaudible frequencies, and sound can be used akin to modems for discovery. The examples above are illustrative; other and new protocols are contemplated.

[0038] Figure 6 shows how discovery results from various discovery protocols can be collected and normalized into a coherent namespace. The discovery engine 110 is configured with logic to determine which discovery protocols are needed at any given time for any given context. In Figure 6, for some context and corresponding discovery criteria, the discovery engine 110 has determined initially that discovery protocol A 200 is needed. The discovery querier 180 is coded to interface with all of the available discovery protocols to formulate discovery requests and to receive results. Initially, a module or implementation of discovery protocol A 200 is instructed to issue a discovery request, for example, by formatting an appropriate message, packet, or frame and passing it out a corresponding network interface.

[0039] In response, the discovery querier 180 receives results 202 conformant to discovery protocol A. For example, the results might be DNS records, WiFi frames containing headers identifying devices that responded to the query, Bluetooth packets, or the like. Generally, results will contain, for each discovered device, one or more of: a network name and/or address (e.g., an IP address), a MAC address, metadata about the responding device, supported protocols, a Return Signal Strength Indicator (RSSI), or any other information of the type found in standard discovery protocols such as those discussed with reference to Figure 5.

[0040] Because the results from different discovery protocols may have different fields, formats, etc., the raw results are stored in a discovery cache 204 and are normalized therefrom. Each discovery protocol may have a table or other data structure for storing results with the format and/or content of the corresponding discovery protocol. For example, table A 206 stores results 202. Each record in table A 206 corresponds to a device discovered through discovery protocol A. Similarly, if the discovery criteria of the current context changes, then the discovery engine 110 might determine that the scope of discovery needs to be expanded to include discovery protocol B 208. A module or implementation of discovery protocol B is used by the discovery querier 180 to formulate another discovery request compliant with discovery protocol B. When additional results 210 are received through the network protocol stack and passed to the discovery querier 180, the additional results 210 are stored in table B 212 which may be specifically for storing data from discovery protocol B. Alternatively, pointers to results stored in discovery protocol modules/implementations may be used.

[0041] Because an objective of the discovery framework is to provide a coherent device namespace from which a user can select devices to connect to, the discovery framework may have a normalizer 214 and a deduplicator 216. The normalizer maps incoming discovery protocol results to a device identities table 218 using any fields of information that can indicate an association with a same device. The device identities table 218 contains a single master record for each discovered device. When a discovery result is received, for instance results 202, for each device therein, if needed, a new master device record is added to the device identities table 218. The master record of a device might be populated with various fields from the results 202, for instance an IP address of the device, a name, an estimated range or proximity rank, pointers to other discovery results in the discovery cache 204 for the same device, and so forth. Each device may be assigned a Unique Identifier (UID) for the device namespace, and the UID functions as a key that links the discovery data of a device to its master record. The deduplicator 216 may consolidate duplicate master records using known deduplication techniques, remove duplicate result records, or otherwise detect and remove duplicate data. [0042] In one embodiment, each context has its own independent discovery cache.

In another embodiment, each context shares the discovery cache as possible; the discovery cache is the union of discovery data of all of the contexts. In another embodiment, no raw discovery protocol results are cached or stored in tables, and instead, all data is translated and copied into the master identities table 218 when received. Generally, the provenance of the discovery data of a discovered device should be tracked, since dynamic discovery scoping decisions may depend on which discovery protocols have already been used or not. For example, if a master record of a device has a link to results table A, then it can be determined that protocol A has already been used to discover that device. If each context has its own discovery cache, the set of used protocols can be determined from which results tables exist or contain data.

[0043] The discovery cache may or may not implement expiration logic. If discovery data is persisted, then the time to expire may depend on the particular discovery protocol, a type of the relevant context, or other factors. Generally, mobile devices will have short-lived discovery data, since the devices that are discoverable may depend on the changing location of the mobile device. That is, some devices may simply perform discovery protocol requests each time discovery data is needed for a given discovery protocol.

[0044] The discovery engine 110 may also have functionality or modules to provide access to the discovery data in the tables. For example, a query handler 220 may handle queries, received through an interface 222, for discovery data, by finding requested discovery data and returning same. A filter 224 may provide filtered views of the discovery data in the master device identities table. For example, if the discovery UI indicates that only wireless devices are to be discovered, then the filter 224 provides a corresponding subset of discovered devices. In effect the filter 224 provides a view of the master device identity table. In addition, a proximity estimator 226 may be included to populate the master device table with proximity measures or ranks. If RSSI data is available, then RSSI values can be used. Any means for estimating the physical proximity of a device may be used, and various factors can be combined in weighted fashion. For instance, RSSI data, indications of a device being in a same building or on a same network segment, discovered location data (e.g., GPS coordinates), etc., may be combined to estimate which devices are relatively closest.

[0045] Figure 7 shows an example of a master device identities table 218. Each record of a discovered device contains key discovered information, including for example a name or hostname, an IP address, an indication of the types of the device (e.g., speakers, display, an operating system), indicia of the discovery protocols used to find the corresponding device, a UID, and/or others. The device identities table 218 is the source of the list of discovered devices displayed in the discovery UI. The contents thereof (or a filtered subset) can be provided to the discovery UI by data binding, event-driven data updating, interprocess communication, software interfaces, etc.

[0046] Figure 8 shows an example of an application configured to use the discovery framework. A display 230 of the host 102 displays a window 232 of the application. The window 232 may display content 234 of any variety. The application is functionally linked to the discovery framework. For example, an operation or user interface element 326 might invoke the discovery UI. The operation might be related to a connectivity need of the application. For instance, if the application is about to attempt to connect to a peer application, then the discovery UI might be automatically displayed. If a user interface element 236 is used, for instance a button, then the discovery UI is displayed when the user interface element 236 is activated.

[0047] Figure 9 shows the discovery UI 108 displayed by an application that uses the discovery framework 100. In the example of Figure 9, the invocation of the discovery UI triggers a first automatic initial discovery request from one or more discovery protocols and the canonicalized discovered devices (the discovered device list) automatically populate the discovery UI. The discovery UI provides the ability to interactively select a device, for instance, in the form of selectable device indicators 240, a scrollable selector/cursor, a context menu, or the like. The discovery UI can be implemented, in some embodiments, to hide, delete its context, or take other actions if a device is selected. Moreover, selection of a device may trigger an application action such as attempting to form a connection with the selected device or setting a configuration setting to the selected device, its address, etc. As noted, in one embodiment, the discovery UI might automatically start to expand its scope of discovery automatically if a device is not selected after a threshold amount of time or in an insufficient number of devices are initially discovered.

[0048] The discovery UI may also have controls 242 to control the scope of discovery, filter the discovered device list, set an ordering criteria (e.g., by device name or proximity), refresh the search, etc. Filtering can be based on any type of discovery data or information associated with discovered devices. For example, indicia of previous connections or pairings at the application level may be stored and the discovered device list may be sorted to prioritize such devices or filtered to display only such devices. Devices may also be filtered or sorted based on device type, proximity, connectivity capabilities, and other features. As noted above, the displayed discovery list can be populated asynchronously as new discovery responses flow in from responding discovered devices. A string filter may also be included to allow the user to display only device whose names and/or associated metadata contains a user-specified string.

[0049] The discovery UI may also include elements to enable a discovered device to be selected or designated. For example, each displayed discovered device may be represented by an interactive graphic that responds to user activation by triggering an event, initiating a network connection to be handed to the calling context (e.g., application) of the discovery UI, configuring the calling context to connect to the selected device, etc.

[0050] Figure 10 shows how the discovery UI can interactively control the scope of device discovery. The controls 242 may include one or more elements, such as a find-button 252, that signal to the discovery engine that additional discovery is needed. Such a signal can also be implicitly generated responsive to passage of some threshold amount of time without selection of a device, too few devices having been found, scrolling to the end of the current discovery list, expansion of the current discovery criteria or filter conditions, etc. In any case, what is notable is the discovery framework providing arbitrary code with transparent abstract access to a suite of discovery protocols to discover connectable devices without exposing the user to details of the underlying discovery protocols, and with a consistent discover-and-connect experience regardless of the application or setting.

[0051] Returning to Figure 10, when the find-button 252 or other feature of the discovery UI indicates that the scope of discovery needs to be extended, the discovery engine responds accordingly by adding indications of new devices 254 to the discovery list. For example, devices discovered by additional discovery protocols may be added, devices that less precisely fit the discovery criteria may be included, etc. In one embodiment, the discovery expansion adds or switches the discovery protocols that supply the current discovery list. In Figure 10, activation of the find-button 252 leads to display of additional devices which can be selected.

[0052] Figure 11 shows an example of the discovery UI initiating a new connection. When indicator 240A for devicel is activated by a user input, because the device has been discovered with a discovery protocol, a network or media address of the device is available. That information, for instance from the master device table, is used to initiate a corresponding network-layer or link-layer connection to the selected device. As shown in Figure 11, the application may use the new network connection to exchange data with a remote application, for instance, a peer, client, server, etc.

[0053] Figure 12 shows details of a computing device 250 on which embodiments described above may be implemented. The host 102 shown in Figure 1 is a computing device 250. The technical disclosures herein constitute sufficient information for programmers to write software, and/or configure reconfigurable processing hardware (e.g., FPGAs), and/or design application-specific integrated circuits (ASICs), etc., to run on one or more of the computing devices 120 to implement any of features or embodiments described in the technical disclosures herein.

[0054] The computing device 250 may have a display 252, a network interface 254

(or several), as well as storage hardware 256 and processing hardware 258, which may be a combination of any one or more: central processing units, graphics processing units, analog- to-digital converters, bus chips, FPGAs, ASICs, Application-specific Standard Products (ASSPs), or Complex Programmable Logic Devices (CPLDs), etc. The storage hardware 256 may be any combination of magnetic storage, static memory, volatile memory, nonvolatile memory, optically or magnetically readable matter, etc. The meaning of the term "storage", as used herein does not refer to signals or energy per se, but rather refers to physical apparatuses and states of matter. The hardware elements of the computing device 250 may cooperate in ways well understood in the art of computing. In addition, input devices may be integrated with or in communication with the computing device 250. The computing device 250 may have any form factor or may be used in any type of encompassing device. The computing device 250 may be in the form of a handheld device such as a smartphone, a tablet computer, a gaming device, a server, a rack-mounted or backplaned computer-on-a-board, a system-on-a-chip, or others.

[0055] Embodiments and features discussed above can be realized in the form of information stored in volatile or non-volatile computer or device readable storage hardware. This is deemed to include at least storage hardware such as optical storage (e.g., compact- disk read-only memory (CD-ROM)), magnetic storage hardware, flash read-only memory (ROM), and the like. The information stored in storage hardware can be in the form of machine executable instructions (e.g., compiled executable binary code), source code, bytecode, or any other physical hardware having a physical state that can transfer information to processing hardware to enable or configure computing devices to perform the various embodiments discussed above. This is also deemed to include at least volatile memory such as random-access memory (RAM) and/or virtual memory storing information such as central processing unit (CPU) instructions during execution of a program carrying out an embodiment, as well as non-volatile media storing information that allows a program or executable to be loaded and executed. The embodiments and features can be performed on any type of computing device, including portable devices, workstations, servers, mobile wireless devices, and so on.