Algon: from interchangeable distributed algorithms to interchangeable middleware

1
Algon from interchangeable distributed
algorithms to interchangeable middleware

• Judith Bishop, Basil Worrall and Johnny Lo
• University of Pretoria
• Karen Renaud
• University of Glasgow

2
Contents

• Motivation and introduction
• Architecture of Algon
• Performance monitoring
• Dealing with failure
• Deadlock detection
• Interchangeable middleware
• Conclusions

3
1. Introduction

• Distributed systems are complex and multi-layered
• We focus on distributed algorithms for e.g.
  mutual exclusion, termination, deadlock etc
• Theory of algorithms were developed 20 years ago,
  but
• Availability of implementations limited
• Existing implementations may not suit
• Developing new implementations requires advanced
  skills
• Judging which implementation is best requires
  domain knowledge

4
Algorithm Examples VRS780
Ricart-Argwala non-token-based algorithm for Mutua
l exclusion

• Sites send requests and replies
• Compare timestamps
• Keep queues

5
Alternative Algorithm
Suzuki-Kasami Token-based Algorithm for Mutual
exclusion
6
Comparing m.e. Algorithms
7
Deadlock Detection
10 algorithms and 7 measurement parameters
8
Algon meets the Challenge

• Algon is a system (begun 2001) for Algorithms on
  the Net
• Algon hides complexity of algorithms from
  programmers in a separate component layer
• Current work involves
• Creating a new component layer for middleware
• Proving that the middleware can thus be exchanged
• Algon can then adapt to changes both theoretical
  (new algorithms) and practical (new middlewares)

9
Architectural Evolution I
Application
Application
Middleware
Middleware
Central Controller
Deals with synchronisation, non-determinism and
contention concerns
Middleware
Application
10
Architectural Evolution II
Application
Application
Application
Middleware
Middleware
Middleware
Centralised controller logic is duplicated in
each application. This logic may, however, be
spread throughout application code, making it
difficult to modify and maintain.
11
2. Algon Component Framework

• Distributed algorithm and scheduling code grouped
  in one component layer (the Algon layer)
• The component layer consists of at least one
• distributed algorithm Interface for a family of
  algorithms
• coded algorithm, implementing that Interface
• scheduler for that family of algorithms
• Families may be
• Mutual exclusion
• Deadlock
• Etc.

12
Algon Architecture
ALGON
13
Example Mutual Exclusion

• System has n (n gt 1) nodes requiring shared
  access to some resource

Mutual Exclusion Scheduler
Application Reading/Writing code
MEScheduler
Interface for Non-Token-based Mutual Exclusion
Algorithms
MENT
Ricart-Agrawala
Maekawa
Application or administrator may switch between
algorithms to adapt to different scenarios
Java/RMI
14
Terminology

• The scheduler is a class that
• Provides transparent access to lower-level Algon
  features
• Performs configuration
• Is specific to an algorithm family used
• The interface
• Generalises distributed algorithm families
• The algorithm
• Is programmed from theory
• implements an interface

15
Schedulers and Interfaces

• Schedulers allow algorithm-dependent state
  information to be maintained outside of
  application logic
• Interfaces abstract behaviour common to
  functionally equivalent algorithms
• Benefits
• Minimal alteration is required to add one or more
  algorithms to an application
• Painless interchange of algorithms
• Facilitates more desirable application performance

16
Architectural Issues

• Two shortcomings identified in original Algon
  architecture
• Automatic site discovery
• done by static config files
• Support for monitoring
• Initially ad-hoc and inefficient

17
Dynamic unique name assignment

• Name server tool (AlgonNameServer) added to the
  Algon framework
• Scheduler registers with AlgonNameServer
• Algorithm information, host IP address and unique
  identifier recorded
• Algorithm request sets constructed by
  Scheduler-initiated name queries

18
3. Performance monitoring
19
OutputDisplay
20
Performance Measurement

• OutputDisplay provides course-grained status
  information
• Data is not useful for realistic comparison of
  algorithms
• PerformanceDisplay was created to solve this
  problem
• Also receives status data via detached queue and
  Dispatch mechanism
• minimises impact on the application

21
PerformanceDisplay
22
4. Dealing with Failure

• Distributed failure is dealt with by specifically
  developed algorithms
• Keep core framework functionality alive by
  containing failures sacrifice non-functional
  components if need be
• Controlling application is kept running if at all
  possible
• Requirement
• Algon layers (e.g. PerformanceDisplay,
  OutputDisplay and AlgonNameServer) do not
  introduce new (unhandled) failure points

23
Dealing with Failure I
Application
Dispatch
Scheduler
Reporter
Interface
UpdateQueue
Algorithm
Algon NameServer
Performance Display
Output Display

• PerformanceDisplay and OutputDisplay
• If Dispatch fails, reports will not be forwarded
• Scheduler is unaffected because Reporter and
  UpdateQueue are not affected
