The Case for Proactive Directory Services
Fabián E. Bustamante - Patrick Widener - Karsten Schwan
{fabianb,pmw,schwan}@cc.gatech.edu
www.cc.gatech.edu/systems/projects/PDS
Center for Experimental Research in Computer Systems
College of Computing
Georgia Institute of Technology
Research Context
New infrastructure layers pooling together widely distributed resources
and services
Computational Grids
Pervasive Computing
Directory service: key component for such infrastructures
Metacomputing Directory Service (Globus)
Intentional Naming System (Oxygen)
Secure Directory Service (Ninja)
Internet
…
Directory services
Act as the “glue” that holds distributed infrastructure together
Provide information about different objects in the environment
Requirements
Support sophisticated object descriptions and query patterns
Operate in highly dynamic environments
Scale to an increasingly large number of objects
The Problem
Classic directory services
Designed for fairly static environments where updates are rare
Rely on “exclusive” inactive interfaces
Problems with inactive interfaces
Hinder service scalability: Client, server, and network
Indirectly restrict the behavior of potential applications1
1.W. Smith et Al., “An Evaluation of Alternative Designs for a Grid Information Service”, In Proceedings of the HPDC9,
Pittsburg, Pa, August, 2000.
Global Namespace
Domain
The Approach:
Customizable Proactive Mode for Directory Services
Filter
Context
Context
To extend service’s client-interface with proactivity
• Costs/Benefits
Scalability of servers, clients, and network
More “consistent” view of the world
Increased application/service reactivity
Potential loss of control 
generic client customization of notification
•
Entity
Entity
Context
Entity
Directory
Agent
Entity
Filter
Entity Notification2
Client
Agent
Evaluating Passive and Active Interfaces
Clients need to be aware of updates to entities but have no knowledge of the
pattern of those updates.
Restricted to a passive interface – a client can poll the directory for updates at
some frequency; its degree of consistency depends on how closely its polling
pattern matches the update pattern of the entity owner.
Filter
Owner
Agent
BIND DNS 8.2.2-7,
OpenLDAP 1.2.11
and PDS.
15 updates by
owner, at random
instants of time,
over a 40 minutes
period. 7 different
poll intervals by
client.
With an active interface – the client can choose to remain fully consistent,
independently of the update pattern of the entity’s owner.
Filter example:
{
int i, j;
double sum = 0.0;
for (i = 0; i < MAXI; i = i + 1) {
for (j = 0; j < MAXJ; j = j + 1) {
sum = sum + input.array[i][j];
}
}
output.avg_array = sum / (MAXI * MAXJ);
if (sum > THRESHOLD) return 1; /* submit */
else return 0; /* filter out */
}
Client-specific customization of notification
does not necessarily penalize servers.
Related Work
•Directory
Services
MDS, INS, SDS, Globe’s Directory Service, Huang and
Steenkiste’s Extended-SLP, Active Names,…
•Publish/Subscribe Systems
Gryphon, Siena, JEDI, SEDA, …
•Cache Consistency (in Web, WAN FS, …)
Future Work
•Security
•Evaluation approaches
•More applications, …