Community Hub0 Subscribers
Community hub
Service discovery
View on Wikipediafrom Wikipedia
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
Service discovery is the process of automatically detecting devices and services on a computer network. It aims to reduce the manual configuration effort required from users and administrators. A service discovery protocol (SDP) is a network protocol that helps accomplish service discovery.
Service discovery requires a common language to allow software agents to make use of one another's services without the need for continuous user intervention.[1]
Protocols
[edit]There are many service discovery protocols, including:
- Bluetooth Service Discovery Protocol (SDP)
- Bonjour, e.g., Apple AirPrint
- DNS Service Discovery (DNS-SD), a component of zero-configuration networking
- DNS, as used for example in Kubernetes
- Dynamic Host Configuration Protocol (DHCP); its classification as a service discovery protocol is controversial
- Internet Storage Name Service (iSNS)
- Jini for Java objects.
- Lightweight Service Discovery (LSD), for mobile ad hoc networks [2]
- Link Layer Discovery Protocol (LLDP) standards-based neighbor discovery protocol similar to vendor-specific protocols which find each other by advertising to vendor-specific broadcast addresses (versus all-1's), such Cabletron (Enterasys) and Cisco Discovery Protocol (both referred to as CDP but different formats).
- Local Peer Discovery, or Local Service Discovery
- Multicast Source Discovery Protocol (MSDP), usually used for unicast exchange of multicast source information between anycast Rendez-Vous Points (RPs) to service mcast clients.
- Service Advertising Protocol used in Novell NetWare networks with IPX
- Service Location Protocol (SLP)
- Session Announcement Protocol (SAP) used to discover RTP sessions
- Simple Service Discovery Protocol (SSDP), a component of Universal Plug and Play (UPnP)
- Universal Description Discovery and Integration (UDDI) for web services
- Universal Service Discovery Protocol (USDP)
- Web Proxy Autodiscovery Protocol (WPAD)
- WS-Discovery (Web Services Dynamic Discovery)
- XMPP Service Discovery (XEP-0030)
- XRDS (eXtensible Resource Descriptor Sequence) used by XRI, OpenID, OAuth, etc.
See also
[edit]References
[edit]- ^ Berners-Lee, Tim (2001-05-01). "The Semantic Web". Scientific American. 284 (5): 34–43. Bibcode:2001SciAm.284e..34B. doi:10.1038/scientificamerican0501-34. Retrieved 2008-03-13.
- ^ Lim, Byong-In; Choy, Kee-Hyun; Shin, Dong-Ryeol (2005). Sunderam, V.S.; van Albada, G.D.; Sloot, P.M.A.; Dongarra, J. (eds.). An Architecture for Lightweight Service Discovery Protocol. International Conference on Computational Science. Springer Berlin Heidelberg. pp. 963–966. doi:10.1007/11428862_148. ISBN 978-3-540-32118-7.
External links
[edit]- Service Discovery S-Cube Knowledge Model
- Dong, H., Hussain, F.K., Chang, E.: Semantic Web Service matchmakers: State of the art and challenges[Online]. Concurrency and Computation: Practice and Experience 25(7) (May 2013) pp. 961–988. Accessed on June 16, 2015.
- Sun, L., Dong, H., Hussain, F.K., Hussain, O.K., Chang, E.: Cloud service selection: State-of-the-art and future research directions. Journal of Network and Computer Applications[Online] 45 (October 2014) pp. 134–150. Date accessed: 16 June 2015.
Service discovery
View on Grokipediafrom Grokipedia
Introduction
Definition
Service discovery refers to the automated process of detecting and locating services, devices, or resources within a computer network or distributed system, enabling clients to connect to them using logical identifiers rather than fixed physical addresses.[5] This mechanism eliminates the need for manual configuration by allowing services to dynamically advertise their presence and availability, facilitating seamless communication in environments where network topologies frequently change.[6] In essence, it serves as a directory service that maps high-level service names to low-level details, such as IP addresses and ports, promoting scalability and resilience in modern architectures like microservices and cloud-native applications.[7] At its core, service discovery involves two primary components: service registration, where providers announce their availability to a central registry or peer network by sharing metadata including IP addresses, ports, and operational capabilities; and service lookup, where clients query this registry to retrieve up-to-date location and attribute information for the desired services.[7] This metadata often encompasses health status, version details, and custom tags, allowing clients to select appropriate instances based on specific requirements.[7] Unlike static configurations, such as hardcoded IP addresses in application code, service discovery operates dynamically to accommodate runtime changes like service failures, scaling events, or migrations, ensuring continuous availability without human intervention.[6] For example, if a service instance fails, the registry can immediately update its records, preventing clients from attempting invalid connections.[8] Service discovery paradigms generally fall into client-side and server-side models, with hybrid approaches combining elements of both. In the client-side (pull) model, clients actively query the registry for service locations and handle routing decisions themselves, offering flexibility but requiring robust client logic.[9] Conversely, the server-side (push) model relies on an intermediary, such as a load balancer or proxy, that receives notifications from the registry and directs traffic accordingly, simplifying client implementation at the cost of a potential central bottleneck.[9] Hybrid systems, like those using API gateways, blend these by querying for initial locations while leveraging proxies for ongoing traffic management.[10] Protocols such as DNS-SD exemplify these concepts in local networks by enabling zero-configuration discovery through standard DNS extensions.[11]Historical development
The concept of service discovery emerged in the mid-1990s as networks grew more complex, with the Service Location Protocol (SLP) marking an early milestone in 1997. Developed by the IETF, SLP provided a directory-based framework for automatic resource discovery on IP networks, particularly suited for enterprise environments where applications needed to locate services like printers or file servers without manual configuration.[12] This protocol addressed the limitations of static configurations in local area networks, enabling user agents to query directory agents for service information.[13] In the late 1990s, several influential systems built on these foundations to support distributed and consumer-oriented applications. Sun Microsystems introduced Jini in 1998 as a Java-based architecture for dynamic service discovery in distributed systems, emphasizing lookup services that allowed devices and software to join and find each other seamlessly. Concurrently, the Universal Plug and Play (UPnP) Forum was established in 1999, promoting the Simple Service Discovery Protocol (SSDP) for device interoperability in home and small office networks. SSDP enabled multicast-based announcements and searches, facilitating plug-and-play connectivity for multimedia devices without central administration.[14] The 2000s saw advancements toward zero-configuration networking, reducing setup overhead in ad-hoc environments. Zeroconf, formalized through the IETF working group starting in 1999 and gaining traction around 2000, introduced mechanisms like Multicast DNS (mDNS) for name resolution and DNS-Based Service Discovery (DNS-SD) for locating services on local links without DNS servers.[15] Apple commercialized these ideas in 2002 with Bonjour (initially Rendezvous), integrating mDNS and DNS-SD into macOS to enable effortless discovery of printers, shared files, and media devices across networks.[16] The 2010s marked a shift to cloud-native and containerized ecosystems, driven by the proliferation of microservices, mobile devices, and Internet of Things (IoT) applications that demanded scalable, dynamic discovery in large-scale, ephemeral environments. CoreOS released etcd in 2013 as a distributed key-value store supporting service registration and coordination, which became integral to Kubernetes for cluster-wide service discovery via watches and leases. In 2014, HashiCorp launched Consul, a tool for service mesh environments that combined DNS and HTTP interfaces for health-checked discovery, addressing the needs of multi-datacenter deployments in cloud infrastructures.[17] These developments were propelled by the explosive growth of mobile computing, IoT ecosystems requiring billions of interconnected devices, and microservices architectures favoring loose coupling over monolithic designs.Core concepts
Service registration
Service registration is the process by which services announce their availability and details to a discovery system, enabling other components to locate and interact with them. Typically, a service provides metadata such as its unique name, type (e.g., HTTP or TCP), endpoint (address and port), and health status to a central registry or through network broadcasts. This registration can occur via API calls to a registry server or by publishing records in a distributed manner, ensuring the service instance is discoverable within the system.[18][19] Two primary models govern service registration to maintain accuracy and detect failures: heartbeat mechanisms and lease-based systems. In heartbeat mechanisms, registered services periodically send updates—known as heartbeats—to the registry at fixed intervals, such as every 30 seconds, to confirm ongoing availability; failure to send heartbeats prompts the registry to mark the service as unhealthy or remove it after a timeout, often around 90 seconds. Lease-based systems assign a time-to-live (TTL) duration to each registration, requiring the service to renew the lease explicitly before expiration; unrenewed leases automatically expire, providing a self-cleaning mechanism without relying on failure detection logic. These models ensure dynamic updates in distributed environments, balancing responsiveness with overhead.[20][21] Metadata in service registrations follows standardized formats to facilitate interoperability, often using key-value pairs for flexible attributes like version, capabilities, or configuration details. Entries may include TTL values to control expiration, and versioning mechanisms allow updates without disrupting existing registrations, such as incrementing a version field in the metadata. For instance, TXT records in DNS-based systems encode metadata as concatenated key-value strings (e.g., "path=/api" or "version=1.0"), limited to recommended sizes for efficient transmission. This structure supports both static and dynamic information, enhancing service discoverability.[19][21] In Consul, services register via the agent's HTTP API endpoint (/agent/service/register), submitting a JSON payload with the service name, address, port, and optional health checks; these checks can be TTL-based, where the service must issue periodic "pass" updates within the specified interval (e.g., 15 seconds) to maintain a healthy status, or other types like HTTP probes for endpoint validation. Similarly, in Multicast DNS (mDNS) for local networks, services publish their details by announcing PTR records for service types, SRV records for host and port, and TXT records for additional metadata via multicast broadcasts, enabling zero-configuration discovery without a central registry. These examples illustrate how registration integrates health monitoring directly into the announcement process, supporting reliable service maintenance in diverse architectures.[18][19]Service lookup
In service discovery systems, lookup refers to the process by which clients identify and obtain access details for available service instances, enabling dynamic communication in distributed environments.[9] This mechanism relies on prior service registration to populate a central registry or directory with instance metadata, such as endpoints and attributes.[4] The query process typically involves clients sending requests to a service registry or using multicast protocols to discover services based on criteria like type, location, or tags. For instance, in DNS-based service discovery (DNS-SD), clients initiate lookups by querying pointer (PTR) records for a service type, such as_http._tcp.example.com, which returns a list of instance names.[22] In registry-based systems like Consul, clients query the catalog via HTTP API or DNS, filtering results by service name (e.g., service-name.service.consul) and health status.[4]
Resolution steps follow the query, where clients retrieve and select from available endpoints, often incorporating load balancing to distribute traffic across instances. In DNS-SD, this entails querying service (SRV) records for a specific instance to obtain the target hostname and port, followed by address (A/AAAA) records for IP resolution; additional text (TXT) records provide metadata like capabilities.[22] Client-side frameworks, such as Netflix Ribbon integrated with Eureka, handle this by resolving logical service names to physical addresses and applying weighted round-robin load balancing among healthy instances.[9]
To manage dynamic environments where services scale, fail, or migrate, lookup systems incorporate retry logic, fallback strategies, and notifications for changes. Clients may retry failed queries with exponential backoff to account for transient registry unavailability, falling back to locally cached endpoints if the registry is unreachable.[23] In Consul, event-driven notifications via blocking queries or watches alert clients to updates, such as instance health changes, reducing polling overhead.[4] DNS-SD supports ongoing browsing for live updates as services join or leave the network, with clients re-resolving SRV records periodically to handle IP changes without full re-browsing.[22]
Common patterns for lookup include pull-based and push-based approaches, balancing efficiency and responsiveness. Pull-based lookup, as in periodic DNS-SD queries or client polls to a registry, suits environments with stable topologies but can introduce latency during changes.[22] Push-based mechanisms, exemplified by Consul's subscription model where the registry notifies subscribers of updates via long-polling or streams, enable real-time awareness and are preferable for highly dynamic systems like microservices.[4] Caching resolved endpoints locally further optimizes performance, with TTLs ensuring freshness while minimizing registry load.[9]