Abstract

This document describes the design and implementation of the caching of profiles within the VenueClient and VenueServer. There is already an implementation in place for profile caching in the VenueClient. This document will examine its design and implementation and also extend it for use in the VenueServer.

Overview

Purpose: Profile caching was initially added to the VenueClient in order to store the names of other users encountered in a venue. This allows user names to be easily chosen from a list when specifying access rights.

Now we are adding profile caching to the VenueServer in order to collect general information such as who and which geographical locations have successfully connected to the VenueServer.

Summary of Modifications

The code added to the server initializes a profileCache object and uses the cache object to store a user's profile when he or she enters a venue. Since the EnterVenue call is located in the Venue class (and not the VenueServer), it is convenient to place the call to the profile update code within the Venue class. This also allows the flexibility of separating the profile caches into per-venue directories even though it will default to a single directory for the server. Each user's profile is cached in a separate file so major conflicts will not occur when multiple venues are saving profiles at the same time.

Specifications

Profile Cache Design Decisions:

• User profiles are stored in separate files in the same directory (per venue or per server).
• Filenames are generated by an md5 hash based on the user's distinguished name. Filename collisions will seldom occur if ever. If they do, the loss of a single cached profile is not of great importance.
• There is a loadAllProfiles function that returns a list of users. It currently loads all files (profiles) from the cache directory, but should probably be changed to look for specific file extensions in case users put extra files in there by accident.
• The ClientProfileCache object utilizes the ClientProfile class and its save and load functions. Since the distinguished name is normally not saved in the profile, a flag was added to the save and load commands in order to specify when we want to include the distinguished name.

API for ClientProfileCache:

__init__(self, path)

set base path and verify the directory exists

updateProfile(self, profile)

stores profile if different from the cached profile

loadProfileFromDN(self, dn)

returns a profile

loadAllProfiles(self)

reads all profiles cached and returns them in a list

Implementation

class ClientProfileCache():
  def __init__(self, cachePath="")
  def updateProfile(self, profile)
  def loadProfileFromDN(self, distinguished_name)
  def loadAllProfiles(self)

Venue Code (VenueClient code is very similar)

from AccessGrid.ClientProfile import CreateClientProfile, ClientProfileCache

# Cache server profiles.
# Store in a server wide location.  You could make this different for
# each venue if you wanted to track who entered certain venues (secure
# venues or conference venues for example).
self.profileCachePrefix = "serverProfileCache"
self.profileCachePath = os.path.join(GetUserConfigDir(),self.profileCachePrefix)
self.cache = ClientProfileCache(self.profileCachePath)

In Venue.EnterVenue()

self._UpdateProfileCache(clientProfile)

New function in Venue.Venue

def _UpdateProfileCache(self, profile):
    try:
        self.cache.updateProfile(profile)
    except InvalidProfileException:
        log.warn("UpdateProfileCache: InvalidProfile when storing a venue user's profile in the cache.")

Copyright

This document is Copyright 2003, The University of Chicago/Argonne National Laboratory.