The Berkeley Service Discovery Service
System Overview
[Homepage] [System overview] [Clients] [Services] [Servers] [Config options]

In case your interested, this page describes the architecture of the SDS system from a very high level. You don't really have to read this, but it will give you a better understanding of how all the pieces fit together.

System functionality

The Berkeley SDS provides a very basic function for client applications: it allows client applications to locate services that are running within the network. These services could be anything: certificate distributors, music jukeboxes, even speech-to-text converters. Clients want to use these applications/services for various reasons. However, in an age with 1000 node clusters, it becomes increasingly difficult to remember which services are running on which machines. The Berkeley SDS tries to solve this problem by automating it: services are tracked by SDS servers, and these servers in turn allow clients to make queries, searching for suitable services.

There are many features of the Berkeley SDS. First, we use XML to describe services and client queries, which allows for a fair amount of flexiblity. Services can create their own tags to better convey whatever information they need to. Another important feature is that it is secure: every component in the system is authenticated, service descriptions are signed by the principals running them, encryption is used for privacy, and capabilities are used to only allow authorized clients to discover sensitive services. A final feature of the Berkeley SDS is that it is fault tolerant: when services go down, the other components in the system will take notice and take appropriate actions.

The next few sections will describe the components of the SDS system.

SDS servers

The SDS servers are the heart of the SDS system. They provide for the basic bootstrapping mechanism, track which services are running, and answer client queries. Each server only coverages a portion of the network, which is currently set manually through the configuration of the SDS server.

The SDS servers provide the bootstrapping mechanism by publishing all the system's parameters on a well known global multicast channel. Clients and services only need to know this one channel address, and by listening on it, they can learn all parameters vary from one server to another. These announcements are sent per SDS server and are called SDS server announcements.

SDS servers track which services are running in their coverage area by having the services send them their descriptions periodically. Basically, each SDS server listens on a service announcement channel, which is a multicast address set in each SDS server's announcement. Services that want to participate in the SDS system get this address from the server announcement and then periodically broadcast their own description to it. If the service stops sending its description, then the SDS server will assume the service as died, and forget about it.

SDS servers handle client queries by simply matching service requests made by the clients against all of the service descriptions it knows about. Both the descriptions and the client queries are made in XML in order to provide for flexibility. If a match is found, then that service description is sent to the client.

Services

The operation of the services is fairly straight forward, as explained in the last section. They need only send their descriptions to the SDS servers. The servers take care of the rest.

The only real difficulty for the services comes for the security features of the system. First, each service is responsible for signing its description, to authenticate the information. Second, the services are also responsible for specifying which principals/users should have the right to discover them. This is done by having the service specify a capability that is needed to discover the service, and then list which principals should receive this capability. Finally, the services have to also encrypt their descriptions such that only the intended SDS servers can decrypt them. This guarantees privacy of the service description when sending it over the network.

Clients

Clients are also straight foward. They simply compose queries and send them to the nearest SDS server. Due to the security features, they also have to retreive all the capabilities that they have, and pass them along with the query so that the SDS server will only give back services for which they have the right to discover.

Security components

There are several components of the system related to security. These components include certificates, capabilities, and services that distribute them. We will briefly describe what certificates and capabilities are, and how they are used in the Berkeley SDS.

As mentioned above, the SDS uses certificates to authenticate users and components in the system. Certificates basically binding a user name/principal name to some public key, where only that user has the corresponding private key. Users can then sign messages using their private key, and others can verify the messages using the public key associated with user in the certificate.

In the SDS, each component is run by a particular principal, and therefore is identified by its principal's certificate. For example, a official department SDS server might be run using the "sds-admin@cs.berkeley.edu." certificate, whereas a private IMAP server might be run under the "czerwin@cs.berkeley.edu." certificate. This way, when other components interact, each can decide if they trust that particular principal or not. In the case of the SDS servers, most users would probably be willing to trust the sds adminstrators, but some might not be willing to use an IMAP server run by a potentially malicious graduate student.

Capabilities are similar to certificates in that they bind principal names to access rights. For example, one capability might bind the principal name "czerwin@cs.berkeley.edu" to the right of accessing all graduate student services. This is done by having a central capability signer that creates a message saying that the principal has that particular right, and then signing it using its private key. Anyone that receives a copy of this capability can easily verify the capability is valid by verifing the signature using the capability signer's public key.

Capabilities are used in the SDS system to prove that particular users have the right to discover certain services. For example, a set of services might indicate to the SDS servers that in order to discover them, a user must have the "graduate student" capability. Then, whenever the SDS server gets a request from a user that posses a capability that proves that user has the "graduate student" capability, it knows it is free to give back any of those services. By doing this, SDS servers are allow services to be private. For example, if you have a color printer that you don't want anyone else to know about, you could have the service require a capability that only you have, guaranteeing privacy.

To make all of this work, the SDS system relies on a couple more services to distribute both capabilities and certificates. To distribute capabilities, the system uses the ninja.sds.CapabilityDistributor service. To distribute certificates, it uses the ninja.ispace.auth.CertificateRegistry service. See those classes for more information.