• Dispatch will continue removing reports from
  queue, but discards them immediately

24
Dealing with Failure II
Application
Dispatch
Scheduler
Reporter
Interface
UpdateQueue
Algorithm
Algon NameServer
Performance Display
Output Display

• AlgonNameServer
• Failure during setup results in overall system
  failure
• Single point of failure is a weakness, but allows
  dynamic design
• Failure after setup does not compromise system
  integrity
• Straightforward to bootstrap name server from any
  site
• Redundant name server replication is also feasible

25
5. Deadlock Detection

• Wait-for graph Edge T-gtU is inserted into graph
  when T is blocked on request for resource that U
  holds T waits for U
• Deadlock detection If wait-for graph contains
  cycle (T-gtU-gt-gtT), system is deadlocked
• Detection can be performed at
• each graph insertion
• Timeouts
• user request
• Classic example Dining Philosophers

26
Application of Algon Deadlock Detection

• Many algorithms exist to detect deadlock
• We focus on diffusion computation family
• Example Chandy-Misra-Haas OR request model
  (1983)
• Other families are
• path-pushing
• edge-chasing

27
Incorporating deadlock detection
Resource acquisition performed here
Locally-held resources
Interface for deadlock detecting algorithms
Chandy-Misra-Haas OR request model algorithm
implementation
28
Setting up an application with DD
29
Testing for Deadlock
Algorithm
30
6. Interchangeable Middleware

• Eliminates reliance of core classes on specific
  middleware features/behaviour
• Improves Algons extensibility
• Provides insight into impact of middleware on
  algorithm implementations
• Enables re-implementation in different languages
  for different environments
• Initially RMI testing on Corba and .NET

31
Challenges

• Implications of using Java RMI as middleware
  layer
• Syntactic rules
• Stub classes must extend UnicastRemoteObject
• Remote objects must nominally implement Remote
  interface
• All methods intended for remote invocation must
  throw RemoteException
• Semantic rules
• All parameters are passed via deep copy
  (serialisation)
• Failure must be handled in application logic

32
Refactoring Mutual Exclusion

• MENT interface
• public interface Ment extends Serializable
• void sendRequests(SchedulerInterface si)
• void reply()
• void request(long time, SchedulerInterface si,
  Ment m)
• void getRequestSet()
• void sendRelease()
• void release()

33
Desired architecture
Remote
UnicastRemoteObject
Algorithm
Ment
RicartAgrawala

• cannot extend both RicartAgrawala and
  UnicastRemoteObject
• methods must still throw RemoteException

Algorithm
RicartAgrawala
Ment
Remote
UnicastRemoteObject
RicartAgrawalaRmi
34
Redesign
Remote
Algorithm
Ment
RicartAgrawala
RmiAlgorithm
RmiMentAlgorithm
UnicastRemoteObject
RmiMentAlgorithmImpl

• Use delegation with a place-holder as a
  middleware stub,
• Place-holder forwards algorithm calls to
  RicartAgrawala
• Ment interface methods throw superclass
  Exceptions
• Thus any exceptions thrown by Java-based
  middleware methods are catered for

35
Additions for middleware

• Middleware interface to cater for algorithm
  discovery, access and manipulation
• MiddlewareException class to signal
  middleware-related failures
• Toolset to generate middleware-dependent
  place-holders and stubs from algorithm interfaces

36
Configuring Algon

• Configuration file defines
• IP address of master site
• Number of participating nodes
• Class name of specific algorithm(s) to be used
• Environment variables define
• Whether or not to dump debug information to
  console
• Whether or not application should hook up to
  performance measuring components
• The middleware to use
• The destination for normal Algon output

37
7. Classifying Algon

• Algon is a tool that applies separation of
  concerns techniques to algorithmic concerns
• Similar to reflective systems, but does not react
  to its own behaviour, rather to runtime settings
• Separation of concerns techniques
• Real-time constraints Aksit et al 94
• Distribution and replication Guerraoui et al 97
• Exception handling Dellarocas 97
• Location control Okamura Ishikawa 94
• Synchronisation Lu et al 2001

38
Approaches to separation of concerns

• Identify concerns and specify in separate objects
• Compile-time proxies Renaud 2001
• Runtime reflection Welch Stroud 2001
• Treat concern as orthogonal thus someone
  elses problem Prentzeis 2000
• Use (3rd party) library that encapsulates
  complexity Guerraoui et al 97
• Algon matches third approach best
• Adds tailoring options and additional level of
  choice
• Garf Guerraoui et al 97 also uses this approach
  to address distribution issues
• Implemented in Smalltalk
• Does not provide alternative algorithms for same
  behaviour

39
Future Work

• Further exploration and incorporation of
  representative implementations algorithms for
• of agreement protocols
• resource management techniques
• failure recovery techniques
• Incorporating other middleware products (.NET)
• Translating Algon to C
• Extend performance evaluation
• New algorithm classes
• Measuring middleware impact
• Packaging and applications