Service Discoverability

Service discovery protocols can be thought of as network protocols that allow for the automatic detection of both services and devices that are offered by a computer network’s various devices. There are a lot of service discovery protocols available. In this article, we will take a look at the attributes of three of the more popular ones – Service Location Protocol, Simple Service Discovery Protocol, and UDDI for Web Services.

Before we proceed, we should point out that a Service Discovery Protocol should not be confused with a Session Description Protocol. The latter is used to describe multimedia sessions for the purposes of session invitation, session announcement, and other forms of multimedia session initiation.

Service Location Protocol

The Service Location Protocol can be thought of as a service discovery protocol that allows for computers and other related devices to find services in a local area network sans prior configuration. Service Location Protocols have been designed to scale from smaller networked that are not managed to larger enterprise networks. In RFC 2608, Server Location Protocols are defined as Standards Track documents.

Service Location Protocol is employed by devices as a means of announcing services on a local network. Each service has to have a URL that is then utilized as a means of locating that service. What is more, it may have to have an unlimited amount of name value pairs, which are referred to as “attributes.”

Every device has to be always in at least one scope. Scopes can be thought of as simple strings. They are used as a means of grouping services. Scopes can be compared to the network neighborhood in other systems. A device is typically unable to see services that are located in different scopes.

A printer’s URL might resemble the following:

service:printer:lpr://ntprinter/prnqueue

Such a URL is descriptive of a queue called prnqueue that is situated on a printer with the host name ntprinter. The protocol that is used by this printer is LPR. Keep in mind that a special URL scheme called “service:” is also being employed by the printer.

These URLs are not necessary, but any URL scheme may be employed. Doing so allows you to search for all kinds of services of the same type, regardless of the protocol they employ.

The three premiere components of the URL type “service:” are also referred to as server type. The first of these two components are referred to as “abstract service type.” In a URL schema that is not related to “service:”, the name will always be for the service type.

So a printer’s attributes might resemble the following:

(printer-name=TVS),
(printer-natural-language-configured=en-us),
(printer-location=Cabin),
(printer-document-format-supported=application/postscript),
(printer-color-supported=false),
(printer-compression-supported=deflate,gzip)

The above example utilizes standard syntax for attributes in SLP. The only thing that has been added is a series of new lines in order to improve the example’s readability.

Service Location Protocol assigns three different roles to devices. A device may also have more than one role – up to three at once. The roles are as follows:

1. User Agents
2. Service Agents
3. Directory Agents

Today, the vast majority of daemon implementations are able to act as both Service Agents and User Agents. They can typically be configured to become Directory Agents also.

The Service Location Protocol is a protocol that is packet oriented. The vast majority of packets are transmitted through UDP. TCP can also be utilized for the transmission of longer packets, though. Owing to the potential unreliability of UDP, Service Location Protocol repeats all multicasts a number of times in increasing intervals until an answer has been arrived at.

All devices are required to listen on port number four hundred twenty seven for UDP packets. Directory and Service Agents should also listen for TCP on that port. Multicasting is utilized extensively by Service Location Protocol, especially by devices that join a network and are in need of seeking out similar devices.

Service Location Protocol’s operation can differ tremendously depending on whether or not a Directory Agent is in the network. When a client initially joins a network, a query is multicast for Directory Agents on that network. In the event that no Directory Agent answers the query, then it will be assumed that it is in a network without Directory Agents.

It is possible for Directory Agents to be added later, when they multicast a “heartbeat” packet in an interval that is predefined, which will be received by all the other devices in the network.

When a DA is discovered by an SA, then it is required to register all services at the Directory Agent. When a service vanishes, then the SA should contact the Directory Agent in order to cancel the registration.

To send a query through a network without a Directory Agent, the UA will have to send a multicast UDP packet that contains that query. All the SAs that boast matches will then send a UDP answer to the UA in question.

If the answer will not fit in to a UDP packet, then the packet will be identified as “overflown.” At that point, the UA is then free to send the query directly to the SA utilizing TCP. TCP is capable of transmitting packets of any size.

In order to be able to send a query in a network with a Directory Agent, the UA will have to send the query to the Directory Agent utilizing either TCP or UDP. Every SA must register all services with the Directory Agent; thus, the Directory Agent should be able to fulfill the request totally and will then simply send the result to the UA.